Re: Java port of Bullet
Posted: Fri Jul 18, 2008 5:56 am
Hey, that's a great news, thx
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)
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).jfelrod1960 wrote:I'm having trouble running the jBullet demos. I know it is something I'm doing wrong.
Would appreciate any helpCode: 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)
Jeff
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.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.
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).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.
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.txtgeniot wrote:Hello,
I've just managed to start demos using my IDE after some voodoo stuff with instrumenting et al.
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.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?
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.geniot wrote: Wouldn't it be better to bind physics calculations to C instead of writing it in pure Java?
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 coursegeniot 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.
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
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.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: