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

[Philippe C . D . Robert]

Hi,

On Monday, November 11, 2002, at 11:18  Uhr, Brent Gulanowski wrote:
> 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?

I agree that this idea was less optimal, it also was too complex for 
what I had in mind. I thought about all this and now I think the best 
solution is that we always use a scene graph composed of G3DNodes. Now 
in order to be able to render data which comes in another 
representation we include this using a G3DPlugin node. What do you 
think?

Now the next question is who guarantees consistency, how can we make 
sure that an action always knows how to handle a custom plugin ... I 
guess this requires some more brain cycles...:-)

<snip>

> > > 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?

Exactly. This is also addressed by the plugin node concept. Hmmm ... 
maybe we should call this thing even G3DProxy?

-Phil
--
Philippe C.D. Robert
http://www.nice.ch/~phip