Re: Re: NSOpenGL RenderKit

On Wednesday, October 23, 2002, at 06:44  AM, Philippe C.D. Robert 
wrote:

> This is a very interesting issue. The GNU 3DKit was developed as a 
> OpenGL based 3D framework only, although the idea to write it came 
> from NeXT's 3DKit. Now my research interests have shifted a little and 
> I am less interested in pure OpenGL based stuff. Up until recently I 
> did not think of making the GNU 3DKit more generic, though. But then I 
> started thinking about how the next gen 3DKit could be used to render 
> a scene using different techniques (I am particularly interested in 
> ray tracing, but other scanline based techniques would be interesting 
> as well). My idea was to manage a scene in a scene database which 
> could then be rendered by different renderers. Of course this needs 
> much more thinking, but I now believe that it is worth it. This has 
> the drawback, that a running version of it will be even more delayed 
> though.
>
> Is this really worth the effort, is anyone else interested in using 
> such functionality?
>

I've wondered about this, too. I think the difficulty is that the more 
optimized the OpenGL renderer is, the more closely tied it is to the 
scene graph representation. (Actually, this is an area I'm weak on -- I 
understand the idea of resorting the polygons based on state, but not 
how this works nicely with sorting them based on visibility.) Given a 
tree organized spatially, multiple scan line renderers could be 
supported by providing a different method, and renaming the OpenGL 
render method to something like "renderToOGL". For a ray tracer, would 
the nodes still be involved directly in producing output? I can imagine 
a method that accepted a ray and returned it as reflected and refracted 
components.

Do ray tracers use polygon approximations or mathematic descriptions 
for curved surfaces? In the latter case, the scene objects would be 
fundamentally different than the objects aimed at OpenGL or another 
realtime renderer. You could have scene objects that produced their own 
approximations when a scan line renderer was used, and used their 
mathematical descriptions (if they existed) when a ray tracer (or other 
offline renderer) was used. Is this too problematic? Would anyone want 
an abstract scene representation that could adapt itself to the 
renderer? The predictable solution is that you have a completely 
different set of node classes, because the overlap in functionality is 
too small. But it would be nice, for an artist/designer, to produce one 
scene specification that could be re-used with different renderers, and 
optimized itself for each of them.

An example implementation which provides this dual representation 
(mathematical description and polygon approximation) is Quesa (aka 
QD3D) . It is designed for plug-in renderers, but no one has ever 
produced a new one -- there are three built-in: software, interactive 
(OpenGL), and wire-frame (also OpenGL). Objects are tessellated 
dynamically. I'm not sure how much we can learn from Quesa, since it is 
built in C, albeit using as much of an OOP-inspired class design as 
possible with C (it even supports runtime class loading). Also it is 
not yet optimized -- they designed and built the entirety first, and 
started optimization and tuning within the last few months. 
Unfortunately I have not studied Quesa sufficiently to remark 
intelligently on its renderer interface design. If you haven't grabbed 
the source, it is available from cvs at

:pserver:[email protected]:/cvsroot (password: 
anonymous)

module name is quesa. There is a working (99%) Project Builder project. 
Message me off-list for help building it. I believe that quesa is worth 
study, if only because it is so carefully designed, and it's behaviour 
is so well documented (as QD3D, which they aim to emulate exactly and 
regularly test themselves against).
--
Brent Gulanowski				[email protected]

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