I’m currently thinking about setting up the master simulation in the server, so it doesn’t need to connect to a scene graph.
As far as it seems to me, JME’s physics controllers are mainly tasked with synchronizing scene graph and physics space. If I’m right (and please correct me if I’m wrong!), then the controller classes carry overhead that I don’t need (and that might give me too pessimistic results when doing performance tests).
So… if I’m to set up a physics space with a lot of randomly floating box shapes, and want to set up a few spherical shapes that test which boxes are inside and which are outside, what are the classes and packages that I should look at first to have a lean-and-mean server?
Of course, if there’s a tutorial that I overlooked, I’d be happy to follow pointers, too.
I’m seeing two groups of classes there, PhysicsControls and CollisionShapes.
Are the CollisionShapes the right ones?
What’s the best way to create these - just use the constructors, is there a factory I should use?
(It seems that the “CollisionShape Code Samples” section creates shapes from Spatials, so I wasn’t sure whether these examples really apply to the use case.)
You missed the base objects that the controls base on, thats basically the objects as they are in bullet, without any connection to the scenegraph. Please do read the page I linked.
The content of this post is meant to be read as a straight information or question without an implicit dismissive stance or interest in having the other party feel offended unless theres emotes that hint otherwise or there’s an increased use of exclamation marks and all-capital words.
“Technical Overview”. They are the parent class of the controls, hence describing them separately would be redundant info. I guessed java developer should see the inheritance tree.
The content of this post is meant to be read as a straight information or question without an implicit dismissive stance or interest in having the other party feel offended unless theres emotes that hint otherwise or there’s an increased use of exclamation marks and all-capital words.
No, subclassing collision shape classes doesn’t make much sense. Subclass to what anyway? Is the text that unclear :? It talks about the connection between collision shape and physics object directly. Apart from that all of the jME bullet api works just like normal bullet, so I suggest trying and understanding the concepts of bullet first before extending any classes of it…
The content of this post is meant to be read as a straight information or question without an implicit dismissive stance or interest in having the other party feel offended unless there’s emotes that hint otherwise or there’s an increased use of exclamation marks and all-capital words.
No, I’m not going to extend Bullet with subclasses, I meant the existing subclasses of CollisionShape. (Heh. A Java programmer should see the inheritance tree, right? SCNR)
The text is mostly clear, I’m just verifying that I didn’t misunderstand or overlook anything.
(The text might be clarified a bit by making a distinction between “this is raw bullet” and “this is scenegraph integration”.)
So:
Should I use BoxCollisionShape/CapsuleCollisionShape etc.?
If yes: Should I just use the constructors, or is there a factory somewhere that will handle relevant aspects?
Seems like the text is unclear… You want to make fun of me, right? If not, the rest of the linked doc describes all that…
The content of this post is meant to be read as a straight information or question without an implicit dismissive stance or interest in having the other party feel offended unless there’s emotes that hint otherwise or there’s an increased use of exclamation marks and all-capital words.
Yeah, but with a “naked” PhysicsSpace @kwando
The content of this post is meant to be read as a straight information or question without an implicit dismissive stance or interest in having the other party feel offended unless there’s emotes that hint otherwise or there’s an increased use of exclamation marks and all-capital words.
Care to read the document I linked?
The content of this post is meant to be read as a straight information or question without an implicit dismissive stance or interest in having the other party feel offended unless there's emotes that hint otherwise or there's an increased use of exclamation marks and all-capital words.
I would still use the scenegraph on the server, but not render anything obviously. I believe there is a Application context called Headless for just this purpose. Then just use a BulletAppState for your physics like all the tutorials show. Otherwise you’re going to have to recreate a lot of plumbing to get a pure bullet physics space working.
I can’t imagine there being much performance difference between the two approaches.
@aaronperkins said:
I would still use the scenegraph on the server, but not render anything obviously. I believe there is a Application context called Headless for just this purpose. Then just use a BulletAppState for your physics like all the tutorials show. Otherwise you're going to have to recreate a lot of plumbing to get a pure bullet physics space working.
I can’t imagine there being much performance difference between the two approaches.
I indeed use a BulletAppState, it doesn’t assume a scene graph
I wouldn’t expect much plumbing if I didn’t use it though. BulletAppState is just 340 lines, and if you discount that plumbing for a specific application can always be shorter than the generality that a library must cater for, it could be far less.
On perfomance: There is little universal advice on the topic, but all sources agree on this one: Don’t assume, measure.
A lot depends on how much Bullet actually does. If it’s burning a lot of CPU cycles per object (many contact points, large clusters of connected and interacting objects), then the Java-side overhead should be small in comparison; if Bullet does very little per object, then the Java-side overhead could become noticeable.
In my case, I’m trying to limit Bullet to “mostly geometric queries and a handful of contact points”. If Bullet is as good at that as it claims to be, the scene graph overhead could become relevant. It’s one of the things I want to measure
I guess you could use a PhysicsSpace directly, but your giving up AppStates and Controls which I think is one of the nicest design features of JME.
Measure all you want, but my educated guess says that having a scene graph attached simply means that JME Spatials are being updated by the Bullet every physics tick and this would be a very small performance hit in any scenario. We are only talking about a position and rotation update per object per physics tick.
So to answer your question.
Use the PhysicsSpace directly .
Add Shapes that correspond to your game entities. I don’t see any reason to create your own shapes.
Call PhysicsSpace.update().
Get the new position and rotation values for your entities and sync with your clients.
I’m not giving up AppStates, I’m still using a BulletAppState. I’m avoiding the controls because they just translate between bullet and scene graph and I don’t have a scene graph.
Maybe a little background is in order. The game data needs double coordinates to be represented properly, and the scene graph uses floats, so I can’t use the scene graph anyway.
Also, the hardest part of the game is making some geometry tests fast. Bullet promises to offer that, so I’ll want to keep the geometry data in bullet. (I’ll also need to rebuild a double version of bullet, but that’s still far less work than building your own fast collision testing library.)
Thanks for the advice, it confirmed what I had arrived at (and confirmation is good).
FWIW, here are the details where I diverge:
I’m still using a BulletAppState. AFAICT it’s a thin wrapper around a PhysicsShape, tasked to run the PhysicsSpace in sync with the interactive app. Which means it’s useful now because I’m currently running stuff inside an interactive app, and I might drop the BulletAppState (or keep it, depending on how much of JME’s infrastructure there will be in the server - haven’t decided on that yet).
Shapes aren’t enough, it seems that there are also PhysicsObjects. My current best assumption is that Shapes are reused across PhysicsObjects, and it’s the PhysicsObject that has an actual position inside Bullet, not the Shape. I’ll have to experiment to see whether it pans out, the web page doesn’t mention them and Normen has been withholding this bit of information (I’m rather angry at him for that, he should have concentrated on finding out what I need instead of repeating essentially useless RTFM advice - I did RTFM, absorbed most, and overlooked a few details, as is normal, but somehow he’s expecting me to understand everything on my own… ah, sorry, I need to get out of rant mode again; trying to force me into some preconceived notion of what I should do regularly brings out the worst in me, I love advice but I hate force, and Normen seems to be unable to give the one without trying the other so we often get into a catfight).
I agree there’s no reason to create one’s own Shape. It was never my plan to subclass CollisionShape (that would require extending Bullet to handle it, and that’s really too large as a subproject). I’ve been planning to use the existing subclasses: BoxCollisionShape, ConeCollisionShape, maybe CompountCollisionShape, etc. (Oh, sweet, there’s also the ConeCollisionShape. I’ll be wanting that.)
Awww, poor toolforger, I force you to do stuff all the time… Like wrap your mind around stuff and so on. And then just mentioning what the info is and not the exact line. Really, I’m mean. Luckily you were in fact able to obtain the information yourself, phew.
This post is intended to be read as completely sarcastic and dismissive.
