org.lwjgl.LWJGLException: Could not choose visual at org.lwjgl.opengl.LinuxDisplayPeerInfo.initDefaultPeerInfo(Native Method) at org.lwjgl.opengl.LinuxDisplayPeerInfo.<init>(LinuxDisplayPeerInfo.java:52) at org.lwjgl.opengl.LinuxDisplay.createPeerInfo(LinuxDisplay.java:702) at org.lwjgl.opengl.Display.create(Display.java:779) at org.lwjgl.opengl.Display.create(Display.java:733) at com.bulletphysics.demos.opengl.LWJGL.main(LWJGL.java:53) at com.bulletphysics.demos.vehicle.VehicleDemo.main(VehicleDemo.java:609) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at com.sun.javaws.Launcher.executeApplication(Launcher.java:1272) at com.sun.javaws.Launcher.executeMainClass(Launcher.java:1218) at com.sun.javaws.Launcher.doLaunchApp(Launcher.java:1065) at com.sun.javaws.Launcher.run(Launcher.java:105) at java.lang.Thread.run(Thread.java:619)

Odd, what graphics card/drivers/platform did you test on? Does other LWJGL based apps work for you? I'm using LWJGL 2.0rc1.

JBullet as physics engine is independent of any graphics API. The demo framework uses OpenGL through LWJGL. The drawing and input is already abstracted so it can support software renderer for applet demo, so it should be pretty easy to add JOGL support. If you're interested you can contribute the code

They should be there just for something to block falling out. Or did you test the applet demo? The software renderer is currently very simple and there is only linear non-perspective interpolation, so they sometimes occlude geometry in front of them.

As long as there will be features interesting for my applications I will port them. Some features I do not use, but are usually not that complex and creates completness of library. In latest development version I'm focusing on writing descriptive JavaDocs and better method names and encapsulation. Goal is to transform it to a normal Java library without much signs of C++ origin. There is possibility that development will stagnate, but it's open source and I think there won't be problem supporting at least contributors in future.

To all: any ideas how to make JBullet more visible? It has some (small) popularity, but when I try googling it, not many sites are mentioning it.

First, great work jezek! Keep it up!

May I make some modest suggestions on how to increase visibilty?(If not then please disregard the following :)

1) Start a project for jBullet on sourceforge.net (or equivalent). It doesn't mean you should use their tools. Just get a space and forward traffic to your home page. In the future it might also be a very good platform for incorporating contributors etc. It's also a nice way of making sure that the project never "disappears", and that makes people more confident and willing to use the library. (Of course that would require committing the code every once in a while to the sf code repository.)

2) Get more people involved in the project. Try to get people who write game engines, games and other stuff to contribute, test and use the library. They will write about it on their websites and so on. This might not be an option, depending on how "personal" this project is to you. You know best. Follow your heart. (Hehe gee that sounded corny..) The theory is, more people on the project, more activity and exposure.

3) Put up a minimal Wordpress website with a simple design. Utilize the blog-feature and post regular news. (Make sure people can subscribe to that RSS-feed.) I strongly suggest Wordpress as it's efficient, simple and a SEO-winner.

4) Make YouTube videos and screenshots and put up on the blog/website.

5) Create a jBullet logo that people can put in their games/websites to show that they use it.

6) Make screenshots and videos. Did I already say that? ;) The trick is really to make screenshots and videos that tickle people's imagination, imho. A checkerd plane with some boxes colliding is not very fun, apart from the occasional academic left-brain kick. A nicely lit basement with some crates moving around and being destroyed when shot at, tells the story.

I believe, that if you got all this going, Google rank will happend by itself. (Although a nice proper domain, like jbullet.org, wouldn't hurt.)

I'm kinda a layman-hobby-learning-game-deving-in-my-spare-time-guy, and I'd love to play around with jBullet, and I will a some point :) Anyway, if any of the suggestions above sound good and you wanna give them a try, but you feel pressed on time, then I'd be happy to help out. I'm a web designer and could help out with 1), 3) and 5). In the future I might be able to do videos and screenshots too. Just let me know somehow if I can help out!

May I make some modest suggestions on how to increase visibilty?(If not then please disregard the following

Hi, thanks for your suggestions. I will be thinking about them more. You're right that more core developers would be really nice, but the problem is, that I feel that not much developers are interested in doing this kind of work. I somewhat always do the hard things that others don't have energy to put on, like this task of porting huge amount of C++ code to Java, it also requires quite good knowledge of both languages. I've been there before on another open source project: MetaTheme which provides unified look and feel of major Linux GUI toolkits (including Swing). It had some nice exposure, and even few contributors, but no one touched core Again you would need to master three different GUI toolkits to touch it... I use it everyday, it's not perfect but usable for me, and I still have future plans, just I had to abandon it for few years because of other projects (and partially also for regaining energy and rethinking architecture).

So JBullet is not that ordinary project. Also creating some news is problematic, since most work is about porting existing library and "only" fiddling with details on top of that. Even the original Bullet doesn't have news too often

I think that more real demo could be done as a part of my "main" project (for which JBullet was partly created). I plan to add some testing physics scene, could be used also for promoting JBullet, by both screenshots/videos and actual demo application. As a side effect I would gather some stats how it run on more HW (I'm especially curious about ATI ).

Cool jezek! I understand your concerns and you have my respect My offer still stands, just let me know at any time if you think I could help!

Thanks for offer. I want to do the website myself (hosting/code-wise), but if you're in a creative mood you can try to look how it could be improved (content, design, logo, etc.). Your contribution is welcome, though as this is subjective thing, also count that I might not like some idea.

Btw, are you by any chance thinking about implementing the continious-step-thing?

Currently it's only partially supported in original Bullet, and interaction between rigid bodies is non-existent. But it seems it will be improved in upcoming new versions. This is definitely thing that I want to port when it's ready

You're right that more core developers would be really nice, but the problem is, that I feel that not much developers are interested in doing this kind of work. I somewhat always do the hard things that others don't have energy to put on, like this task of porting huge amount of C++ code to Java, it also requires quite good knowledge of both languages.

Well I had to do the exact same thing porting ODE for JOODE.

Your attempt seems to be taking off pretty well. Can you tell me the features of JBullet?

What is the integrator?What is the constraint satisfaction technique? And how does it cope with redundant constraints like a door with two hinges?

Can you retrieve the actual forces used to enforce constraints?

Tom

Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.

What is the integrator?What is the constraint satisfaction technique? And how does it cope with redundant constraints like a door with two hinges?

Can you retrieve the actual forces used to enforce constraints?

You should rather post these questions to original Bullet forum, I'm not a physics guy I'm more an user, but willing to see what is behind to better understand whole problem and it's specifics as every abstraction is leaking implementation details. Bullet is nice in it's object hierarchy, allowing using just stuff that you need and it even doesn't have to be for physics. As a nice side effect of porting I have much better whole image of internals, something that's very useful when implementing it for my purposes or possibly extending it.

I'm not involved with Bullet, but I'm pretty sure it uses most of the same techniques (at the core) as Box2d - they both solve constraints with sequential impulses and warm starting. Forces should be available quite easily by pulling the warm starting values (there's probably a function to get the constraint force, or maybe you can get it from a callback), and redundant constraints should require no special treatment (iterative solvers don't have problems with redundant or inconsistent constraints because they apply constraints one at a time, though this can become unstable in some cases). The integrator is probably symplectic Euler, though I could definitely be wrong there.

If and when continuous collision detection comes back, Bullet's approach is conservative advancement using GJK for nearest point distance calculations. Can't wait for that to show up (or rather, be brought back - it used to work, I think), it's the killer feature that makes me love Box2d over all other 2d physics engines, it will be awesome to have it in 3d, too!

Bullet does not offer me a way of getting at the forces exerted by the constraint though (that I could find anyway). Its not as easy as unwrapping it from the solver though, because the info at the solver level has allready integrated geometry information. So you would have to transform the info back out again to determine the force exerted by an anchor at a specific location (not a hard transformation admittedly, but someone has to write the transformation and the callback option for the solver).

Shame to hear the curvey collision detection is not currently working. That was the thing I liked most about Bullet.

Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.

My game API uses my own modified version of Hiranabe's vecmath (the API allows people to create their own Artificial Intelligence modules). It provides mutable, read only and immutable Vector3f:s, Matrix3f:s, etc., with a small memory footprint and, I think, no significant impact on performance. I think it is largely backwards compatible with Hiranabe's and Sun's versions.

Yeah I know it. I'll probably distribute it instead of the Sun's mainly because of license (Sun doesn't allow GPLv3 usage with it's GPLv2 only+classpath exception and usage of the older non-GPL license with GPL is in grey area).

My game API uses my own modified version of Hiranabe's vecmath (the API allows people to create their own Artificial Intelligence modules). It provides mutable, read only and immutable Vector3f:s, Matrix3f:s, etc., with a small memory footprint and, I think, no significant impact on performance. I think it is largely backwards compatible with Hiranabe's and Sun's versions.

I'm interested in your approach. I've been myself experimenting with different ways how to handle vecmath library, but in the end found Sun's vecmath approach the best. Could you share JavaDoc or something (can be privately by e-mail)?

That's probably best option, the other option is to convert between Sun's vecmath and yours (which is not much problem as physics tends to be quite separated from other things anyway). There exist many vecmath libraries (mostly private/custom) and it would be impossible to support them.

I'm interested in your approach. I've been myself experimenting with different ways how to handle vecmath library, but in the end found Sun's vecmath approach the best. Could you share JavaDoc or something (can be privately by e-mail)?

/** * Interpolates this {@code KeyFrame} and {@code target}, * and places the result into this instance. * @param amount how close to {@code target} the resulting key frame should be. In [0, 1]. */publicvoidinterpolate(KeyFrame<L> target, floatamount) {

I think that the overhead is minimal and shouldn't be problem because if you need to have many vectors (like 10000 or so), it's better to store them in float[] array or FloatBuffer and do bulk operations on it anyway.

I think it would be better to move the exception generation in _checkWritable() to own private method, so you get better chance to inline in HotSpot. Also for better clarity, it would be better to always use descriptive private static final field as key, instead of reusing some array, as it can get messy when the code evolves.

How do you handle direct operation on x,y,z fields? Did you make them protected and provide setter/getters or are they naked as in original vecmath?

I see slight problem with side effects in your approach. For example you return some vector, the caller is using it for some computation and calls some other method which changes the same instance and suddendly caller is using different data. This kind of unintuitive behaviour is very dangerous. Or when they store the instance somewhere else for later usage

On the other hand it gives nice degree of safety for performance sensitive code and could be fighted by stating everywhere that the returned vectors are meant only for intermediate usage.

Personally I still like better the output parameters and shifting up the care of allocation to the caller, as it's more intuitive and less error-prone, though some more copying will happen and you need to pass the out parameter which can be annoying sometimes

I see slight problem with side effects in your approach. For example you return some vector, the caller is using it for some computation and calls some other method which changes the same instance and suddendly caller is using different data. This kind of unintuitive behaviour is very dangerous. Or when they store the instance somewhere else for later usage

That's a good point.

I don't, however, expose such function calls to the end users of my application (= artificial intelligence (AI) module writers).((The KeyFrame code snippet in my previous post is from a game internal class (private class loader).))

However, the values of read-only variables (read-only from the AI module's point of view) do change. But at well-defined points in time:In my application, the simulation state (rotations, locations etc. - lots of Matrix4f) is copied to a snapshot. The AI modules then do computations based on that snapshot of the simulation. After a while, the AI modules are done thinking. The snapshot is then updated with new simulation data: The same instance of e.g. a Vector3f is updated with new simulation data, although it is read only all the time, from the AI modules' point of view.

And you're right that other users of the math lib could write unintuitive code in the way you described.

Personally, when constructing game internal stuff visible to no one but me:Were it not for read only instances, I might, for the sake of performance, or for the sake of laziness, expose mutable Vector3f:s etc., for read access only (without enforcing read-access-only). I believe I here would find the lock-unlock-lock approach safer.

Personally I still like better the output parameters and shifting up the care of allocation to the caller, as it's more intuitive and less error-prone, though some more copying will happen and you need to pass the out parameter which can be annoying sometimes

Yes, I might actually also like the original vecmath approach better. After all, x,y,z are still directly accessible, and the code is simpler to understand.

Actually, since JBullet does lots of direct access to x,y,z and it seems to take long to rewrite and perhaps maintain all such changes in a separate vendor branch,I'll probably ditch the read-only etc. stuff.Then I'll save lots of time; I haven't really started using that read-only fancy-fancy stuff yet, only at one place (the code snippet in my previous post).

And in the future, when HotSpot does escape analysis, I suppose all such read only stuff will be fairly pointless.

I tried to add some restrictions to rigidBodies within an InternalTickCallback.Especially I tried to restrict the Z-movement of moving sphere on a surface ground to avoid jumping because of xy-torque or gravity in combination with full restitution. Because I need full restitution for collsion with static objects with the xy-layer, but not in the z-layer.But my tries-outs didn't work not or causing strange collision detection behavior after changing the interpolated transform of a rigid body. Perhaps the strange effects are caused, because the rigidBodies are overlaping before the moment of the transform is changed. My current work around solution is to restrict the active transform not within the internal tick callback, instead I simply perform rigidBody.setWorldTransfrom() as postStep.

Concerning predictIntegratedTransform.I thing predictIntegratedTransform is a Bullet internal function that you should/need not use.

Concerning getMotionState().setWorldTransform.Directly after internalSingleStepSimulation(),(from whichinternalTickCallback.internalTick(this, timeStep);is invoked),synchronizeMotionStates();is invoked-- and it overwites whatever you've written to your motion states.So I think you cannot use getMotionState().setWorldTransform(activeTransform) from inside the internal tick callback.

Concerning CollisionObject.setWorldTransform.It seems that before [the first time the actual step is done, and your-internal-tick-callback is invoked] each DynamicsWorld.step,the CollisionObject.worldTransform is overwritten with the MotionState value (if you use MotionStates).From inside DiscreteDynamicsWorld.saveKinematicState(...).So, if you use MotionStates, and invoke CollisionObject.setWorldTransform from inside the internal tick callback, then I think the CollisionObject.setWorldTransform call has no effect (unless many internal ticks happens each DynamicsWorld.step; then, it'd have effects sometimes only), since whatever you've written to CollisionObject.worldTransform will be overwirtten by the MotionState's world transform in the next call to DynamicsWorld.step.

CollisionDetectionDemo - Please can you help a complete newbie to get this code working

I have tried to implement the bullet CollisionDetectionDemo.cpp as a java demo along the lines of the other jbullet demos. Unfortunately I am new to jbullet, don't know either c++ or openGL, hence I am stuck!

This software is provided 'as-is', without any express or implied warranty.In no event will the authors be held liable for any damages arising from the use of this software.Permission is granted to anyone to use this software for any purpose, including commercial applications, and to alter it and redistribute it freely, subject to the following restrictions:

1. The origin of this software must not be misrepresented; you must not claim that you wrote the original software. If you use this software in a product, an acknowledgment in the product documentation would be appreciated but is not required.2. Altered source versions must be plainly marked as such, and must not be misrepresented as being the original software.3. This notice may not be removed or altered from any source distribution.*/

to improve JBullet development I've decided to raise funds using donations (using PayPal). This way I'll be able to work on JBullet more and catch-up with latest versions provided there will be enough money raised. For more information visit JBullet's homepage here.

Current plan is to port changes from current 2.70-beta1 to 2.70 final (this includes some classes still on 2.66). The next step will be porting changes from 2.70 to 2.74. This will very likely also include porting of soft bodies feature.

You initial aim (€1000) will probably only be reached when devs absolutely need this work in they day job, and can convince their boss to invest in a risk: you might or might not be able to 'fix' it, in the timespan allocated for a specific phase in their project.

Don't get me wrong, (and I very well might be wrong...), but it might take a few... years?

"The author created this library and is doing the porting for a reason: he uses it in his commercial projects."

May I ask, are those projects going well? You don't work with those projects for a living do you? (But on your spare time)If you have a Web page it would be interesting and fun to read about them.(But I understand that you might not want to publish information on those projects before they're finished.)

May I ask, are those projects going well? You don't work with those projects for a living do you? (But on your spare time)If you have a Web page it would be interesting and fun to read about them.(But I understand that you might not want to publish information on those projects before they're finished.)

Yes they're going well so far (ok by schedule with "development overhead constant" accounted, which is about 2.5x than time previously thought, but as we're development company and have plenty of experience in other projects we knew this from beginning ) and I do them for living although we have to finance them from other income as they're in development few years and not really usable until nearly finished.

Currently no public information exist, but it's game related so I'll announce it here too when done

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org