[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu3dkit-discuss] considering G3DGeometry
From: |
Philippe C . D . Robert |
Subject: |
Re: [Gnu3dkit-discuss] considering G3DGeometry |
Date: |
Mon, 17 Mar 2003 00:41:14 +0100 |
On Monday, March 17, 2003, at 12:07 Uhr, Brent Gulanowski wrote:
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.
Sure, I am aware of this, what I mean is what is different internally
if you want to render an object which is either referenced by a pointer
or by a string? Not that much, I guess. Of course, lazy loading of
scene parts is another problem, but I guess this will/should be solved
at a higher level. We just have to make sure that dynamic
insertion/deletion of nodes is not too costly. I could imagine that you
could implement a custom G3DGeometrySubclass which implements lazy data
loading (and unloading, if needed), for example.
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
If you create a new geometry class how do you make sure that every
existing renderer can handle it? If you write let's say a 3D modeller,
you would maybe want to use parametric surfaces together w/ an OGL
renderer, but how would you turn the created surfaces let's say into
equivalent implicit surfaces used by another, raytracing based backend?
There are many questions like these which are not easy to answer.
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.
I am also interested in lazy loading strategies, but as I mentioned
above I think this can be handled w/ the current design.
-Phil
--
Philippe C.D. Robert
http://www.nice.ch/~phip