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

[Philippe C . D . Robert]

On Sunday, November 10, 2002, at 11:04  Uhr, Brent Gulanowski wrote:
> > Of course, I didn't meant to be 'offensive'. What we need *know* is a 
> > plan how to start with the real work, otherwise 0.4 will never take 
> > off... BTW I am not even sure if 0.4 is a good number, because it 
> > sounds like a simple successor to 0.3.x .... what do you think?
>
> No offense taken. ... I don't have any opinion on version numbers -- 
> it's rather arbitrary unless you produce a proper feature release 
> schedule (aka roadmap).

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.

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

<snip>

> I know it is common to think of scenes as being a combination of 
> static objects which can be broken up into visible polygon lists, and 
> dynamic objects which require live visibility determination, but that 
> is an annoying artificial distinction. Buildings fall down, bridges 
> move, landscapes change -- nothing is really static. Is this a 
> distinction we will be forced to maintain for the forseeable future?

On the fly tessellation can be quite interesting, esp. for dynamic 
level of detail rendering. But then this is computation intensive and 
not suitable for every object in a scene. In general it makes sense to 
treat objects differently depending on their kind - computer resources 
are and will always be limited!

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