Re: [Gnu3dkit-dev] gnuDKit.info: RenderKit - questions

[Brent Gulanowski]

On Monday, November 11, 2002, at 04:27  PM, Philippe C.D. Robert wrote:
> > A "Scene" is an abstraction. A "Scene rep" is a particular 
> > construction of data representing that scene for a particular ... can 
> > I say "context"? Maybe we need to consider a context -- not an OpenGL 
> > Rendering Context, but a general scene *Presentation* context. That 
> > would include files and serialized forms (say, for transmission), 
> > scan line rendering contexts (both raw arrays and visibility sorted 
> > lists and trees), offline rendering contexts (for ray tracing, 
> > radiosity and other lighting calculations), scene databases (pure 
> > scene descriptions which are designed for freeform, database-style 
> > access), and even textual summaries (for example, in an 
> > NSOutlineView).
>
> I guess this is what I call scene rep, no? ...:-)

Sorry. What I meant was that the Presentation would not necessarily be 
an explicit class -- it would be the implicit environment where the 
scene rep was used. And then I listed a bunch of examples of scene reps 
(doh!) ;-). Although maybe multiple types of reps would work in 
different Presentation contexts... If you have multiple reps of a 
scene, how do you know which one to use? Is that pre-determined? 
Considering our inspiration: how does NSImage know which image rep to 
use?
> > It would be interesting if we could create a structure which could 
> > hold combinations of these sorts of reps <...>
>
> This is what I had in mind - more or less - but there are problems 
> with this concept. Ie. how would you manipulate (read: transform) an 
> object which influences more than one representation, how would you 
> traverse a scene, how ...

Well, the painful way is if you still have the "original" interactive 
rep, you have to regenerate the other reps. But if the fast display 
reps can still be referenced by decoupled structural data, it might be 
possible that only a small chunk has to be re-evaluated. If the data is 
stored in a big array, that will be hard. That's why I was using the 
term "list" before -- if you had lists of arrays, which maintained some 
of the structural divisions, you could create the changes locally and 
then write out a new array and dispose of the old one.
> > [snip]
>
> Reading all this somehow makes me think that the approach of having a 
> central scene graph which may manage subscene in various 
> representations is more suitable. It is more convenient and easier to 
> use w/o loosing functionality.

I just disposed of another message that was getting too long where I 
was going to suggest a meta-graph, which contained divisions of scenes, 
instead of divisions of objects. One scene may then contain any (or 
all) of the reps considered, including a scene graph scene rep.
> > Here's a very good side effect if we can get such a thing working: 
> > sub-scene paging. If you have a scene made of sub-scenes, perhaps in 
> > a very large-chunk Octree, it could contain nothing by G3DScenes -- 
> > basically pointers to individual scenes, which would only load their 
> > scene reps when necessary. This could proceed down the hierarchy as 
> > many layers as needed. When a sub-scene is required for rendering, 
> > the Scene is swapped out for the scene rep, which is attached to the 
> > parent node, as if it had been there all the time.
>
> I guess this can also be achieved by using special kind of subscenes 
> as part of the central scene graph.

Like a proxy?

--
Brent Gulanowski                                address@hidden

http://inkubator.idevgames.com/
Working together to make great software.