gnu3dkit-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnu3dkit-discuss] considering G3DGeometry


From: Brent Gulanowski
Subject: [Gnu3dkit-discuss] considering G3DGeometry
Date: Mon, 10 Mar 2003 23:57:12 -0500

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?

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.

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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]