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

[Brent Gulanowski]

On Saturday, November 9, 2002, at 03:53  AM, Philippe C.D. Robert wrote:

> Hi
>
> On Saturday, November 9, 2002, at 03:59  Uhr, Brent Gulanowski wrote:
> <snip>
> > > uh ... did you do too much C++ programming lately? ...:-} But in 
> > > general - for the exposed API - please avoid direct ivar access, 
> > > esp. in ObjC! If there is a speed penalty it is certainly not caused 
> > > by simple accessors. Or do I missunderstand what you mean here?
> >
> > I dunno, Phil, I'm just trying to come up with some brainstorming to 
> > compensate for your wet-blanket worries. If you promise not to write 
> > about "big showstopper" problems, I promise not to diverge into 
> > fragile non-OOP techniques for circumventing them. Hey -- this is 
> > just the discussion list, after all.
>
> 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).
> 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.

Do we want to be able to preserve information about non-polygon 
primitives? Ideally. But polygons have to be produced prior to 
rendering (in some renderers, at least). What little research I have 
been able to do lately suggests that subdivision surfaces may be 
valuable here. There is a chance that hardware support for subdivision 
surfaces will become common -- ATI's TruForm comes to mind, though I 
can't recall if it the same. I think subdivision surfaces are not at 
odds with the scene graph -- but it may require duplication of data. 
They might also be able to provide CSG without using voxels (I'm weak 
in this area).

Then the question is, what about speedy rendering? Fast drawing 
pipelines demand triangles -- they are oblivious to structural 
organization or semantics. I would like to discuss multiple 
representations being used simultaneously. Or again, decoupling could 
be sufficient, as long as vertex sets are a constant size or we can 
find an effective means for managing changes to raw geometric 
information about an object representation.

So how do we decouple the data? Two possibilites:
1) provide both parametric and polygon representations, in redundant 
pairs (one of each for each object)
2) keep polygon data in large, re-sizable lists, and have the abstract 
objects point into the lists to identify their own polygon 
representations

It might even be conceivable to use 2) with BSP and other visibility 
sorted representations, but it might be unduly complicated. 1) would 
probably not work with such reps unless there was a lot of duplication, 
and then it seems unlikely that the objects could be modified without 
completely re-building the polygon reps from scratch.

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?

--
Brent Gulanowski                                address@hidden

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