[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.

Philippe C.D. Robert

reply via email to

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