Re: [Gnu3dkit-dev] 3D file formats

[Philippe C . D . Robert]

On Dienstag, Oktober 8, 2002, at 05:11  Uhr, Matt Brandt wrote:
> On Monday, October 7, 2002, at 09:19 PM, Brent Gulanowski wrote:
> > I'm personally of the idea that everything not a leaf is a group, and 
> > moreover that a leaf is really just a group of one. I'd be interested 
> > in your thoughts on whether there could simply be one G3DScene class, 
> > which would be a node, a group, and a world all in one, depending on 
> > what attributes were present. Then the propagation of recursive calls 
> > down the tree would involve a message to the node followed by a 
> > message to the appropriate attribute. No attribute of that type means 
> > no message is sent, but the general call is still propagated to the 
> > child nodes. Even a pile of geometry is just another attribute.
>
> This makes perfect sense to me. I think the more the model can be 
> simplified the more useful it is. I also think that an elegantly 
> simplistic design is easier to do great optimizations with.

I agree with you that simplicity is the key to success. But it must not 
become too simple, otherwise it won't be as useful as possible. NeXT's 
3DKit is an example which is maybe a little too simplistic with the 
consequence that the programmer has to do a lot of its own.

> > Of course I'm afraid of how slow this might be. But if it's workable, 
> > every node would in fact be a sort of dictionary. Maybe even a 
> > standard NSDictionary. It would be sent a message asking if it had a 
> > key matching the attribute. If so, work with the attribute. If not, 
> > ask for the children attribute and do the same with them, if they 
> > exist. Do you think that that would just be impossibly slow and too 
> > generic to be workable? I mean, the attributes would have unique 
> > classes, and they would be optimized.
>
> I think that if you just implement this in the straightforward way, 
> where you actually send the message to each child, without cached 
> knowledge of whether or not they are acting on the messages, you will 
> get very slow results very quickly. (did that make sense?)

Yes. As you say, knowledge is very important - the more you know about 
the scenario the better you can optimise.

> On the other hand, it is pretty easy to have a child return a status 
> to each message that indicates whether it, or any of it's children, 
> acted on the message, and have the parent cache this status to keep 
> from sending messages that aren't needed. That will quickly prune the 
> message tree so that it won't get too busy. This requires that a child 
> send a message up the parent chain when something enables a message 
> (like adding an attribute).
>
> > I am fascinated by the dynamism of Objective-C, and I am very curious 
> > how far it can be taken before it runs away with itself.
>
> I really like Objective C. It is easier to write good code in it than 
> in most other languages. Of course, it is easier still to write bad 
> code in any language :)

:-)

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