Re: considering G3DGeometry

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