[Top][All Lists]

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

Re: [Gnu3dkit-discuss] considering G3DGeometry

From: Brent Gulanowski
Subject: Re: [Gnu3dkit-discuss] considering G3DGeometry
Date: Sun, 16 Mar 2003 18:07:00 -0500

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                                address@hidden
Working together to make great software.

reply via email to

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