Re: [Gnu3dkit-discuss] considering G3DGeometry

[Philippe C . D . Robert]

On Tuesday, March 11, 2003, at 05:57  Uhr, Brent Gulanowski wrote:
> I have been struggling with the issue of what it means for a scene 
> graph to be object oriented. I have been studying the MVC pattern 
> recently as well, and the two have led to an idea.
>
> It seems to be taken for granted that geometry data is part of the 
> scene graph. What if this is not correct? What if the representation 
> and the object were strictly distinct from one another? Not just a 
> class distinction, as G3DNode is distinct form G3DGeometry, but a 
> model/view distinction. It is taken for granted that the 
> representation of 3D objects in interactive rendering is a vast 
> simplification. So why is it not the case that the representation is 
> considered a part of the renderer component, instead of the scene 
> graph?

The geometry is actually not element of the scene graph, it is an 
'attribute' to graph shape nodes, so your reasoning is not entirely 
correct. Moreover the geometry does not contain the actual 
representation of the scene object, but only its description - imagine 
a geometry object describing an algebraic surface, for example.

> I would like to propose that, instead of holding a reference or 
> pointer to a geometry object, that the scene graph merely holds a 
> name. It uses this name when specifying itself to the renderer. The 
> geometry used is specified --once -- at load time, and used from then 
> on. It would even be best to store geometry data in a separate file or 
> files from scene graph data. Then, whenever you change renderers, you 
> will possibly also change geometric representations. For example, 
> while an OpenGL renderer would use mesh objects, a ray tracer might 
> use parametric objects. A scene graph could even be "rendered" to a 
> text context, in which case objects would be represented by strings.

What is the fundamental difference between a name reference and a 
pointer at runtime?

The idea to use different representations based on the renderer of 
choice is not bad, but I don't think it makes sense in the real world.

> If there were some facility to ensure that the various representations 
> used by different renderers were in fact parallel, so much the better, 
> but I have not pursued that problem. My main purpose is to properly 
> encapsulate object/model information, and to distinguish it from view 
> information. I am more and more of the opinion that the on-screen 
> representations of objects are view information, more to do with the 
> display context than with the objects themselves. Likewise, I see the 
> renderer as a view controller class, the complement to the drawable.
>
> Comments and responses would be very welcome.

Talking MVC, a scene graph is a data type and hence it provides the 
model only, actions such as the G3DRenderAction are the controllers 
which operate on this data, and the camera/view duo is the view which 
is used to visualise the data.

In other words, the scene graph only contains the data to be used by 
the renderers to visualise the respective scene, this includes the 
geometry but also transformations, shaders and likewise data. Therefore 
you can for example render the same scene using different renderers to 
generate different results (in any aspects) without touching the scene 
data at all. So the model is indeed completely separated from the view.

-Phil
--
Philippe C.D. Robert
http://www.nice.ch/~phip