Re: [Gnu3dkit-dev] G3DRenderer.h

[Brent Gulanowski]

On Sunday, March 16, 2003, at 06:26  PM, Philippe C.D. Robert wrote:

> On Sunday, March 16, 2003, at 11:49  Uhr, Brent Gulanowski wrote:
> > > An instance of G3DRenderAction is used for this purpose. It 
> > > traverses the graph and renders the scene by first calling the 
> > > appropriate methods on its renderer (context management, optimised 
> > > state handling, shader setup and so on) and then requesting the 
> > > geometry to draw itself.
> > >
> > > So you can use n render actions using m different renderer backends 
> > > concurrently on the same scene. This also makes life in a 
> > > multithreaded environment much easier as this is non intrusive.
> >
> > You can solve this all for me with one question: who calls 
> > [someGeometry drawGeometry]? Does the Render action call it or does 
> > the shape call it? I can honestly see it in both ways, and neither 
> > looks any different from where I'm standing. When a geometry instance 
> > receives the drawGeometry message (from whomeve), does IT then call 
> > [someRenderer objectInstance:objHandle] or [someRenderer 
> > drawPolygons:myPolys params:myParams]?
>
> The render actions calls drawGeometry: on the geometry. The geometry 
> then uses the passed renderer to draw itself. As far as I can see it 
> this is done using [someRenderer drawPolygons:myPolys params:myParams] 
> for example (if the node has not yet been compiled). Now if you first 
> compile the nodes the renderer can create an optimised rep for 
> internal usage. How this will look is still far away, I am afraid. But 
> I originally had the idea that objectInstance: would be used whenever 
> a geometry node has been compiled beforehand. Maybe this mechanism can 
> also be used whenever a geometry node is shared by multiple shapes, 
> though.
>
> Does that make sense to you?

Your words are quite sensible. This compilation process is of very high 
importance and interest to me. I suppose my concern is how effective 
and efficient compiling itself can be. I certainly think it is 
essential. The problems of course are that a compiled group of nodes 
(what I like to call a flattened sub-tree) can no longer be edited. Of 
course, what I have only just learned is that the compiled node is 
retained by the renderer, meaning that the original, uncompiled 
geometry is still held in the scene graph. I approve of that, memory 
waste notwithstanding, because in a modeller, the user can still go 
back and edit, and the enclosing sub-tree can be re-compiled. For me, 
the issue then is, how do I not waste the work done by compilation? Can 
the system leverage that in some other way? What form ought one to 
compile a sub-tree into? (What forms are there?) BTW, I'm asking these 
q's out loud, not asking you to answer them. :)
> > Sidebar: why isn't -objectInstance: call -drawObject: ?
>
> Because it is originated from RiObjectInstance(), but you are right 
> that the name is not optimal in the context of Cocoa, maybe draw: or 
> drawObject: would indeed be better.

I like drawObject: -- it is more in line with the other draw... 
selectors.


Brent Gulanowski                address@hidden
--
If you paid a million monkeys to type on a million keyboards, 
eventually they would produce Micro$oft Windows.