|
| From: | Brent Gulanowski |
| Subject: | Re: [Gnu3dkit-discuss] gnuDKit.info: RenderKit - questions |
| Date: | Wed, 30 Oct 2002 17:26:22 -0500 |
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.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'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 address@hidden http://inkubator.idevgames.com/ Working together to make great software.
| [Prev in Thread] | Current Thread | [Next in Thread] |