SceneGraphPath
Posted: Thu 1. Mar 2007, 11:50
At the jReality meeting yesterday (28.02.07) we discussed the issue of specifying a selection in jReality. For example, the ViewerApp has a SelectionManager which does just this. In many cases, this is fully specified by an instance of SceneGraphPath, but there are currently at least two exceptions: where the selected object is a Tool, and where it is an AttributeEntity. Since these are not subclasses of SceneGraphNode, they cannot be validly inserted into a SceneGraphPath. The current solution as implemented in SelectionManager class, involves extra methods for handling these special cases.
We discussed whether it would be possible to overcome these special cases by widening SceneGraphPath to allow arbitrary objects to be inserted. That is, a SceneGraphPath would be essentially a list of Object's rather than of SceneGraphNode's. This would permanently solve the selection problem, since any conceivable selection could be so represented.
Here are some points which came up in the ensuing discussion:
1) the method getLastElement() should be renamed getLastNode(), since there might be further elements.
2) a valid SceneGraphPath would still begin with a sub-list of SceneGraphComponents, followed by an optional SceneGraphNode; then there could be a sublist of Object's. Allowing more than one Object would allow us to "drill down" into shaders (which are AttributeEntity type), into subshaders (also of this type). Even now this exists in the case of a Texture2D inside a DefaultPolygonShader, and implementing multi-textures would continue this trend.
3) Existing code usually accesses the path via the methods getLastCompoonent() or getLastElement() (which would become getLastNode() -- see above). These methods would continue to function as before, so code depending on theme would not need to be changes.
We decided to think further this week on possible ramifications of this change and take up the issue again next week. Particularly of interest are examples where existing code involving SceneGraphPath would no longer function correctly.
We discussed whether it would be possible to overcome these special cases by widening SceneGraphPath to allow arbitrary objects to be inserted. That is, a SceneGraphPath would be essentially a list of Object's rather than of SceneGraphNode's. This would permanently solve the selection problem, since any conceivable selection could be so represented.
Here are some points which came up in the ensuing discussion:
1) the method getLastElement() should be renamed getLastNode(), since there might be further elements.
2) a valid SceneGraphPath would still begin with a sub-list of SceneGraphComponents, followed by an optional SceneGraphNode; then there could be a sublist of Object's. Allowing more than one Object would allow us to "drill down" into shaders (which are AttributeEntity type), into subshaders (also of this type). Even now this exists in the case of a Texture2D inside a DefaultPolygonShader, and implementing multi-textures would continue this trend.
3) Existing code usually accesses the path via the methods getLastCompoonent() or getLastElement() (which would become getLastNode() -- see above). These methods would continue to function as before, so code depending on theme would not need to be changes.
We decided to think further this week on possible ramifications of this change and take up the issue again next week. Particularly of interest are examples where existing code involving SceneGraphPath would no longer function correctly.