Closed PhoenixIllusion closed 9 months ago
The Path constraints demo should probably color-code the blocks to the actual colors used on the axis debugger code (the ray's shooting off each block).
Looking good! Thanks again for all these demos!
I've created a PR to provide the path fraction so you can support figure 8-s. I'll merge this in a moment.
(and I also fixed the typo in the enum you found)
All changes have been merged in https://github.com/jrouwe/JoltPhysics.js/commit/5b5ec0e2856bb266733e989c4c940864e0034e56
I think Pulley is one of the few constraints with pure and unalterable fixed world points? There is no way for a pulley to be on a moving object due to that, unless you destroy and recreate the constraint every movement of the object. If I needed it, for now I would probably instead fake it with 2x distance constraints.
I believe the only two constraints we don't have are gear and rack & pinion, but I haven't thought of anything interesting that uses those where I currently wouldn't just bypass to a powered hinge or slider. Possibly gear makes sense for a pseudo-water wheel turning a mill, or connect the two and have the wheel being engaged open a gate via wheel-to-gear-to-pinion, and turn off the water for the wheel to spin backwards as the weight of the gate closes, but haven't though of anything that isn't a niche use case.
I guess the pulley would become a 3-to-4-Body constraint if it didn't use the fixed world points
I think Pulley is one of the few constraints with pure and unalterable fixed world points?
Yes, and you're right that otherwise it would become a 3-4 body constraint. I made it to support what the Source Engine needed but so far it didn't get integrated and to my knowledge it is not used by anyone.
Gear & rack & pinion are indeed also niche constraints.
Hmm, kinda interested in gear & rack & pinion. Not sure I understand what those are, though. Or is it a single constraint? Is it something like this?: https://fabmax.github.io/kool/kool-js/?demo=phys-joints
As for the static constraints, I think another case is probably with soft bodies. Even though not a constraint, technically. Could probably be useful to set the position of the static vertices, so the cloth could be attached to moving bodies.
Rack and pinion: https://www.youtube.com/watch?v=e588KG-ZSxc Gear: https://www.youtube.com/watch?v=3w5SgElroBw
Soft body is not compatible with any constraints at the moment, you need to set the inverse mass of a vertex to 0 and then animate it yourself. At some point in the future I will make it possible to attach a point to a dynamic rigid body.
I just exposed gear and rack & pinion constraints (didn't make a demo and also didn't release a version yet so you need to build yourself)
The pulley constraint is straight-forward. Though I couldn't figure out a good demo of various weights on the pulley. I was tempted to wire it to a draw-bridge and push a giant rock on one side, and might do that in my actual games.
The paths were made so I can do nice floating platforms in a jumper game. ex: Mario64's moving platform puzzles (most Bowser levels, Rainbow Ride, Tick Tock Clock)
The Path Constraint is functional with a custom JS Path, but the demo implementation is not the ideal way to do it. The demo currently uses a high-res sample of the path and brute force catches 'closest point' and uses that to assign the mFraction of the constraint on the path. I'd thought of using an SVG path object since that supports a mirrored 2D functionality of
pathElement.getPointAtLength(n)
andpathElement.getTotalLength()
The normal/binormal/tangent is still likely how you would do it in most cases.
For
GetClosestPoint
, ideally instead you would use a lookup data-structure, pre-calculated for most likely/common Body2 locations. For 2D-ish paths, you can even just make a data-texture of common locations and pre-calculated 'XY coord is closest to mPathFraction" as an instant lookup.Possibly maintain multiple Path objects would help, so there exists a per Constraint context with a memory of 'prior mPathFraction' and jump near there to start the search. That would also solve the problem I had when I tried to do figure-8s and other complex self-crossing paths, where the mBody2 location search would jump-track when a path crossed itself, since without a memory you don't know which of the crossed paths to take. https://github.com/jrouwe/JoltPhysics/blob/master/Jolt/Physics/Constraints/PathConstraint.cpp#L122 .