Note that there are some explanatory texts on larger screens.

plurals
  1. POimplementing MVC pattern on c++ scene graph
    primarykey
    data
    text
    <p>I have a tree of objects that represent a 3D-model (a scene graph). The tree nodes are of different types (implemented as derived classes from a common base class). For example, there is a node representing a polygon, or a node which applies a coordinate transformation (rotation, translation) to its child nodes. It is also a requirement, that third party vendors should be able to implement new node types, and add them by a plugin (I use Qt as GUI framework). Therefore it is possible, that there may be nodes in the tree, of whom the type is unknown when compiling.</p> <p>Now I want to implement a class, that acts as a view for this scene graph. For every tree node type the view has to take the appropriate actions (draw the polygon, transform etc.). My idea is to implement view classes for every node type and let the top-level-view class delegate to these classes depending on the node type. (Third party vendors will be able to implement own view delegate classes)</p> <p>So my question is: how can I determine the type of a node in a performant and extensible way? </p> <p>My ideas so far:</p> <ol> <li><p>I could add a type identifier to every node class. This could simply be an integer (strings are not suitable for performance reasons). The problem is the management of type identifiers for third party vendors. How can I make sure that the same identifier is not used for different node types (e.g. by different vendors)?</p></li> <li><p>I could implement drawing code, or at least a call to the appropriate drawing delegate object directly in the node. But my node objects should preferably not know something about their view objects. Also it is not possible to give every node object a dedicated view object (we are talking about tens of thousands of nodes). </p></li> </ol> <p>So, what are your ideas? Is there perhaps a completely different way to handle this? Remember: the solution should NOT require hash table lookups or other computation intensive algorithms, because I need to draw the graph in real time.</p> <p>Thanks in advance, McNumber</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload