Re: gnuDKit.info: RenderKit - questions

On Wednesday, October 30, 2002, at 05:08  PM, Philippe C.D. Robert 
wrote:

>> This suggests that my guess above (about how actions work) is wrong, 
>> and that RK pulls the strings on the renderer using the Protocol 
>> methods. That would require controller objects for nodes, attributes 
>> and geometry, as well as the camera. E.g., for drawing, a DRAW 
>> mechanism walks the tree, optionally submitting a bounding volume (if 
>> the renderer responds to some initial query: "-usesBoundingVolumes" 
>> with "YES"), submitting attributes and geometry, whereon renderer 
>> replies with whether or not to continue to the current node's 
>> children. RK can still do attribute/state optimizations using its 
>> internal formats.
>
> Again, this is somewhat what I have in mind. This ensures proper 
> decoupling of graph management, rendering code and concrete rendering 
> techniques.
>
> The only big showstopper for this approach I can see right now is that 
> it will be too slow because of too much OO overhead.
>
I think maybe we need to do some work on patterns or other design ideas 
that will let us use the OO features we need for safety and faster 
development, but avoid excessive dynamic messaging. We can cache 
selectors for a bit of a speedup. That requires careful management. We 
could consider some more ways to be lax about the privacy of certain 
data, while still having boundaries.

I'm thinking something like requiring a sender to identify itself when 
one requests a pointer to ivar data. The sender would have to be a 
certain "friend" class, and we could even set a "friend" ivar so that 
we don't accidentally having more than one friend instance accessing 
data.

The real effort is simply reducing the number of messages, making sure 
no messages are sent from within loops, and other such things -- but we 
can worry about optimization later.

--
Brent Gulanowski				[email protected]

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