Broken VRCConstraint behavior when constraints utilize float point precision.
closed
WingmanDraws
- Create GameObject container (A)
- Create child GameObject of A and set positional coordinates to 9999999 on X,Y, and Z Axis (B).
- Create another child object, this time of B, and set position coordinates to -9999999 on all axis (C).
- Create final GameObject as a child of C and add either position or parent VRCConstraint (D).
- Set target of constraint on D to any GameObject outside of A.
- Move the target game object.
Intended behavior: constrained object should utilize float point precision to snap along 1m distances (Similar to how Minecraft blocks work!) each time the game object crosses over to the next 1m threshold.
What occurs: The constrained will erratically shake and snap along the seemingly closest four 1m distances to the target.
Included in the link below is higher quality video with both the intended and unintended behavior examples (The gifs really don't do the erratic nature justice).
Included is also a prefab I made to assist in testing! To test, simply unpack the prefab and move the respective targets around and observe the snapping.
Log In
Dexvoid
closed
_
_tau_
If you build up the system you describe in editor with VRC Constraint components and switch them to "Solve in Local Space", does that work for you or produce different results?
WingmanDraws
_tau_ So some good news and bad news. Good news: with Beta 4, the erratic snapping is gone with the setting ticked on and the constrained object seems to follow the intended behavior. Bad News: The setting seems to mess with the transform values when applied as it no longer has it's initial offset and sets it's transform to 0's on all axis. This seems to only apply when the setting is ticked on and actively resets when ticked off (See gif)
_
_tau_
WingmanDraws: Solving in local space will copy the values in the Transform view the same way as you see them in the editor. So you need to move the parent probably? I'd recommend playing around with that setting and various ways of moving transform parents or the object that the constraint targets.
I do not believe we will fix the original behaviour at this time.
WingmanDraws
_tau_ Sorry for the late reply! Sadly Local Space does not work. Attempting to place the object inside a container and moving it in any way with that enabled does not appear to make any difference. Sure, the erratic nature is gone, but I am now unable to move the object without an intense chain of constraints. I do think I can understand why it behaves this way, but is it intentional for the lack of movement even when the target is inside a container?
Dexvoid
WingmanDraws It looks like your GIF shows the container position constrained to its own child. Being able to move it around with Solve In Local Space disabled is expected since the child will move with the parent as you drag it. With Solve In Local Space enabled, I'm seeing the parent game object remain at (0, 0, 0), which is the expected behavior in that case assuming the child is also at local position (0, 0, 0) and doesn't seem to match what you've shown here - are you sure the constraint is locked under Constraint Settings?
It seems that I can recreate the effect you're looking for by following the steps in your initial post, then turning on Solve In Local Space and keeping both A and the target game object as children of the avatar. This matches how this works with a Unity constraint in my testing. Does that help?
WingmanDraws
Dexvoid This does help in editor to stop the erratic snapping. In game, the object simply locks itself to the constrained object without any snapping (in my testing I took the previous example and simply placed the target on my head and enabled local space). The object would simply follow my head as if I had constrained it normally. It seems there is an inconsistency between in editor and in game?
Dexvoid
WingmanDraws I can't reproduce any mismatched behavior between the SDK and the client. In your test, since your constraint on D is solving in local space, just putting the target on your head won't work since that would still give it a local position of (0, 0, 0) relative to the head bone.
I can produce a similar effect to this that follows the head by doing the following:
- Follow the steps in your original post with A and the target both being direct children of your avatar's root.
- Enable solving in local space for the game object on D.
- Add a parent constraint to the target game object with Solve in Local Space disabled.
- Have the parent constraint on the target game object use the avatar's head bone (or any other bone as needed) as a source.
This appears to give me the effect you've shown in your original post. The game object D snaps to the position of my avatar's head in increments of 1 world unit. The cube moves with my avatar root without snapping as I run around, which seems to match the behavior you'd otherwise get when using this technique with Unity constraints.
WingmanDraws
Dexvoid After some testing I can safely say that the solution you supplied worked (sorta)! So it stopped the snapping for sure, but there's a massive issue with this iteration. The snapping "blocks" will follow the avatar smoothly if done this way. In my personal projects, I have always placed this into world locked at 0,0,0 in order to have everyone on the same grid. With this iteration, I can no longer do so as the "grid" smoothly follows me. When I lock it to world, the new "local space" becomes wherever 0 is in the world.
Dexvoid
WingmanDraws After the steps above I can stop the block following the avatar smoothly by:
- Creating a new game object under the avatar root
- Adding a parent constraint with no sources to it and enabling Freeze To World
- Moving both A and the target to be direct children of this new game object.
You might need to vary this a little depending on what you need but could you give this a try please? Alternatively you may want to assign a prefab with position (0, 0, 0) and no rotation to the new parent constraint and leave Freeze To World disabled if you want the cube to stay axis aligned to the world.
Dexvoid
WingmanDraws Hopefully the suggestion above has helped out. As mentioned above, we aren't currently planning to implement this behavior natively at this time, so I'll switched this to Closed for now.
WingmanDraws
Dexvoid Sadly I wasn't notified of the above response! I'll give it a go! Leaving this as closed is fine as well, since I have found an alternative method for this in the meantime! If I am able to get your method to work, I will be implementing it asap! Thank you for all the help!
StormRel
tracked