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
I definitely need more people using this to squish the last bugs and verify that everything is "there" and accessible. So please keep reporting.
I hope at least some of you are testing jbullet-jme 0.9alpha thoroughly already. I have been using it for some time now in my project and commited some small bugfixes to the svn but everything seems to work just fine.
I am currently working on the native implementation of jbullet-jme and I recognized something about the API of jbullet-jme that maybe should be changed. Right now, there are public methods for example in PhysicsNode to access the internal jbullet objects. Now, these are not supposed to be used by jbullet-jme users since in the native version they become just "long"s pointing at the native RigidBody etc. and so using them makes your jbullet-jme project incompatible to the native bullet-jme.
Currently, they have inviting names such as getRigidBody() or getCharacterController(). I'd like to change their names to something a bit more cryptic so the users attention does not get drawn on them so much. Or do you think it is obvious from the javadoc and return types that these are not to be used?
Another thing is, I need somebody to check if building of the native binaries for bullet-jme on windows and/or linux is working using my ant script. Not much is working yet in the native version but I'd like to have working build scripts for all platforms
So if anyone wants to try, please download using svn:
Are there any thoughts on adding the capabilities (or at least a demonstration) of using the JME terrain for this physics implementation?
That would be a nice test but it would require me to include the jme data classes to the project, or is there something in the jars I already included? Anyway, if I understand correctly what you want it is already working. In my project I have a terrain that I can drive on with a vehicle, heres the code (just a quick cut and paste);
Hmm,...at the very beginning you provided also the jbullet-source-code. Would it be possible
to attach this like javadoc as archive as well?
Since I did not change anything in the jbullet source yet I do not see the sense in doing that. One can download the source from the jbullet website and monotone repository. I can send you the current monotone source if you dont want to install monotone, just PM me.
why not just include the bullet compiled binaries are part of your updates... :?... this added setup, though explained, and the fact that u are dealin with another language, may put off potential testers i.e me :// :|
why not just include the bullet compiled binaries are part of your updates... :?... added setup, though explained, may put off potential testers i.e me :// :|
Now I know why you got that text below your avatar.. Dude, this is the very first non-working pre-alpha *native* version and I need people to compile the final version for other people like *you* who just want a binary ;) (no offense!) I'm just searching people who can verify that it works and can maybe later compile the final native version for win and linux (I have just macs).
To make it perfectly clear: The java-only version (jbullet-jme) you can already download as alpha on the googlecode page, the native version (bullet-jme) is in the works.
Cheers,
Normen
why not just include the bullet compiled binaries are part of your updates... :?... added setup, though explained, may put off potential testers i.e me :// :|
Now I know why you got that text below your avatar.. Dude, this is the very first non-working pre-alpha *native* version and I need people to compile the final version for other people like *you* who just want a binary ;) (no offense!) I'm just searching people who can verify that it works and can maybe later compile the final native version for win and linux (I have just macs) .
To make it perfectly clear: The java-only version (jbullet-jme) you can already download as alpha on the googlecode page, the native version (bullet-jme) is in the works.
Cheers,
Normen
ah....me see......now og understand.......... og no see when normen first explain this :?..... sorry :P :D
I know this is a lot to ask, but the ways its written currently you can't subclass a PhysicsNode, since the constructor calls for a Spatial to compute the bounds off of. I liked in JME Physics 2 where you could extend the PhysicsNode. Of course this would come at the cost of having to compute the bounds of the node sometime after it is instantiated. I think this would be more elegant than having to keep a reference of the parent physics node in my non-physics node subclass. What do you think?
I know this is a lot to ask, but the ways its written currently you can't subclass a PhysicsNode, since the constructor calls for a Spatial to compute the bounds off of.
Well you can subclass PhysicsNode, its just that you need to implement a constructor with a Spatial or CollisionShape :)
In fact, there could be a constructor without child spatial, it would just have to compute a standard sphere collision shape.. The thing is, I want to keep PhysicsNode and CollisionShape as close as possible, since from the perspective of a jbullet-jme user, one is useless without the other. There should be no PhysicsNode without collision shape.. Anyway, the svn now has a PhysicsNode with blank constructor.
Anyway, the svn now has a PhysicsNode with blank constructor.
Well that's good, but I was speaking a little generically. What I'm really working with right now is the PhysicsCharacterController, so maybe a blank constructor might be necessary for at least PhysicsGhostNode as well.
Well that's good, but I was speaking a little generically.
In the svn now as well, but as I said, a CollisionShape is a necessity when creating a PhysicsNode, even if you add it afterwards, so why have the danger of a PhysicsNode without collision shape? I dont understand why you cannot extend or incorporate the other form in your project?
In the svn now as well, but as I said, a CollisionShape is a necessity when creating a PhysicsNode, even if you add it afterwards, so why have the danger of a PhysicsNode without collision shape?
Yes, I agree. Unless you require a user subclassing, to add the Collision Shape and call buildObject() before adding it to the PhysicsSpace. That way you don't waste the creation of a collision shape (i.e. Box for PhysicsNode, Sphere for GhostPhysicsNode) by just replacing it with another user created collision shape.
normen said:
I dont understand why you cannot extend or incorporate the other form in your project?
I will, don't worry. Just since PhysicsGhostNode and PhysicsNode are rather different, but equal in usefulness, I was thinking that they both should have a blank constructor.
I'm really starting to like this engine, especially it's ease of use. Keep up the good work. :D
Unless you require a user subclassing, to add the Collision Shape and call buildObject() before adding it to the PhysicsSpace.
Ah, I see.. Your Node wants to have its own constructor and not have to imitate or call a constructor with a CollisionShape because its more than a PhysicsNode, sure.. Coding styles.. Personally, I like to wrap objects rather than extend them to avoid lots of overloading, so I didn't even think that way :) See, thats what the internet is for :D
Just a quick update bump to maybe catch some more alpha testers…
I extended the wiki massively and the new 0.9.3 alpha version has some more fixes and additions. Everybody who wants to test, make suggestions, give hints, extend the wiki or even extend the jbullet-jme code is very welcome to do so.
I am currently doing a small racing game to test/highlight the functions of jbullet-jme, still a lot to do but heres a first view: Youtube video
Cheers,
Normen
P.S.:
If anybody has some C++ skills, I started the native version but theres still a lot of work to do, mostly mindless method wrapping. Basic movement of bodys etc. is working and highlighting the way on how to do stuff and theres some hints on the wiki developers page.
Since I am currently working more on the java implementation and falken needs all the sleep he can get for his family, everybody who wants to see a native version dearly can help implementing it