This fixes a bug that caused transform nodes to break on scenes that dynamically update the scene graph in significant ways. The key issue is that when a transform node of any sort was compiled, it would push its core onto the xform stack, which would clear all of the core's children. The problem is that if any of those children were from node branches that hadn't been marked as dirty (and thus aren't set to be compiled), they would not be re-pushed onto the stack. The transforms they represented would be lost.
This solution involves a few changes to how transform nodes are handled:
Introduce a _branchDirty hook on all nodes, so they can define some behaviour to occur when their branches are marked as dirty.
When marked as dirty, transform nodes mark their cores as compiling. This indicates that they will be pushed onto the stack on a subsequent compilation.
When a core is pushed onto the xform stack, only the child cores marked as compiling are cleared from the list of children, since they are the ones that will be pushed again later. (Note that the filtering happens in place, to avoid memory churn).
@xeolabs, let me know if you see any issues with this approach.
This fixes a bug that caused transform nodes to break on scenes that dynamically update the scene graph in significant ways. The key issue is that when a transform node of any sort was compiled, it would push its core onto the xform stack, which would clear all of the core's children. The problem is that if any of those children were from node branches that hadn't been marked as dirty (and thus aren't set to be compiled), they would not be re-pushed onto the stack. The transforms they represented would be lost.
This solution involves a few changes to how transform nodes are handled:
_branchDirtyhook on all nodes, so they can define some behaviour to occur when their branches are marked as dirty.compiling. This indicates that they will be pushed onto the stack on a subsequent compilation.compilingare cleared from the list of children, since they are the ones that will be pushed again later. (Note that the filtering happens in place, to avoid memory churn).@xeolabs, let me know if you see any issues with this approach.