What is the overhead of RealtimeView components?
I like to keep prefabs in a tidy and verbose hierarchy, but having RealtimeComponents require a RealtimeView component next to each.
what is the overhead from having extra nodes in the hierarchy (meaning extra RealtimeViews that do not need to be in separate gameObjects)?
Like in terms of: bandwidth, model size, computation - is it even slightly significant in any of these factors?
Thanks
4 Replies
Hi @Niv. 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 the overhead of RealtimeView components in NormalVR, let's break it down based on the information available in the knowledge sources:
1. Hierarchy and Model Structure:
RealtimeView components create a hierarchy in the datastore that mirrors your GameObject hierarchy. Each RealtimeView creates a model for itself and its child RealtimeComponents in the datastore. This is explained in the Realtime > RealtimeView documentation.
2. Bandwidth and Model Size:
While the knowledge sources don't provide specific numbers on bandwidth usage or model size for RealtimeViews, we can infer that each additional RealtimeView does contribute to the overall data that needs to be synchronized. The Architecture > Unity Client document mentions that Normcore uses delta updates to conserve bandwidth after the initial datastore snapshot, which suggests some optimization is in place.
3. Computation:
Each RealtimeView and its associated RealtimeComponents participate in the synchronization process. The Realtime > RealtimeComponent document outlines the lifecycle of these components, which includes model creation, replacement, and event handling.
4. Significance of Overhead:
The knowledge sources do not provide specific information about the significance of the overhead from extra RealtimeViews. However, it's worth noting that Normcore is designed to handle complex hierarchies and multiple components.
5. Best Practices:
While the documents don't explicitly advise against creating verbose hierarchies with many RealtimeViews, they do emphasize the importance of proper structure. The Realtime > RealtimeView document mentions that child views and their components are managed by their parent RealtimeView.
In conclusion, while there is likely some overhead associated with additional RealtimeViews in your hierarchy, the knowledge sources don't provide enough information to quantify this overhead in terms of bandwidth, model size, or computation. The design of Normcore suggests that it's built to handle complex hierarchies, but without specific performance metrics, it's difficult to say whether the overhead is significant.
If you're concerned about performance, you might consider testing your application with different hierarchy structures to see if you notice any significant differences. Additionally, you could reach out to the NormalVR support or community for more specific guidance on optimizing your prefab structures.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
<@269927864265211906> Kapa.ai is still learning and improving, please let me know how I did by reacting below.
Hey Niv,
RealtimeViews do add a small overhead, but we're talking about an extra node to visit when evaluating ownership. And 2-3 bytes per node during serialization. Both of which we've found to be negligible in terms of performance. Views don't run anything in Update() and since Normcore only serializes delta updates, for most games the overhead is not noticeable. In general, I'd say start with the architecture that makes the most sense for you all and then profile in practice later on.
Thanks mark - that's in line with what I assumed, but good to know.