1
\$\begingroup\$

I am trying to write a C++ scene graph structure. While designing the node classes I am facing the below issue.

I have a scene graph to represent a house. enter image description here

I would like to have another house next to the one I have but I would like to reuse the nodes from the existing graph. In order to do that, I create another house (House 2) as a child of the original house (House 1). Although this leads to a situation where the base node in the following graph has 2 parent nodes.

enter image description here

I would like to know, is it a good idea to have a scene graph node (intermediate translation node) to have multiple parents? I would like to reuse my sub-graph as much as possible.

Improve this question
\$\endgroup\$

1 Answer 1

Reset to default
1
\$\begingroup\$

Sure, you can, but a monolithic scene graph where nodes have multiple actual parents sounds complicated and cumbersome.

Instead, it sounds like what you'd want to do is allow nodes in the graph to reference other complete graphs. This sort of mechanism is often called a "prefab," "template" or "blueprint" system.

In this sort of solution, you'd package what is currently the sub-graph representing the house up into it's own "prefab" graph. It has a root at the origin, and all the pieces of the house placed relative to that root.

The main world graph would contain two nodes, with appropriate world transforms, which then reference the house graph (but aren't duplicating its contents). At runtime you can walk from the nodes in the main graph to the nodes in the referenced graph as if they were duplicated into the main graph, but you have the advantage of only having the house prefab graph in memory once, and that when you change the prefab graph, all instances of references to that graph inherit those changes.

(The main difference, in case it's not obvious, is that there's no "parent" link from the root of the prefab subgraph back to the node(s) in the main graph; the relationship is only from the main graph into the subgraph, and so avoids a lot of the complication that comes from instead treating the same logical relationship of nodes as equal peers in one single graph.)

Improve this answer
\$\endgroup\$
3
  • \$\begingroup\$ Thanks for the insight. I believe having a subgraph is the practical solution to my problem. Although, can you shed some light on complication that could arise from having a parent relationship from subgraph to the main graph? I see one use of having such a relationship is I can query all the places in the main graph where the subgraph is used. \$\endgroup\$
    – Abhishek
    Jan 4, 2019 at 20:00
  • \$\begingroup\$ The “multiple parent” approach implies all nodes are equivalent in the graph; there’s no way to disambiguate them in a traversal, which complicates algorithms that generically walk the graph (at the very least you must now detect cycles and skip them). The prefab approach makes a distinction between the two types of data, easing this burden and making most of the kinds of traversals you’d want to do easier. \$\endgroup\$
    – user1430
    Jan 4, 2019 at 20:12
  • \$\begingroup\$ You can still achieve the “find all places this is referenced” query with prefabs, you can store and update references from the prefab to the main graph as you like (or find them all on demand by traversing the main graph). You have the same data, but in more appropriate, specific forms for use rather than homogenized together in one massive graph. This should result in simpler and more optimal code. \$\endgroup\$
    – user1430
    Jan 4, 2019 at 20:14

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .