SceneGraphPath

Core SceneGraph API, Utilities, Factories etc.
Post Reply
User avatar
gunn
Posts: 323
Joined: Thu 14. Dec 2006, 09:56
Location: TU Berlin
Contact:

SceneGraphPath

Post by gunn » 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.
jReality core developer

timh
Posts: 28
Joined: Wed 28. Jun 2006, 20:30
Contact:

Post by timh » Tue 20. Mar 2007, 15:39

As far as I understand this. A class - say SelectionPath - that derives from SceneGraphPath and has an optional aditional last Element of type Object would do the job without extending the core with something that is only used outside the core. the extra methods you mention would reside in that class and would return a SceneGraphNode or a AttributeEntity or Tool depending on wether the extra last element is set or not.

Tim

User avatar
gunn
Posts: 323
Joined: Thu 14. Dec 2006, 09:56
Location: TU Berlin
Contact:

Post by gunn » Wed 21. Mar 2007, 11:03

I would be interested in hearing specific reasons why we could not extend SceneGraphPath itself rather than introducing a new class. One of the overriding design principles of jReality is expressed in the saying, "Why have two classes when one will do?" For example, can anyone provide a specific example (even if only hypothetical) demonstrating the disadvantage of extending SceneGraphPath itself?

The fact that the added functionality is not currently used in the core does not in itself provide a counter-argument in my view. We might in fact find applications where it might be useful -- for example a PickResult might consist of a SceneGraphPath whose last element is an instance of PickHit. This example demonstrates nicely that a scene graph path is exactly the same as a selection. Having two classes for one concept is a questionable design principle.
jReality core developer

User avatar
steffen
Posts: 186
Joined: Fri 16. Jun 2006, 13:30
Location: TU Berlin
Contact:

Post by steffen » Wed 21. Mar 2007, 12:55

gunn wrote:I would be interested in hearing specific reasons why we could not extend SceneGraphPath itself rather than introducing a new class.
* The equals(..) method is undefined for attribute entities;
* The possibility of adding objects results in "bookkeeping" in the SceneGraphPath implementation which is unnecessary now (this is not only a performance issue, it also blows up the API and makes the code more fragile);
* For the portal backend and the jrs format only "special" paths would work (paths with only SceneGraphNodes);
gunn wrote:One of the overriding design principles of jReality is expressed in the saying, "Why have two classes when one will do?"
This is new to me; why do we have a PointSet? An IndexedFaceSet with 0 faces and edges would do the job...
gunn wrote: For example, can anyone provide a specific example (even if only hypothetical) demonstrating the disadvantage of extending SceneGraphPath itself?
Counterquestion: What would we win when we extend SceneGraphPath? I think a selection should provide convenience methods to access the end of the selection and to determine its type. Also a reference to the SelectionMangager might be useful and maybe other selection-related functionality. Adding all this to SceneGraphPath would blow up the API and confuse people who just want to set an camera/avatar path or who try to write their own tools. Not adding this functionality would result in ugly selection-related code like

Code: Select all

if (p.getLastElement() instanceof Tool) ...
else if (p.getLastElement() instanceof PolygonShader) ...
else if ...
gunn wrote:The fact that the added functionality is not currently used in the core does not in itself provide a counter-argument in my view. We might in fact find applications where it might be useful -- for example a PickResult might consist of a SceneGraphPath whose last element is an instance of PickHit. This example demonstrates nicely that a scene graph path is exactly the same as a selection.
The PickHit (what we have is called a PickResult) consists of a SceneGraphPath, which it needs since it (also) returns the pick in world coordinates. So if we decide that a PickResult should be a SceneGraphPath with a final "Hit" object, this object would also have to reference its own path. Then when getting a pick result (which would be a SceneGraphPath) we would have to try to cast the last element into a hit object (which then references the path from which we just extracted it)... In java:

Code: Select all

PickResult pr = pickSystem.performPick(..);
vs.:

Code: Select all

PickResult pr=null;
SceneGraphPath p = pickSystem.performPick(..);
try {
  pr = (PickResult) p.getLastElement();
} catch (ClassCastException cce) {
  // this should never happen...
}
if (pr != null) ...
Just as for the selection, a pick result should provide special pick-related functionality as it currently does.
gunn wrote:Having two classes for one concept is a questionable design principle.
In my opinion both the selection and the pick result have to provide their very own functionality which we can not merge.

Post Reply