Re: considering G3DGeometry

Brent Gulanowski <[email protected]> Sun, 16 Mar 2003 18:07:00 -0500
Newsgroups gmane.comp.gnu.3dkit.general
Message-ID <[email protected]>
Sorry I answered part of this in another message, but only now recalled 
my answers to the questions below.
On Sunday, March 16, 2003, at 02:33  PM, Philippe C.D. Robert wrote:

>
>> 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?

You can reference an object that is not yet actually loaded from a 
file. Pointers mean you must load everything up front. An ID means you 
can be lazy about it. What if the storage is far away? Or what if some 
objects may never get rendered -- no need to load them.
>
> 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.
>
Please elaborate. I have been thinking about this a lot and its seems 
worthy of investigation, but if you know any serious reasons that would 
make it unrealistic, I would appreciate if you could mention them. If I 
want to browse a scene graph using, say, NSOutlineView, why not make it 
possible to use the exact same interface to interact with the scene as 
would be used by a graphical renderer? Similar to an outline view would 
be a custom, symbolic graphical representation of the scene. It also 
means that the scene can be much, much bigger without memory problems 
-- leave the representations on disk until they are needed. This 
alleviates need for paging a single, gigantic file. It also could be 
used to incorporate LOD and other switch groups.

--
Brent Gulanowski				[email protected]

http://inkubator.idevgames.com/
Working together to make great software.