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

[Philippe C . D . Robert]

On Monday, November 11, 2002, at 09:25  Uhr, Brent Gulanowski wrote:
> On Monday, November 11, 2002, at 02:31  PM, Philippe C.D. Robert wrote:
> > Well, there was a roadmap for my initial plans wrt the next version. 
> > But then everything seems to have changed...:-) This leads to a good 
> > point, we need a feature list for the new 3DKit. I try to come up 
> > with some input, but you are all welcome to contribute. My goal is to 
> > have an initial version available on the website within the next >> week.
>
> Erm, I already wrote a starter feature list. It was part of my dev 
> plan overview ([Gnu3dkit-discuss] Development Plan Topics - Overview), 
> with section numbers and everything... I'm getting the feeling that 
> that really turn anyone's crank :\.

No, no, I mean something different (I read your email, of course). I 
mean more of a plan wrt what kind of graphics/API features will be part 
of what versions/milestones. This includes the definition of these 
milestones as well. Ie. what will be in the first version (0.4) of the 
new architecture, what will be the next step, what does 1.0 mean to us 
etc.

> > > > Wrt the work, for me there is one last real issue which I do not 
> > > > yet really see through, the scene representation. What if sb would 
> > > > like to use not a scene graph but an octree or some CSG? How can we 
> > > > offer a good API to incorporate such  scenes in the 3DKit? Ideas?
> > >
> > > I am seriously interested in this issue. I think it would make sense 
> > > to always have a scene graph, but allow for chunks of that graph to 
> > > have alternative scene representations embedded within them. We need 
> > > to decide what information we want to preserve in the scene 
> > > representation. Do we want to preserve the hierarchical nature of 
> > > represented objects? Whenever possible. But this information is 
> > > filtered out during rendering, so maybe we can find a way to 
> > > decouple the information about object assembly from the geometric 
> > > information.
> >
> > I like this idea of having 'sub scenes' in different reps. So my idea 
> > was (as seen in the UML diagram) that a scene uses a scene rep. Now a 
> > scene can have multiple reps which do not have to represent the same 
> > data. The problem here is that I do not yet see a good solution about 
> > how to handle that internally, ie. how actions can be written so that 
> > they can process any kind of scene reps.
>
> > Maybe your approach of having a scene which is a scene graph 
> > containing some special purpose nodes if needed (which in turn 
> > contain scene data in other representations) is better/easier to 
> > implement and work with... I guess I need to spend some more cycles 
> > on that.
>
>
> OK, I'm hip with the idea of the over-arching scene (as opposed to 
> scene rep) -- I see what you mean about handling multiple reps, sort 
> of like switching gears with the engine running full speed: GRIND. 
> Plus it means having to implement a "gearbox". Here's where I've let 
> myself get confused, and need to clarify.
>
> 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? ...:-)

> It would be interesting if we could create a structure which could 
> hold combinations of these sorts of reps, but probably we would 
> instituted some kinds of rules -- most like restricting the scan line 
> renderer sorts together such that they can't have sub-scenes of reps 
> that are suited to the more generalized, offline, or interactive 
> presentation contexts. Although the other way around might be alright.
>
> I have an idea: every discreet scene is represented by a G3DScene. The 
> parts of the scene are made of G3DSceneReps, including such 
> G3DSceneRep classes as G3DSceneNodeRep, G3DSceneBSPListRep, 
> G3DSceneDictionaryRep, G3DSceneDataRep, G3DSceneCSGRep, with whatever 
> rules are required for sub-scenes. We can consider a facility for 
> adding and subtracting sub-scenes, and stripping off or adding a 
> G3DScene wrapper in the process. I don't know if this is analogous

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

>  to NSImage merging or not, but I don't see that it necessarily would 
> be. The real value of the Scene class seems to be that it can arrange 
> the invisible production of specialized scene reps using the master 
> G3DSceneNodeRep. However you won't be able to re-generate a 
> SceneNodeRep from the stripped reps unless we can successfully 
> preserve the structural data -- hopefully as a decoupled parallel data 
> set. Maybe a DictionaryRep could be coupled with BSPs and the like, 
> removing the structural data from the data needed for rendering, but 
> there if needed to re-generate a more interactive scene rep.
>
> Granted that would be a lot of work to get working properly. It's 
> usefulness depends on how it conserves storage resources compared to 
> just maintaining multiple different reps of the same scene.

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.

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

Anyone?

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