[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
http://inkubator.idevgames.com/
Working together to make great software.
- [Gnu3dkit-discuss] considering G3DGeometry, Brent Gulanowski, 2003/03/10
- Re: [Gnu3dkit-discuss] considering G3DGeometry, Philippe C . D . Robert, 2003/03/16
- Re: [Gnu3dkit-discuss] considering G3DGeometry,
Brent Gulanowski <=
- Re: [Gnu3dkit-discuss] considering G3DGeometry, Philippe C . D . Robert, 2003/03/16
- Re: [Gnu3dkit-discuss] considering G3DGeometry, Brent Gulanowski, 2003/03/16
- Re: [Gnu3dkit-discuss] considering G3DGeometry, Philippe C . D . Robert, 2003/03/21
- Re: [Gnu3dkit-discuss] considering G3DGeometry, Brent Gulanowski, 2003/03/21
- Re: [Gnu3dkit-discuss] considering G3DGeometry, Philippe C . D . Robert, 2003/03/23