What happens if we disable a rigidbody game object with a realtime transform and view on it?
Will it be able to resume syncing if reenabled? Does it break the object?
5 Replies
Hi @cryptomax. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
----------------------
Hmm, I don't know enough to give you a confident answer yet. The provided knowledge sources do not contain specific information about what happens when a Rigidbody GameObject with a RealtimeTransform and RealtimeView is disabled and then re-enabled.
However, it's important to note that NormalVR does not support adding or removing a Rigidbody at runtime. Instead, they recommend instantiating an invisible game object with a Rigidbody on it and then copying the transform position/rotation in Update if you need the ability to synchronize a transform to be dynamic at runtime source (https://normcore.io/documentation/realtime/common-questions#can-i-add-or-remove-a-rigidbody-at-runtime).
For more detailed information, you may want to refer to the official NormalVR documentation (https://normcore.io/documentation/).
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
<@401986039964631060> kapa.ai is still learning and improving, please let us know how it did by reacting below
As long as the enable / disable is in sync I don't see a reason why it'd break?
if the object is moving it will eventually correct itself, but but if not it’s possible it isn’t in sync and RT doesn’t send an update
ideally you disable the renderers / child game objects as disabling a RT doesn’t actually stop serialization or the overhead from running it
and the sync position/rotation/scale bools are now networked if that helps with this
interesting, so it wont change the realtime overhead, but theorecially I could use this to negate the rigidbody effect on the physics system by disabling it, and if it's moving when reenabled your saying it would eventually interpolate the position back to where it actually was (unless we did something specific to reposition it perphaps)
thanks for the extra info