Is there a way to get the physics engine to basically just ignore Z in terms of collisions? In the games I am making, I am using 3d graphics and things, but the actual game play takes place in a plane, as such one possible thing we could do for efficiency and convenience, is just ignore Z when doing collisions. Does the feature to reduce the number of dimensions considered exist?
I don’t even know what you mean by “ignoring z for collisions” :? You mean so that the objects do not collide when they move in z direction? Then everything would fall through the floor…? Do you mix up physics and collision somehow? They are closely linked but not the same. As for physics, you can only lock the effect of rotation by setting the angularFactor to 0. You can not set the linearFactor per axis, that will be possible when we move to native bullet completely.
@normen said:
I don't even know what you mean by "ignoring z for collisions" :? You mean so that the objects do not collide when they move in z direction? Then everything would fall through the floor..? Do you mix up physics and collision somehow? They are closely linked but not the same. As for physics, you can only lock the effect of rotation by setting the angularFactor to 0. You can not set the linearFactor per axis, that will be possible when we move to native bullet completely.
I basically mean a sphere would be treated like a circle, or if one kept thinking about it in 3d it would be treated like a cylinder with an infinitely tall z component. Is there a 2d version of the physics engine?
I'll explain the game a little better: It's a space game with 3d graphics but 2d physics, so you only move around in the z=0 plane. Any Z motion is more of a special ability if used at all.
Okay so there is a native bullet functionality for ignoring an axis component in the effect of a collision? That's cool, I'll use dirty hacks until it gets fully integrated ;)
What I'll probably do is gravitate objects towards a target height or something and attempt to seamlessly drop or raise them to that height if they get knocked or shot out of the plane.
Do you mean collisions or positioning things?
If you mean positioning things, in the update loop I just set the position (and, if necessary, the rotation) so that nothing moves out of the plane.
If you mean collisions, and you only have one 2D plane, then trying to mess around with a 3D physics system to get it to work like a 2D physics system is going to be a needlessly large amount of work for marginal (if any) gains in performance.
Otherwise, do you mean you have multiple 2D planes? If so, there are better ways to handle that (collision groups, making cylinder collision shapes that won’t cross over into the next plane).
Personally I’d rather use a dedicated 2D physics engine like Box2D and use jME for graphics. You’d have to find a good way to pass data from the physics engine thread to the jME render thread. A bit of work but maybe easier in the end than trying to force a 3D physics engine to 2D.
2 Likes
Don’t know if this applies to others, but I had considered using a 2D physics engine (specifically Box2D) with 3D graphics, but then you wouldn’t be able to have things rotating in 2 of the 3 axes: if you do, what appears on screen and the physics collision shapes won’t match up.
gave u a -1 by accident (wasn’t even meant to rate it) can someone correct please, n thanks
edit: thanks
Yeah, I’m not too worried about any of this stuff, there are a bunch of easy fixes, I was just wondering if there was a simple way to change a few booleans and hey, now jBullet can treat collision as if it is in 2D. It seems like after it gets more integrated then there might be, but it doesn’t impede me that much that the functionality isn’t there.
I just need to figure out how I want the weapons to work basically. I can actually aim them in 3d (which would require precision, I might want to make the bullets larger so it’s easier to hit with them if I do that), I can try to position more things in the z=0 plane, I can make bullets and other objects fall towards z=0, I can make the collision objects cylinders instead of spheres. Plenty of easy fixes.
@normen said:
You can not set the linearFactor per axis, that will be possible when we move to native bullet completely.
Can you tell me any more about this moving to native bullet thing? Is jmonkey's physics in kind of an intermediate state right now, and in the future maybe there won't be spatial and then rigidBody, there will just be one object with a boolean that physics is enabled or...?
@jmaasing said:
Personally I'd rather use a dedicated 2D physics engine like Box2D and use jME for graphics. You'd have to find a good way to pass data from the physics engine thread to the jME render thread. A bit of work but maybe easier in the end than trying to force a 3D physics engine to 2D.
I don't really want everything to be 2D, I just want a few 2D features. The ability to shoot things up and down a bit for a mortar-style effect would be nice, and I definitely want to be able to rotate in three dimensions for at least visual effect.
@yuxemporos said:
Can you tell me any more about this moving to native bullet thing? Is jmonkey's physics in kind of an intermediate state right now, and in the future maybe there won't be spatial and then rigidBody, there will just be one object with a boolean that physics is enabled or...?
Who gave you that idea? No, there won't be much of a change at all for the user.
@normen said:
Who gave you that idea? No, there won't be much of a change at all for the user.
I was just thinking of what could happen and that was one thing that popped in my head.
So what is happening with the bullet system? It is currently partially implemented or code wrapped? What will it be like when it is "native"?
@normen said:
Like I said, it will be the same as it is now. You can already switch easily by swapping a jar file and android projects automatically replace jbullet with bullet.
http://hub.jmonkeyengine.org/2011/04/27/jme3-native-bullet-physics-is-available-for-testing/
Ah, very interesting. Thank you. I'll have to go over the native feature list and compare to what we already have.
@yuxemporos said:
I was just thinking of what could happen and that was one thing that popped in my head.
So what is happening with the bullet system? It is currently partially implemented or code wrapped? What will it be like when it is "native"?
Like I said, it will be the same as it is now. You can already switch easily by swapping a jar file and android projects automatically replace jbullet with bullet.
http://hub.jmonkeyengine.org/2011/04/27/jme3-native-bullet-physics-is-available-for-testing/
@yuxemporos said:
Ah, very interesting. Thank you. I'll have to go over the native feature list and compare to what we already have.
All features are there but not all bugs out :)
@normen said:
All features are there but not all bugs out :)
Yeah I understand that. I'll think if/when I decide to switch. Wouldn't want to create more problems than I'm solving.
I’ll just answer inspite of being a very old post, since it is top on Google when searching for 2d physics jmonkeyengine.
What I did was to extend RigidBody (and BetterCharacterControl) and Z=0 in the update loop. Like so:
class RigidBody2DControl extends RigidBodyControl {
RigidBody2DControl(float f) {super(f)}
public void update(float tpf) {
super.update(tpf)
Vector3f loc = this.getPhysicsLocation()
loc.setZ(0f)
this.setPhysicsLocation(loc)
}
}
class BetterCharacter2DControl extends BetterCharacterControl{
@Override
public void update(float tpf) {
super.update(tpf)
Vector3f loc = rigidBody.getPhysicsLocation(location)
loc.setZ(0)
rigidBody.setPhysicsLocation(loc)
}
}
Seems to work:
