Best way to push data into a scene
Posted: 03 Oct 2021, 04:51
Imagine you have 100 objects that each have 10 properties. You want to have access to all these objects in your scene. 2 of the properties change frequently (group A), 3 once in a while (group B) and 5 rarely change (group C). I'd like to get your advice on the best way to push this data into a scene. Here are some approaches:
1. Push a JSON array that contains 100 nodes with 10 properties.
2. Push 3 JSON arrays that each contain 100 node but with the 3 different properties groups (A, B and C).
3. Push 10 JSON arrays, one for each property.
In these 3 scenarios, accessing a specific object would be done using the JSON Parser node: 100 Hierarchy Containers (named 0-99) would contain a JSON Parser that uses the Container Info node's NameIndex to extract its JSON object from the array. Back to the 3 scenarios:
1. One JSON Parser extracts all properties.
2. 3 JSON Parsers would extract the 3 groups of properties.
3. 10 JSON Parsers would extract one property each.
Each scenario seems to have its advantages and disadvantages:
1. Advantages: One JSON Parser for all properties.
Disadvantages: All JSON data is sent if any data changes.
2. Advantages: Far less data sent when data changes, mostly group A data gets updated which is 20% of the data.
Disadvantages: More logic nodes.
3. Advantages: Only the data that changes gets sent.
Disadvantages: large amount of logic nodes.
It would seem that the second approach would probably be the most efficient at handling the data but maybe there are some areas where Ventuz is more efficient. For example, handling incoming data might be faster than dealing with large amount of nodes, making scenario 1 more attractive than scenario 3.
Some questions:
1. Would it be better to skip the JSON Parser and create 100 groups in Scene Data, with 10 properties each, and push the data directly instead of using JSON?
2. Sticking with the JSON approach, is there a way to have the data parsed asynchronously? Unfortunately the last project I did still used CLI to push the data instead of Remoting so that could've been one of the reasons I experienced some dropped frames when pushing updated data.
Thanks for any suggestions you might have.
Etienne Laneville
1. Push a JSON array that contains 100 nodes with 10 properties.
2. Push 3 JSON arrays that each contain 100 node but with the 3 different properties groups (A, B and C).
3. Push 10 JSON arrays, one for each property.
In these 3 scenarios, accessing a specific object would be done using the JSON Parser node: 100 Hierarchy Containers (named 0-99) would contain a JSON Parser that uses the Container Info node's NameIndex to extract its JSON object from the array. Back to the 3 scenarios:
1. One JSON Parser extracts all properties.
2. 3 JSON Parsers would extract the 3 groups of properties.
3. 10 JSON Parsers would extract one property each.
Each scenario seems to have its advantages and disadvantages:
1. Advantages: One JSON Parser for all properties.
Disadvantages: All JSON data is sent if any data changes.
2. Advantages: Far less data sent when data changes, mostly group A data gets updated which is 20% of the data.
Disadvantages: More logic nodes.
3. Advantages: Only the data that changes gets sent.
Disadvantages: large amount of logic nodes.
It would seem that the second approach would probably be the most efficient at handling the data but maybe there are some areas where Ventuz is more efficient. For example, handling incoming data might be faster than dealing with large amount of nodes, making scenario 1 more attractive than scenario 3.
Some questions:
1. Would it be better to skip the JSON Parser and create 100 groups in Scene Data, with 10 properties each, and push the data directly instead of using JSON?
2. Sticking with the JSON approach, is there a way to have the data parsed asynchronously? Unfortunately the last project I did still used CLI to push the data instead of Remoting so that could've been one of the reasons I experienced some dropped frames when pushing updated data.
Thanks for any suggestions you might have.
Etienne Laneville