Restricting movement of a RigidBody onto an arbitrary plane.

Post Reply
Mako_energy02
Posts: 171
Joined: Sun Jan 17, 2010 4:47 am

Restricting movement of a RigidBody onto an arbitrary plane.

Post by Mako_energy02 »

I am currently working on a 2.5D game that locks rigid bodies to a plane using the Linear Factor on each rigid body. The issue that comes with using this simple feature is that the plane you can restrict movement to using it has to be axis aligned. As the title says, I want to be able to move objects along an arbitrary plane as seemlessly as possible similar to how the Linear Factor allows movement.

Implementing this seems like it could be somewhat straight forward. In the same place that Linear Factor is applied to the calculated force for a rigid body (in the constraint solver), instead of multiplying by the linear factor the movement vector can be projected onto a user defined plane that is object centered and world oriented. Since it is object centered, the plane can be expressed as just a normal.

Now, I have a few questions about this:
1) If I were to implement this, how likely would it be to be integrated into the Bullet library? I really don't want to have to maintain a patch indefinitely, and the issue tracker seems to move incredibly slow(I base this on having a different issue that is 11 months old and has yet to be acknowledged).
2) As near as I can tell, something like this and the Linear Factor is mutually exclusive. Is giving the axe to the Linear Factor out of the question? If so, does prioritizing the arbitrary axis and if it is not set then resort to the Linear Factor sound sane?
3) Is there anything related to this task that I should be made aware of? Has anyone attempted this behavior in this way? Better...is this a feature that exists or is planned already for Bullet 3?
Basroil
Posts: 463
Joined: Fri Nov 30, 2012 4:50 am

Re: Restricting movement of a RigidBody onto an arbitrary pl

Post by Basroil »

Mako_energy02 wrote:I am currently working on a 2.5D game that locks rigid bodies to a plane using the Linear Factor on each rigid body. The issue that comes with using this simple feature is that the plane you can restrict movement to using it has to be axis aligned. As the title says, I want to be able to move objects along an arbitrary plane as seemlessly as possible similar to how the Linear Factor allows movement.

Implementing this seems like it could be somewhat straight forward. In the same place that Linear Factor is applied to the calculated force for a rigid body (in the constraint solver), instead of multiplying by the linear factor the movement vector can be projected onto a user defined plane that is object centered and world oriented. Since it is object centered, the plane can be expressed as just a normal.
All of this really sounds like a bunch of 6dof constraints to the world frame if the planes of each object intersect with any other planes. If the planes are all parallel (or identical), then you might be looking at this the wrong way.
Mako_energy02 wrote: Now, I have a few questions about this:
1) If I were to implement this, how likely would it be to be integrated into the Bullet library? I really don't want to have to maintain a patch indefinitely, and the issue tracker seems to move incredibly slow(I base this on having a different issue that is 11 months old and has yet to be acknowledged).
2) As near as I can tell, something like this and the Linear Factor is mutually exclusive. Is giving the axe to the Linear Factor out of the question? If so, does prioritizing the arbitrary axis and if it is not set then resort to the Linear Factor sound sane?
3) Is there anything related to this task that I should be made aware of? Has anyone attempted this behavior in this way? Better...is this a feature that exists or is planned already for Bullet 3?
1) Only Erwin can tell you that, but it doesn't seem like something that really belongs IN the engine, rather something you apply to your own version of the code.
2) Linear factor isn't really necessary for most code, it's really just there for low cost locking to a plane. In your own code, you could easily have linear factor overloaded for your functionality (needs extensive fixes though, and simple code might run slower)
3) Ever considered just shifting your other axis to the default world ones? If you only have one arbitrary plane you might as well just "turn your head" rather than rewrite everything. If you have multiple planes, you might want to just use constraints.
Mako_energy02
Posts: 171
Joined: Sun Jan 17, 2010 4:47 am

Re: Restricting movement of a RigidBody onto an arbitrary pl

Post by Mako_energy02 »

Basroil wrote:All of this really sounds like a bunch of 6dof constraints to the world frame if the planes of each object intersect with any other planes. If the planes are all parallel (or identical), then you might be looking at this the wrong way.
I have a couple concerns with that. Our objects that are moving along the plane are being manipulated with the mouse via a Point2Point constraint in the world frame. Also important to note is that not all of the objects movement is explicit. The mouse starts a force on the object and then it is released. I'm worried about stability issues/jitter from having the two constraints trying to control the movement. I also am not really seeing how to use the 6Dof constraint to lock to a plane that isn't axis aligned. If I am missing something that makes that happen, please let me know.
Basroil wrote:1) Only Erwin can tell you that, but it doesn't seem like something that really belongs IN the engine, rather something you apply to your own version of the code.
I respectfully disagree. Unless I am missing something fundamental about how this code works (which is why I posted) then this change can be done in ~50 line changes/additions in Bullet2, and ~100 line changes/additions in Bullet3 (way more constraint solvers). I've also seen this feature come up in ~4 threads just from my casual browsing of the forums. I won't say there is such demand that this is mandatory, but to me it would make sense as a core feature.
Basroil wrote:2) Linear factor isn't really necessary for most code, it's really just there for low cost locking to a plane. In your own code, you could easily have linear factor overloaded for your functionality (needs extensive fixes though, and simple code might run slower)
I got the same impression that it wasn't used all that much, but I still figured I'd ask. As stated before, maintaining my own separate code is something I absolutely want to avoid. I don't see how the fixes would be extensive. And yes, simple code will run marginally slower, but not by enough for a noteworthy performance hit on modern machines. Constraint performance worries me more than this does.
Basroil wrote:3) Ever considered just shifting your other axis to the default world ones? If you only have one arbitrary plane you might as well just "turn your head" rather than rewrite everything. If you have multiple planes, you might want to just use constraints.
Keeping things locked to axis aligned planes severely limits the kinds of puzzles that we can assemble. Multiple planes is something we have planned, yes.
c6burns
Posts: 149
Joined: Fri May 24, 2013 6:08 am

Re: Restricting movement of a RigidBody onto an arbitrary pl

Post by c6burns »

I also am not really seeing how to use the 6Dof constraint to lock to a plane that isn't axis aligned. If I am missing something that makes that happen, please let me know.
By using the transforms taken as parameters to the constraint's constructor
Mako_energy02
Posts: 171
Joined: Sun Jan 17, 2010 4:47 am

Re: Restricting movement of a RigidBody onto an arbitrary pl

Post by Mako_energy02 »

c6burns wrote:By using the transforms taken as parameters to the constraint's constructor
More details would be helpful. My understanding of how those transforms work is somewhat limited, specifically in regard to the orientations as I usually leave that part of the transform as identity. What limited details I can guess at the moment is that would be the orientation in local space to use for constraint movement. An immediate problem I can think of with that is that the objects being thown are able to freely rotate about. Only translations are locked. So if it rotates and the constraint is using local orientations of the object it is bound to, then wouldn't it re-orient the plane the object is supposed to be moving along?

I probably explained that poorly...
c6burns
Posts: 149
Joined: Fri May 24, 2013 6:08 am

Re: Restricting movement of a RigidBody onto an arbitrary pl

Post by c6burns »

My understanding is that those transforms express the pivot of the constraint in local coordinates. For example, you can tilt the entire 6dof slide in the constraint demo by specifying a rotation.

As for the other concerns about the merits of this as a solution to the original problem, I really can't say. Just wanted to chime in on constraint rotations :)
Basroil
Posts: 463
Joined: Fri Nov 30, 2012 4:50 am

Re: Restricting movement of a RigidBody onto an arbitrary pl

Post by Basroil »

Mako_energy02 wrote: Keeping things locked to axis aligned planes severely limits the kinds of puzzles that we can assemble. Multiple planes is something we have planned, yes.
Moving objects in 3d surfaces (several intersecting planes or objects like spheres) is not exactly fun to do with a mouse :wink:

By "multiple planes", do you mean parallel planes or intersecting ones (that form some sort of surface the object moves on)? If parallel, you definitely should try just moving your camera rather than the world, since you can lock and unlock objects from one plane to another. For a surface, you'll either need good code/ gameplay mechanic at the intersecting edges or you will have instability when crossing the boundary (how much depends on what you do and how fast you do it)
c6burns wrote:My understanding is that those transforms express the pivot of the constraint in local coordinates. For example, you can tilt the entire 6dof slide in the constraint demo by specifying a rotation.
Exactly that :D Hell, you can even apply rotation torques based on translation if you want to make it look cooler.
Mako_energy02 wrote:Also important to note is that not all of the objects movement is explicit. The mouse starts a force on the object and then it is released. I'm worried about stability issues/jitter from having the two constraints trying to control the movement.
It's certainly a valid concern, but if you keep the mouse joint forces low (perhaps lower ERP, maybe even use 6dof constraint rather than p2p) it should work just fine in PGS and Dantzig (only two I have tested overlapped, overconstrained bodies on)
Post Reply