Raytest difference between jBullet and Native bullet

Troubleshooting physics
1

First of, I know native bullet isn’t done yet. Hopefully this test case will help getting it there eventually :slight_smile: This is nightly.



I was playing around with ray casting and in native bullet the hit fraction seems to be the inverse of what JBullet does. There also seems to be a difference in the sizes of boxes, haven’t really understood what that is about but if the FUDGE_FACTOR is set to 1.0f JBullet detects collisions but native bullet does not.



Don’t rightly know what to make of this or what to do about it but here it is.



[java]package mygame;



import com.jme3.app.SimpleApplication;

import com.jme3.bullet.BulletAppState;

import com.jme3.bullet.collision.PhysicsRayTestResult;

import com.jme3.bullet.collision.shapes.BoxCollisionShape;

import com.jme3.bullet.control.RigidBodyControl;

import com.jme3.font.BitmapText;

import com.jme3.math.Vector3f;

import com.jme3.scene.Node;

import java.util.ArrayList;

import java.util.List;



/**

  • test
  • @author jmaasing

    /

    public class Main extends SimpleApplication {

    private BulletAppState bulletAppState = new BulletAppState();

    private final Vector3f boxHalfExtents = new Vector3f(1f, 1f, 1f);

    private final float FUDGE_FACTOR = 1.5f ;



    public static void main(String[] args) {

    new Main().start();

    }



    @Override

    public void simpleInitApp() {

    stateManager.attach(bulletAppState);

    StringBuilder sb = new StringBuilder() ;



    sb.append(addBox("Pos X", 5f, 0, 0)).append(" | ");

    sb.append(addBox("Neg X", -5f, 0, 0)).append(" | ");

    sb.append(addBox("Pos Y", 0, 5f, 0)).append(" | ");

    sb.append(addBox("Neg Y", 0, -5f, 0)).append(" | ");

    sb.append(addBox("Pos Z", 0, 0, 5f)).append(" | ");

    sb.append(addBox("Neg Z", 0, 0, -5f));



    BitmapText bitmapText = new BitmapText(guiFont);

    bitmapText.setText(sb);

    bitmapText.setLocalTranslation((settings.getWidth() - bitmapText.getLineWidth())0.5f, (settings.getHeight() + bitmapText.getLineHeight())0.5f, 0);

    guiNode.attachChild(bitmapText);



    bulletAppState.getPhysicsSpace().enableDebug(assetManager);

    }



    private String addBox(final String name, final float x, final float y, final float z) {

    Node node = new Node(name);

    node.setLocalTranslation(x, y, z);

    node.addControl(new RigidBodyControl(new BoxCollisionShape(boxHalfExtents), 0f));

    bulletAppState.getPhysicsSpace().add(node);

    rootNode.attachChild(node);



    Vector3f from = Vector3f.ZERO ;

    Vector3f to = new Vector3f(x    FUDGE_FACTOR, y    FUDGE_FACTOR, z    FUDGE_FACTOR);

    List<PhysicsRayTestResult> results = new ArrayList<PhysicsRayTestResult>();

    bulletAppState.getPhysicsSpace().rayTest(from, to, results);

    if (results.size() > 0) {

    return "" + to + " = "+ results.get(0).getHitFraction() ;

    }

    return to + " = No hit" ;

    }

    }

    [/java]
1 Like
2

Hm… Okay, thanks! I’ll keep a link to this post.

3

You up to date? Since in older revision there was in fact a simple swap in the native call. But as far as I know it is fixed already.



Hit fraction should be Hitposition = from + direction*hitfraction.

4

I just updated nightly + clean and build, still the same difference. Don’t know what else to do to make sure I’m updated. But it sounds like that is the fix alright :slight_smile:



Here is an idea, wouldn’t it be great if the stats view included a version + build number? Is that information available somewhere?

2 Likes
5

hm I will take a look at this

insert 15 minute break for loading ide on netbook

Yes, right, seems like I only fixed that in my local version:



@normen



In physicspace.cpp



JNIEXPORT void JNICALL Java_com_jme3_bullet_PhysicsSpace_rayTest_1native

(JNIEnv * env, jobject object, jobject to, jobject from, jlong spaceId, jobject resultlist) {

should be

JNIEXPORT void JNICALL Java_com_jme3_bullet_PhysicsSpace_rayTest_1native

(JNIEnv * env, jobject object, jobject from, jobject to, jlong spaceId, jobject resultlist) {



can you fix and commit that plz?

6
@EmpirePhoenix said:
can you fix and commit that plz?

Nope, I am on vacation and only have my iPad.
@jmaasing: I don't exactly know what you mean? Where to store the build number?
7
@normen said:
Nope, I am on vacation and only have my iPad.
@jmaasing: I don't exactly know what you mean? Where to store the build number?


It could be stored anywhere, what he wanted is that the build number should show up on StatsAppState debug text.
1 Like
8
@shirkit said:
It could be stored anywhere, what he wanted is that the build number should show up on StatsAppState debug text.

Exactly. Ive done similar things in many ways, generating a "Version.java" file from Ant-scripts, reading maven metadata from META-INF. The thing is, it helps to identify what is deployed. If it were visible on the StatsAppState and people upload screenshots of whatever problem they have it might be useful.
9

Yeah, sounds like a useful idea to me.

10

I know that NB modules have some update info that could show this, but I’m not sure where to find this information for the libraries.

11

Could this be causing my issue with the GhostControl collsions? I haven’t dug to far into how the control does detection yet (its on my list), so I’m hoping so.



http://hub.jmonkeyengine.org/groups/physics/forum/topic/ghostcontrol-collision-oddness/

12

if you use native bullet it depends, if the character uses rays from java then yes, from native code it works fine however.

13
@jmaasing said:
Exactly. Ive done similar things in many ways, generating a "Version.java" file from Ant-scripts, reading maven metadata from META-INF. The thing is, it helps to identify what is deployed. If it were visible on the StatsAppState and people upload screenshots of whatever problem they have it might be useful.

Ah, generally, I thought for the natives or something.. Thing is, what part of the engine would define that? The single plugins all have build numbers but the people that deeply mess up their installs often have mixed jar files and whatnot. Also whats with the people who build themselves?
14

Basically the right place to do such a thing would be the svn system unfortunatly there is no way to attach a hook to a commit event, and increase a number in a file then. And doing this manually will lead to forgotten increments, false increments ect. This would only work if people would be forced to use nightlys, but that is not a real solution either.

15

Actually can’t you do it the other way around? The commit event already generates a version number. Usually there are “magic strings” you can put in files that on a fetch put that version number there.



http://stackoverflow.com/questions/107840/how-to-display-latest-revision-in-a-file

http://stackoverflow.com/questions/16248/getting-the-subversion-repository-number-into-code

16
@normen said:
Ah, generally, I thought for the natives or something.. Thing is, what part of the engine would define that? The single plugins all have build numbers but the people that deeply mess up their installs often have mixed jar files and whatnot. Also whats with the people who build themselves?

Yes this won't help in all cases (manually messing up the composition of the system). As Empire_Phoenix says the trick is to be able to backtrack from an installation to a revision in source control. I've usually tackled this in the build system (like zarch suggests) and assumed that the installation "bundle" can have a single number even if the components have their separate revisions.
I probably confused the issue by talking about build numbers, it is probably more accurate to talk about something akin to release-numbers and consider every nightly build a "release". The composition of the release (i.e. what revisions of the various modules) needs to tracked but that can be solved.

Not a big thing but I think it could be helpful. In dream-land :) it could shorten this:
User: "I have a problem, here is a screenshot"
Forum: "Is this stable or nightly?"
User: "Nightly"
Forum: "When did you update?"

To:
User: "I have a problem, here is a screenshot"
Forum: "I see you have revision X, that has been fixed in revision Y"
17

The nightlies all have build numbers in the respective SDK plugins version numbers, the stable ones will be e.g. 3.0.1 in the future. Like I say it only makes sense if you have an actual original build (SDK update).

18

…and this is something that is created and packaged on build, not on commit… using either something similar to what zarch suggests or some other approach.



For Mythruna, I stick a build.time file in the build/classes directory and look it up as a class resource.



Normen is right, though… it gets more complicated for the plugins and stuff.

19

Yeah, it might be misleading to invent a single number for the set of plugins in the SDK that is updated everytime one plug-in is updated. I was mostly thinking about the engine version and something like pspeed says with build.time or something, but still, more trouble than it is worth I guess.

20

Well, the NB plugins have already this information! Maybe this could be used? The only problem is that as @normen said, if you have built the engine from the SVN, this won’t work though. http://stackoverflow.com/questions/3238769/how-do-i-find-the-version-of-a-installed-netbeans-module



Now, get the information about the jMonkeyEngine3 Library module.



Installed version:3.0.0.9393

Available version:3.0.0.9583

Author: jMonkeyEngine

Date: 25/07/12

Source: jMonkeyEngine SDK Nightly

Homepage: http://www.jmonkeyengine.com



Plugin Description

This plugin contains the jMonkeyEngine3 library used to run and distribute your jMonkeyEngine applications.