| /*! \page node_ownership Memory Handling and Ownership of Scene Graph Nodes |
| |
| @ingroup api_notes |
| |
| To avoid as many issues with memory allocatoin/deallocation as |
| possible, I propose to use -- at least for the scene graph -- some |
| pretty basic but automatic memory deallocation that automatically |
| deallocates everything that's no longer used. As a scene graph does |
| not allow cyclic references, anyway (you're f***ed if you have them, |
| anyway...), this should be pretty straightforward. |
| |
| To make that happen, I will follow the following rules |
| |
| <ul> |
| |
| <li> every "node" in the scene graph track its list of "parents" |
| (yes, you can have an unlimited number of parents, this is a liberal |
| society ....) |
| |
| <li> as soon as a node is destroyed, it tells so to all its |
| dependents, and (recursively) kills all dependents who have no |
| parents left (not too liberal: kids without parents starve |
| immediately). In other words, every node must have at least one |
| parent. \n |
| |
| To facilitate that "every node needs an owner", I will force the |
| app to pass a "parent" for every call that creates a new node. In |
| some cases (like rtNewDataArray) this has to be done explicitly, |
| in many calls, though, it is implicit and not visible (i.e., |
| rtVertexArray3f() needs to get a reference to a mesh, anyway, |
| which is automatically the parent). |
| |
| <li> the only exception to above rule of having at least one parent |
| are "root" nodes (rtNewRoot), which are somewhat similar to openrt's |
| "objects", in that they contain an entire object with an entire |
| scene graph. Note, however, that it is _still_ possible (note: this |
| may be subject to discussion) to cross-reference from one such |
| "object" to another, and to also directly reference some node(s) |
| somewhere deep within another root node's subtree. |
| |
| <li>as a consequence of above, rtDestroy makes most sense for root |
| nodes, though I will currently allow it for internal nodes, too, but |
| this is subject to discussion/change (e.g.,: what actually happens |
| when deleting a vertex array node that is still referenced by a mesh |
| !?) |
| |
| </ul> |
| |
| note: having parent links in all nodes facilitates some lazy |
| bottom-to-top notifications (for lazy update/rebuild schemes), too. |
| |
| |
| */ |
