Page 3 of 9

Re: Java port of Bullet

Posted: Fri Jul 18, 2008 5:56 am
by LvR
Hey, that's a great news, thx

Re: Java port of Bullet

Posted: Wed Jul 30, 2008 10:16 pm
by jfelrod1960
I'm having trouble running the jBullet demos. I know it is something I'm doing wrong.

Code: Select all

Exception in thread "main" java.lang.Error: not instrumented
	at cz.advel.stack.Stack.alloc(Stack.java:110)
	at com.bulletphysics.collision.broadphase.AxisSweep3Internal.<init>(AxisSweep3Internal.java:90)
	at com.bulletphysics.collision.broadphase.AxisSweep3.<init>(AxisSweep3.java:49)
	at com.bulletphysics.collision.broadphase.AxisSweep3.<init>(AxisSweep3.java:41)
	at com.bulletphysics.demos.dynamiccontrol.DynamicControlDemo.initPhysics(DynamicControlDemo.java:81)
	at com.bulletphysics.demos.dynamiccontrol.DynamicControlDemo.main(DynamicControlDemo.java:244)
Would appreciate any help
Jeff

Re: Java port of Bullet

Posted: Sat Aug 02, 2008 5:06 am
by jezek2
jfelrod1960 wrote:I'm having trouble running the jBullet demos. I know it is something I'm doing wrong.

Code: Select all

Exception in thread "main" java.lang.Error: not instrumented
	at cz.advel.stack.Stack.alloc(Stack.java:110)
	at com.bulletphysics.collision.broadphase.AxisSweep3Internal.<init>(AxisSweep3Internal.java:90)
	at com.bulletphysics.collision.broadphase.AxisSweep3.<init>(AxisSweep3.java:49)
	at com.bulletphysics.collision.broadphase.AxisSweep3.<init>(AxisSweep3.java:41)
	at com.bulletphysics.demos.dynamiccontrol.DynamicControlDemo.initPhysics(DynamicControlDemo.java:81)
	at com.bulletphysics.demos.dynamiccontrol.DynamicControlDemo.main(DynamicControlDemo.java:244)
Would appreciate any help
Jeff
It seems you've compiled whole JBullet yourself without using provided ANT script (build.xml). For full build you need to instrument classes by JStackAlloc (bundled with JBullet sources), which is automatically handled by provided ANT script. I've removed dependency on JStackAlloc in demos (all code in com.bulletphysics.demos packages) in latest development version. I've also backported the change to latest release, grab it here and replace the files with it. After that you should be able to compile demos without problem, just copy only code from com.bulletphysics.demos packages and use pre-compiled "jbullet.jar" (or build it properly by provided ANT script).

Re: Java port of Bullet

Posted: Sun Aug 03, 2008 9:10 pm
by jezek2
New version available on JBullet homepage.

Changes in release 20080803:
- Upgraded LWJGL to 2.0rc1
- Added UniformScalingShape
- Improved JavaDoc generation
- Removed dependency on JStackAlloc in demos
- Added support for moving triangle meshes
- Added MovingConcaveDemo
- Optimized allocation of collision algorithms

Re: Java port of Bullet

Posted: Tue Aug 05, 2008 2:14 pm
by jfelrod1960
Thanks! I'm using Eclipse instead of Netbeans so when I run the ant build, I have to move the classes to the bin directory. At any rate it is working great.

Jeff :D

Re: Java port of Bullet

Posted: Fri Aug 15, 2008 11:41 am
by irrisor
Hi all,

I have a question regarding jBullets feature set. As it might be a feature not present in Bullet itself, I post it here:

Do linear joint limits work? (I would like to model things like pistons etc.)
Using it like the rotational stuff it results in strangely oscillating joints without any degree of freedom.

Any pointers on what could be wrong? Missing feature?

Regards,
Irrisor

Re: Java port of Bullet

Posted: Sun Sep 07, 2008 5:19 am
by Erwin Coumans
irrisor wrote:Hi all,
Do linear joint limits work? (I would like to model things like pistons etc.)
Using it like the rotational stuff it results in strangely oscillating joints without any degree of freedom.
Bullet has linear joint limits in several constraints. Check out btSliderConstraint and its demo. Or download Bullet 2.71 and play with the ForkLiftDemo. Don't know if this has been ported to JBullet yet.

Thanks,
Erwin

Re: Java port of Bullet

Posted: Wed Sep 17, 2008 5:51 pm
by jezek2
New version available on JBullet homepage.

Changes in release 20080917:
- Documented many classes and adjusted existing descriptions
- Minor API changes
- Changed method names for callbacks to be more descriptive
- Improved BulletGlobals
- Added SliderConstraint
- Added ForkLiftDemo

Re: Java port of Bullet

Posted: Thu Sep 18, 2008 9:26 am
by tokmag
Hi all,

I now found the JBullet, and I wrote a simple code to test it with Java3D. In my code I created a DiscreteDynamicsWorld with SequentialImpulseConstraintSolver, DefaultCollisionConfiguration, AxisSweep3_32 and CollisionDispatcher. I added to this dynamic world an BvhTriangleMeshShape, and I wanted to drop some Cylinder objects to this triangle mesh shape, from a small height. It worked beautifull, but after 200 cylinder became very slow. (The cylinders was in one clump. The height of the cylinders was 0.3 with a 2.0 radius). I used the stepSimulation with 1/60.0 and I tested with deltaTime also, but after 200 cylinder was very slow.

My computer has this configuration:
core 2 duo 2.2 GHz,
1 GB ram

I wish to know, if I have mistaken, or this behaviour is normal.

Thanks for your answers.

Re: Java port of Bullet

Posted: Thu Sep 18, 2008 11:06 am
by jezek2
tokmag wrote: I now found the JBullet, and I wrote a simple code to test it with Java3D. In my code I created a DiscreteDynamicsWorld with SequentialImpulseConstraintSolver, DefaultCollisionConfiguration, AxisSweep3_32 and CollisionDispatcher. I added to this dynamic world an BvhTriangleMeshShape, and I wanted to drop some Cylinder objects to this triangle mesh shape, from a small height. It worked beautifull, but after 200 cylinder became very slow. (The cylinders was in one clump. The height of the cylinders was 0.3 with a 2.0 radius). I used the stepSimulation with 1/60.0 and I tested with deltaTime also, but after 200 cylinder was very slow.
Try AxisSweep3 or even SimpleBroadphase. The AxisSweep3_32 is highly unusable in Java because of Java object overhead and the way it's designed. The redesign is possible but would need to slightly change API of many other classes, the route I wish not go. More likely I will just remove it, there is better broadphase in Bullet anyway, the DbvtBroadphase (though that's not yet ported in JBullet).

You can also enable server VM which gives nice performance boost (but it's quite bad for single core CPUs before Intel Core era due to noticeable compile pauses).

BTW you can compare this to BasicDemo which contains 125 boxes, which is also somewhat slower than other demos.

Re: Java port of Bullet

Posted: Mon Sep 22, 2008 11:05 pm
by geniot
Hello,
I've just managed to start demos using my IDE after some voodoo stuff with instrumenting et al.
I'm quite impressed with what I see. Although I'm worried about the performance issues.
Looks like those demos are taking up a lot of CPU power. Gets to 50-70% on my Centrino Duo.
And you don't use shaders, shades, textures, lighting effects. I guess performance would worsen even more in that case.
Could you speculate on performance issues a little bit. What are the bottle necks?
Maybe I'm using some libs incorrectly (some software rendering?) ?
I've put all dll's into the root of my project.
In comparison I've downloaded and started a Tokamak demo in pure C (OpenGL rendering). There is that demo with a hundred of cubes/cones/spheres falling onto a table (similar to the basic demo with cubes) and the CPU usage is close to none (somewhere around 7%).
Is it because of the physics calculations done in C? or because of the Java JNI calls to rendering?
Wouldn't it be better to bind physics calculations to C instead of writing it in pure Java?
The rendering in Java is not delayed right now, the only thing that worries me is the cooler on my notebook that starts to hum and the fact that at some point the rendering will be delayed or for some older hardware my games will not be real time but more of a turn-based nature. :)

Re: Java port of Bullet

Posted: Tue Sep 23, 2008 6:45 am
by jezek2
geniot wrote:Hello,
I've just managed to start demos using my IDE after some voodoo stuff with instrumenting et al.
You can just use already provided jbullet-all.jar and copy just the demos package, this way you don't need to do any instrumentation. I suppose I should really create a readme.txt :)
geniot wrote: I'm quite impressed with what I see. Although I'm worried about the performance issues.
Looks like those demos are taking up a lot of CPU power. Gets to 50-70% on my Centrino Duo.
And you don't use shaders, shades, textures, lighting effects. I guess performance would worsen even more in that case.
Could you speculate on performance issues a little bit. What are the bottle necks?
Maybe I'm using some libs incorrectly (some software rendering?) ?
I've put all dll's into the root of my project.
In comparison I've downloaded and started a Tokamak demo in pure C (OpenGL rendering). There is that demo with a hundred of cubes/cones/spheres falling onto a table (similar to the basic demo with cubes) and the CPU usage is close to none (somewhere around 7%).
Is it because of the physics calculations done in C? or because of the Java JNI calls to rendering?
I don't think this is Java-specific issue. The demos are rendering in loop without any FPS throttling, so you'll end up with (almost) full CPU utilization (and it's normal in many games). Shaders etc. doesn't play much role, since they're handled mainly by GPU. Software rendering is used only in applet demo.

I didn't tested Tokamak demo, but it must either limit FPS or have enabled vsync, which you can test too by either driver settings or by calling Display.setVSyncEnabled(true) in initialization code of com/bulletphysics/demos/opengl/LWJGL.java. You should rather compare this to the Bullet C++ pre-compiled demos (available in downloads).

Using C or JNI doesn't play role here. And JNI overhead with OpenGL is practically non-existent as you need to batch geometry anyway to render efficiently in OpenGL generally (JBullet demos do that).
geniot wrote: Wouldn't it be better to bind physics calculations to C instead of writing it in pure Java?
For this issue, no. Generally yes it's also a way. I initially did a binding before and wasn't satisfied with it: bad API interaction with native stuff, you need to track objects to destroy instead relying on GC, maintaining native builds for all supported platforms is huge task, you can't use it in secure (sandbox) environments such as unsigned applets, there was lack of full-blown pure Java physics libraries, etc.

With JBullet it's as easy as just include one .jar and you're done with that, it simply works the same on all platforms with one build :)
geniot wrote: The rendering in Java is not delayed right now, the only thing that worries me is the cooler on my notebook that starts to hum and the fact that at some point the rendering will be delayed or for some older hardware my games will not be real time but more of a turn-based nature. :)
Just limit FPS in your game loop, or redraw only when needed. The physics itself is running at fixed speed (maintained automatically by Bullet), so it shoudn't utilize CPU that much unless you overload the simulation of course :)

Re: Java port of Bullet

Posted: Tue Sep 23, 2008 10:44 am
by geniot
Yes! vsync did a whole world of difference.
Cubes are flying like crazy and the CPU never gets too high.
Now I'm going to write something using JBullet , thanks!
A little quote on vsync that I found:
"There is no visual benefit to having a game render more frames per second than your monitor is displaying."

Re: Java port of Bullet

Posted: Thu Nov 13, 2008 10:14 pm
by naz027
I've just downloaded the latest version of JBullet. Firstly I'd like to say thank you very much for porting Bullet to Java, I'm far more confident coding in Java and hopefully JBullet will make my life a lot easier.

However so far I have been unable to compile the source and run the demos. I'm having similar problems to jfelrod1960. If I use ANT with build.xml I get the following errors:

Code: Select all

    [javac] Compiling 223 source files to /Users/adamnasralla/Java/jbullet-20080917/build/classes
    [javac] /Users/adamnasralla/Java/jbullet-20080917/src/com/bulletphysics/collision/broadphase/AxisSweep3Internal.java:375: method does not override a method from its superclass
    [javac]     @Override
    [javac]          ^
    [javac] /Users/adamnasralla/Java/jbullet-20080917/src/com/bulletphysics/collision/broadphase/AxisSweep3Internal.java:585: method does not override a method from its superclass
    [javac]     @Override
    [javac]          ^
    [javac] /Users/adamnasralla/Java/jbullet-20080917/src/com/bulletphysics/collision/broadphase/AxisSweep3Internal.java:594: method does not override a method from its superclass
    [javac]     @Override
    [javac]          ^
    [javac] /Users/adamnasralla/Java/jbullet-20080917/src/com/bulletphysics/collision/broadphase/AxisSweep3Internal.java:600: method does not override a method from its superclass
    [javac]     @Override
    [javac]          ^
    [javac] /Users/adamnasralla/Java/jbullet-20080917/src/com/bulletphysics/collision/broadphase/AxisSweep3Internal.java:621: method does not override a method from its superclass
    [javac]     @Override
    [javac]          ^
    [javac] /Users/adamnasralla/Java/jbullet-20080917/src/com/bulletphysics/collision/broadphase/AxisSweep3Internal.java:636: method does not override a method from its superclass
    [javac]     @Override
    [javac]          ^
    [javac] /Users/adamnasralla/Java/jbullet-20080917/src/com/bulletphysics/collision/broadphase/AxisSweep3Internal.java:642: method does not override a method from its superclass
    [javac]     @Override
    [javac]          ^
    [javac] /Users/adamnasralla/Java/jbullet-20080917/src/com/bulletphysics/demos/applet/DemoPanel.java:200: method does not override a method from its superclass
    [javac]             @Override
    [javac]                  ^
    [javac] /Users/adamnasralla/Java/jbullet-20080917/src/com/bulletphysics/demos/applet/DemoPanel.java:204: method does not override a method from its superclass
    [javac]             @Override
    [javac]                  ^
    [javac] /Users/adamnasralla/Java/jbullet-20080917/src/com/bulletphysics/demos/applet/DemoPanel.java:208: method does not override a method from its superclass
    [javac]             @Override
    [javac]                  ^
    [javac] /Users/adamnasralla/Java/jbullet-20080917/src/com/bulletphysics/demos/applet/DemoPanel.java:212: method does not override a method from its superclass
    [javac]             @Override
    [javac]                  ^
    [javac] /Users/adamnasralla/Java/jbullet-20080917/src/com/bulletphysics/demos/applet/DemoPanel.java:222: method does not override a method from its superclass
    [javac]             @Override
    [javac]                  ^
    [javac] /Users/adamnasralla/Java/jbullet-20080917/src/com/bulletphysics/demos/applet/DemoPanel.java:228: method does not override a method from its superclass
    [javac]             @Override
    [javac]                  ^
    [javac] /Users/adamnasralla/Java/jbullet-20080917/src/com/bulletphysics/demos/applet/DemoPanel.java:234: method does not override a method from its superclass
    [javac]             @Override
    [javac]                  ^
    [javac] 14 errors
Any help would be much appreciated.

Adam

Re: Java port of Bullet

Posted: Fri Nov 14, 2008 6:55 am
by jezek2
naz027 wrote:However so far I have been unable to compile the source and run the demos. I'm having similar problems to jfelrod1960. If I use ANT with build.xml I get the following errors:
This is because Java 5 can't use @Override on interface methods, you can safely remove the annotations. You can also (and it's preferred) use the precompiled library and just copy out the demos package to play with. Demos package can be compiled normally without any need of using provided ANT script.