steering wheel syncing
So if we have a vehicle, we would have to have the wheel as a child of the rigibody on the car. I understand that parent child relationships get tricky when trying to sync so what is the best way to set up a car with a syncing steering wheel? A holder object top parent that is a realtimetransform only, then rigibody siblings as all the children linked with joints?
21 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:
----------------------
To answer your question about syncing a steering wheel in a vehicle using NormalVR (Normcore), let's consider the best practices and limitations of RealtimeTransform components.
You're correct that parent-child relationships can be tricky when syncing, especially with Rigidbodies. The RealtimeTransform component works differently when a Rigidbody is present, and there are some important considerations to keep in mind.
According to the RealtimeTransform documentation (https://normcore.io/documentation/realtime/networked-physics#realtimetransform--physics):
1. Rigidbodies are synchronized in world space rather than local space.
2. RealtimeTransform components with Rigidbodies should not have parents.
Given these constraints, here's a suggested approach for setting up a car with a syncing steering wheel:
1. Create a top-level empty GameObject for the entire vehicle.
2. Add a RealtimeTransform component to this top-level object.
3. Create child GameObjects for the car body and the steering wheel as siblings under the top-level object.
4. Add Rigidbody and RealtimeTransform components to both the car body and steering wheel objects.
5. Use joints (like ConfigurableJoint) to connect the steering wheel to the car body.
This setup avoids parent-child relationships between Rigidbodies while still allowing you to sync the entire vehicle and its parts.
For the steering wheel specifically, you might want to use a custom RealtimeComponent to sync its rotation relative to the car body, rather than relying solely on RealtimeTransform. This would give you more control over the steering behavior and synchronization.
Remember that when using RealtimeTransform with Rigidbodies, ownership becomes important for physics interactions. The Networked Physics guide (https://normcore.io/documentation/realtime/networked-physics#using-realtimetransform) explains how ownership works with RealtimeTransform and Rigidbodies.
Lastly, keep in mind the advice from the RealtimeTransform documentation (https://normcore.io/documentation/realtime/realtimetransform#extra-notes):
"Don't reparent game objects with RealtimeTransform on them! RealtimeTransform does not track the parent of a RealtimeTransform and cannot synchronize it at runtime."
By following these guidelines, you should be able to create a synced vehicle with a steering wheel using Normcore's RealtimeTransform components.
----------------------
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 me know how I did by reacting below.
@Normcore Assistant but the steering wheel child has to have a realtimetransform, as does the NON rigibody main transform parent. Is that correct?
Let me check the knowledge base for you again. One moment! :books:
----------------------
You're right to seek clarification on this point. Let's break down the correct setup for the steering wheel and the main transform parent based on the Normcore documentation.
1. For the main transform parent (top-level object):
Yes, this non-Rigidbody parent should have a RealtimeTransform component. This allows the entire vehicle to be synchronized as a whole.
2. For the steering wheel:
Yes, the steering wheel should also have its own RealtimeTransform component. However, it's important to note that it should not be a child of a Rigidbody object.
According to the RealtimeTransform documentation (https://normcore.io/documentation/realtime/networked-physics#realtimetransform--physics):
"RealtimeTransform + Rigidbody should not have parents. PhysX simulates all rigidbodies in world space. If you have a Rigidbody with a child that also has a Rigidbody component, you're going to end up with unpredictable results."
Instead, the recommended setup is:
1. A top-level GameObject with RealtimeTransform (no Rigidbody)
2. The car body as a child, with both Rigidbody and RealtimeTransform
3. The steering wheel as a separate child of the top-level object (sibling to the car body), also with both Rigidbody and RealtimeTransform
This setup avoids the parent-child relationship between Rigidbodies while still allowing both the car and the steering wheel to be synchronized.
Remember, as stated in the RealtimeTransform documentation (https://normcore.io/documentation/realtime/realtimetransform#extra-notes):
"Don't reparent game objects with RealtimeTransform on them!"
So, once you set up this structure, avoid changing the hierarchy at runtime.
----------------------
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 me know how I did by reacting below.
@Normcore Assistant so lets say two players are in the vehicle and the steering wheel is a sibling of the car. There is a top level NON rigibody transform. Can one player own the sterring wheel and one player own the top level transform?
Let me check the knowledge base for you again. One moment! :books:
----------------------
Yes, in the scenario you've described, it is possible for one player to own the steering wheel and another player to own the top-level transform. This setup aligns with Normcore's ownership model and the recommended structure for networked physics objects.
According to the Ownership and Lifetime Flags documentation (https://normcore.io/documentation/room/ownership-and-lifetime-flags):
"Every model in the datastore, including child models, can have an owner with which it is associated."
This means that different components of your vehicle can indeed be owned by different players. Here's how it would work in your scenario:
1. The top-level non-Rigidbody transform (with RealtimeTransform) can be owned by one player.
2. The steering wheel (a sibling of the car body, with its own Rigidbody and RealtimeTransform) can be owned by another player.
To achieve this, you would use the
RequestOwnership() method on the respective RealtimeTransform components. For example:
It's important to note that ownership affects how updates are synchronized. As stated in the RealtimeTransform documentation (https://normcore.io/documentation/realtime/realtimetransform):
"RealtimeTransform treats the client that owns the object as the source of truth. All other clients follow along with the owner's copy of the transform or rigidbody."
This means that the player owning the top-level transform will control the overall movement of the vehicle, while the player owning the steering wheel will control its rotation.
Remember that when using Rigidbodies, RealtimeTransform handles ownership differently. It will attempt to request ownership of colliding objects to ensure smooth physics interactions. You may need to manage this behavior carefully in your specific use case.
Lastly, keep in mind that this setup, while possible, may require careful coordination between the players to ensure smooth and logical vehicle control. You might need to implement additional logic to manage how these separately owned components interact within your game's context.
----------------------
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 me know how I did by reacting below.
@Normcore Assistant ok so to confirm owning the top level non rigibody transform will not own it's children rigibody realtime transforms (which are sibligns of each other but children of the main transform
Let me check the knowledge base for you again. One moment! :books:
----------------------
You're correct in seeking confirmation on this important point. Let me clarify based on the Normcore documentation:
Owning the top-level non-Rigidbody transform with a RealtimeTransform component does not automatically grant ownership of its children's RealtimeTransform components, even if they are siblings to each other and children of the main transform.
According to the Ownership and Lifetime Flags documentation (https://normcore.io/documentation/room/ownership-and-lifetime-flags):
"Every model in the datastore, including child models, can have an owner with which it is associated."
This means that each RealtimeTransform component, whether it's on the parent or child objects, can have its own distinct owner. The ownership of the parent does not automatically propagate to the children.
However, it's important to note that there is a hierarchy of ownership when it comes to making changes. The same documentation states:
"Models can have other models as children, and the ownership settings of a parent are enforced on all children. If a model is owned by one client, all other clients are blocked from making changes to the model or any of its child models."
This means that while the children can have different owners, if a parent object is owned by a specific client, that client's ownership takes precedence when it comes to making changes to child objects.
In your specific setup with Rigidbodies as siblings, each RealtimeTransform component (on the parent and on each Rigidbody child) would need to have its ownership set separately if you want different clients to control different parts of the vehicle.
Remember, as mentioned in the RealtimeTransform documentation (https://normcore.io/documentation/realtime/networked-physics#realtimetransform--physics), Rigidbodies with RealtimeTransform components should not have parent-child relationships between them, which is why your setup of having them as siblings is correct.
----------------------
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 me know how I did by reacting below.
@Normcore Assistant ""Models can have other models as children, and the ownership settings of a parent are enforced on all children. If a model is owned by one client, all other clients are blocked from making changes to the model or any of its child models."
This means that while the children can have different owners, if a parent object is owned by a specific client, that client's ownership takes precedence when it comes to making changes to child objects."
Doesn't this mean that other players can't own a realtimetransform rigidbody under it though?
Let me check the knowledge base for you again. One moment! :books:
----------------------
You've raised an excellent point, and I apologize for any confusion in my previous explanation. You're right to question this, as there seems to be a contradiction. Let's clarify this based on the official Normcore documentation.
According to the Ownership and Lifetime Flags documentation (https://normcore.io/documentation/room/ownership-and-lifetime-flags#how-ownership-is-enforced):
"Models can have other models as children, and the ownership settings of a parent are enforced on all children. If a model is owned by one client, all other clients are blocked from making changes to the model or any of its child models."
This statement indeed suggests that if a parent object is owned by a specific client, other clients cannot make changes to its child models, regardless of their individual ownership settings.
However, it's crucial to understand the distinction between RealtimeView ownership and RealtimeTransform ownership. The RealtimeTransform documentation (https://normcore.io/documentation/realtime/realtimetransform#ownership) states:
"In order to move an object with a RealtimeTransform component, your client needs to be the owner of the RealtimeTransform component"
This means that the ownership of a RealtimeTransform is separate from the ownership of its parent RealtimeView.
In the context of your vehicle setup, where you have a non-Rigidbody parent with child Rigidbody objects as siblings:
1. The top-level non-Rigidbody transform would have a RealtimeView component.
2. Each child Rigidbody object would have its own RealtimeTransform component.
In this case, different players can indeed own and control different RealtimeTransform components, even if they are children of a parent RealtimeView owned by another player. The ownership of the parent RealtimeView does not prevent other players from owning and controlling child RealtimeTransform components.
I apologize for the confusion in my previous response. You are correct to point out this discrepancy, and it highlights the importance of understanding the specific behavior of RealtimeTransform components in relation to the general ownership model in Normcore.
----------------------
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 me know how I did by reacting below.
I'd just make a custom model with a float to sync steering angle for the car
in this case it's actually a yoke so it's a bit more complex
but I guess technically still could do that
vector 2 then
ultimately that seems like it might be easier than what I've been messing with so far though I guess
-1 for full lock left and +1 for full lock right
yeah thats what I have set up and likewise for forward back, good idea
and I like the idea of less active rigibodies heh
how would you handle ownership though then without a realtime transform do you use the view?
use the view or leave it unowned