Re: [Gnu3dkit-dev] G3DRenderer.h

[Philippe C . D . Robert]

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?

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

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