Lots of Physics

I do not understand the question. If you want to position your PhysicsNodes you will have to do so, theres no way around it even if its lots of them… What exactly is your problem?

I'd like a more efficient way of positioning my Blocks than creating a node for each. It may not be a big deal (I'm new to this), but it doesn't seem like the best way of handling the problem to me.

The only other way would be creating one big mesh that consists of all the single boxes and modifying that. Then you have only one object but eight times as many locations to update (the corners of the boxes).

If you want each box to be a PhysicsNode then this will not work however. If you want the whole thing to be one PhysicsNode (like a floor or something) it would be the only way to go. But then you should create some algorithm that simplifies the box-mesh after it has been created and before you compute the physics collision shape from it.

I do not quite understand your approach here, if you try to do some voxel-like thing where the 3d world does not consist of hollow meshes but of little "atoms" then forget about it. This way it will be way too computation and memory intense.



Ok. So you already have all those objects and want to be able to move them. If you want them to be movable physics objects you will have to do as you indicated in the first post, there is no way around that.

I'd suggest you create one BoxCollisionShape and use that to create all the PhysicsNodes that wrap your current box spatials (they are all the same size right?), this way you will save memory and some cpu cycles.

If you use the svn version of jbullet-jme (theres instructions on how to build it on the googlecode page) then I suggest using kinematic nodes (normal PhysicsNodes where setKinematic(true) has been called). Then they will not be affected by physics but affect the objects around them when they are moved and collide with them.

If you don't use the svn version you will have to set the mass of the PhysicsNodes to 0 to indicate that they are static (do that in the constructor and not afterwards) but there might be problems when you want to move them after you have added them to the PhysicsSpace.



Edit: maybe you try not to add/remove the physicsnodes but reuse them. if you have to add/remove them use the dvbt broadphase which allows faster adding/removing.

The terrain itself will always be static, and will never move after initial placement (they will be destroyed when removed). All Blocks are of uniform size and shape.

See my edit in the last post. Adding/removing of bodies to the physicsspace takes some time.

normen said:

Edit: maybe you try not to add/remove the physicsnodes but reuse them. if you have to add/remove them use the dvbt broadphase which allows faster adding/removing.

I've never heard of a 'dvbt broadphase,' but it will have to make quite a difference to offset the time it takes to create these object. Building one node per Block takes the initial Build phase from less than a second to almost a minute. If I have to, I'll just do dumb collision checking each update for the movement, but a full physics engine is attractive...

There really isn't any possibility of reusing the Nodes, since this performance hit occurs at the initial terrain generation.

You can set the broadphase when creating the PhysicsSpace:

PhysicsSpace pSpace=PhysicsSpace.getPhysicsSpace(BroadphaseType.DVBT);