Santa left something special under the tree this year:
A brand new physics library for jme2!
Introduction
I was trying around with the current jmephysics2 and as everyone knows, it is plagued by bugs in the native ODE implementation. Falken is doing a really good job with adapting jbullet to jmephysics2 and I tried around with that but after looking into jbullet and jmephysics2 I found that the adaption will always limit jbullet and its possibilities.
So, I planned to implement a jbullet wrapper for my own projects to use more of its capabilities… jbullet-jme was born.
I think that this would be a great addition to jME. I have one a couple small recommendation, don’t nest repositories like you have currently, especially if they are of different types! Don’t include all the basic jME stuff in the repository, as it just adds to wasted disk space ( not everyone has that sought after 1TB laptop hardrive! ). If you are going to include the jbullet monotone repository with your update shell script, you need to include the “jbullet.mtn” database so users can use it! There is also duplicate jME entries in your repository, so when checking it out people get several jME distributions ( it does not matter if they are the same, you don’t need 2, well 3 if you count the one people already have! ). I recommend moving the dependencies into 2 separate zip archives “jbullet.zip” and “jME.zip”, that way people can download them as needed and can get right to the source you are trying to present here!
Great contribution normen! Way to use the source to make the source
Your issues list looks pretty thorough to me… I'm curious about your difference in philosophy with the jmephysics project… I've got no stake in either, just being a curious george
If you are going to include the jbullet monotone repository with your update shell script, you need to include the "jbullet.mtn" database so users can use it! There is also duplicate jME entries in your repository, so when checking it out people get several jME distributions
Thanks for the hints.
I put the source of jbullet in more as another branch since I dont know if I encounter bugs in it and if the original gets updated in the future. I tried to contact jezek but he didn't answer yet. Currently theres no changes in it but that may change, maybe I will put it in the trunk folder then. Currently its just there for "backup".
Is there really several JMEs? Lwjgl is also included in the jbullet source folder, that is true but JME is there only once as far as I know.
sbook said:
I'm curious about your difference in philosophy with the jmephysics project.. I've got no stake in either, just being a curious george
I explain some of that in the googlecode-wiki. jbullet-jme is basically tied to bullet while jmephysics is a more general wrapper.
I try to "simplify" or "unify" some of jbullets/bullets concepts while still being quite close to the original implementation. So I kind of have jme-objects that have bullet functions.
Still, I try to have the physics as separated from the jme part as possible (internally), so one can multithread/be careless on the jme side.
Is there really several JMEs? Lwjgl is also included in the jbullet source folder, that is true but JME is there only once as far as I know.
Sorry, that is what I meant. Anyway I hope you didn't think I was being picky, just trying to future proof your project to make it easy to integrate into existing projects, by only having your source in the repository.
Anyway I hope you didn't think I was being picky, just trying to future proof your project to make it easy to integrate into existing projects, by only having your source in the repository.
No problem. I intend to make downloadable releases including only the necessary jbullet jars etc. available as soon as the whole thing is release-worthy. I currently code on two computers and so I use svn to have all stuff on both sides.
And personally, I like having all the libs in the svn already, so I dont have to link around / download libraries and always use the same library version as the developers to compile the project. Also, like this compiling works out of the box. If one really wants to integrate only the source into a project, theres always the possibility of svn-ing just the jbullet-jme/src folder.
But you are right about the nested jbullet source, I think I will just take it out of the repo and add it again in the trunk folder when I really change something in it.
I was trying around with the current jmephysics2 implementation and as everyone knows, it is plagued by bugs in the native ODE implementation. Falken is doing a really good job with adapting jbullet to jmephysics2 and I tried around with that but after looking into jbullet and jmephysics2 I found that the adaption will always limit jbullet and its possibilities.
So I have to ask, how closely have you been in touch with Falken during all of this new development? From your brief reasoning here, I get the feeling you and Falken are of the same opinion in a technological interest. He too decided to start a lot of work from scratch. Last I heard, he was attempting to completely rework JMEP2's API.
Are you in conflict with the very concept of jMEPhysics?
In any case, don't think I'm not extremely happy to see this work being freely distributed to the community, it's great! A merry Christmas to you, and many thanks for the swell surprise gift.
normen wrote:
P.S.
I put the whole thing under the BSD license and put jMonkeyEngine as the copyright holder (its a christmas present after all ;)) but if that is a problem, I will take out the jMonkeyEngine reference.
Since jMonkeyEngine is not registered as a trademark nor organization, by stating jMonkeyEngine as the license holder you're basically licensing it to nobody ;) jmonkeyengine.com is a registered name, but I would suggest you just put yourself up as the copyright holder seeing as the New BSD doesn't put any restrictions on the code for anybody regardless.
First of all, thanks to everybody. I forgot to mention that in the previous posts
erlend_sh said:
So I have to ask, how closely have you been in touch with Falken during all of this new development? From your brief reasoning here, I get the feeling you and Falken are of the same opinion in a technological interest. He too decided to start a lot of work from scratch. Last I heard, he was attempting to completely rework JMEP2's API.
Are you in conflict with the very concept of jMEPhysics?
I was not in close contact to Falken since the project started basically as a wrapper just for myself. Most of what falken knows about jbullet is in the source of jmephyiscs anyway ;)
I was digging into the api of jmephysics and as stated in the wiki, I found that the concepts of jmphysics and bullet are so incompatible that there will always be quite some compromises to make (e.g. joint properties/functions). The last time I saw Falken posting something about a *new* jmephysics api he suggested that he would build it for jme3, and keep the jme2 physics api as it is: http://www.jmonkeyengine.com/forum/index.php?topic=12528.15
The "conflict" maybe lies in the fact that I want to be able to integrate bullet physics, not physics in general. I think this way it will be easier to integrate more powerful functions of bullet without having drawbacks due to a "generalized" api.
I did not ask falken to join or let me join in his development since its not really possible to work together in the beginning of such a project and frankly, talking about "concepts" via the forum or email would have strained my patience in getting some physics to work properly ;)
Anyway, as stated, the project here is not set in stone, as soon as I have implemented all things I still want/need to, everybody is welcome to participate in making it even better. If it gets overshadowed by a new jmephysics3 for jme2 and jme3 then be it so.
The "conflict" maybe lies in the fact that I want to be able to integrate bullet physics, not physics in general. I think this way it will be easier to integrate more powerful functions of bullet without having drawbacks due to a "generalized" api.
Very big thumbs up to that sentiment. At this point, I think such integrations are actually far more useful to the JME community than the generalized one I'm hoping to work on.
In the meantime, where you're starting seems as good a place as any. I haven't had a chance to look at the code yet (my new son just arrived two days ago! free time is now a distant memory) but from a conceptual standpoint, I think you're headed the right way.
And actually, I've done a LOT of digging into Bullet and JBullet in ways that I haven't had a chance to integrate into the jmePhysics code, so if you ever have questions, feel free to ask. I think my knowledge / advice may be more useful to you than any direct involvement at this point
So good luck on your integration. I'll contribute as much as I can!
Very big thumbs up to that sentiment. At this point, I think such integrations are actually far more useful to the JME community than the generalized one I'm hoping to work on.
In the meantime, where you're starting seems as good a place as any.
Thanks for the comments.
Good to hear you think similar to me.. Based on our PM contact, I will add you as a committer to the jbullet-jme project. Even if you dont use the option, you certainly already contributed to the project.
Just a status update bump. I implemented almost everything that I wanted to and things seem to work just fine, except for that darn wheel rotation thing. Since it does not seem like I'm going to change the current API much, I officially change the status to "alpha" now
Just a status update bump. I implemented almost everything that I wanted to and things seem to work just fine, except for that darn wheel rotation thing. Since it does not seem like I'm going to change the current API much, I officially change the status to "alpha" now :)
Cheers,
Normen
um I know its a "basic" test but could u adjust the character test to only move the character while the key is actually down and could explain a bit how to apply rotation to the character
um I know its a "basic" test but could u adjust the character test to only move the character while the key is actually down and could explain a bit how to apply rotation to the character
Yes, the tests need to be extended and refined still. If anyone creates a nice test class, please post it here!
There is code that toggles the applying in the car test, its always a bit complicated to track key toggling, anyone got a hint on how to track just the pressing and the releasing of keys in jme? Not just like "is it down in this tick"? The action thing does not seem to work, there are no actions when the key is released..? Anyway, I can add the vehicle test way of doing it to the character test at some time.
As far as I understand bullet, the character node itself is not supposed to turn. You animate or turn your added spatial/mesh. The CharacterNode is just for collision and location. Thats possibly also why it does only seem to work properly with sphere shapes.
um I know its a "basic" test but could u adjust the character test to only move the character while the key is actually down and could explain a bit how to apply rotation to the character
Yes, the tests need to be extended and refined still. If anyone creates a nice test class, please post it here!
There is code that toggles the applying in the car test, its always a bit complicated to track key toggling, anyone got a hint on how to track just the pressing and the releasing of keys in jme? Not just like "is it down in this tick"? The action thing does not seem to work, there are no actions when the key is released..? Anyway, I can add the vehicle test way of doing it to the character test at some time.
As far as I understand bullet, the character node itself is not supposed to turn. You animate or turn your added spatial/mesh. The CharacterNode is just for collision and location. Thats possibly also why it does only seem to work properly with sphere shapes.
Cheers,
Normen
well I use simple-physics and I dont apply rotation forces in my game either I use the cameras xz direction to turn my character and direct the the forces applied to the attached collider, I just thought that character control would be a bit more complicated in bullet, I know it was a bitch to setup in ode............based on what I read on the forums.
I just thought that character control would be a bit more complicated in bullet, I know it was a bitch to setup in ode............based on what I read on the forums.
The bullet CharacterController is pretty basic, I think its aim is performance with lots of character nodes, not realism, something like simplephysics built inside bullet. Sadly, the jump() method seems to be broken in jBullet.. For something more advanced, I'd suggest building up the character from multiple PhysicsNodes.
I just thought that character control would be a bit more complicated in bullet, I know it was a bitch to setup in ode............based on what I read on the forums.
The bullet CharacterController is pretty basic, I think its aim is performance with lots of character nodes, not realism, something like simplephysics built inside bullet. Sadly, the jump() method seems to be broken in jBullet.. For something more advanced, I'd suggest building up the character from multiple PhysicsNodes.
well I think I'll stick to the simple-physics library for now, since I get it to work correctly in most cases..... if I decide to do some dynamics stuff....falling boxes and such I'll "try" to mix them.......if possible
