Re: [simspark-devel] discussion

[Oliver O. <Oli...@ne...>]

>> mmh, yeah, but maybe I'm wrong. At least if we only store the  
>> data  close to the object they belong to, that shouldn't affect  
>> the  performance. We have this graphics-engine part inside the  
>> project  (kerosin), which was really cool stuff when it was  
>> created. But as  nobody is really using and maintaining it, we  
>> should think of using  3rd party graphic libs, and they will  
>> handle this kind of data  internally. So in the simulator core,  
>> the graphics stuff would be  mainly needed for initialisation, and  
>> then be passed to the graphics  engine. Anyway, as long as  
>> additional data is only stored in the  tree, we can put in  
>> anything we want. We'd have to think about an  interface to  
>> possible graphics engines, though.
>
> Of course, you're right. Sorry, I forgot about the plan to change  
> to an external graphics lib for a moment there :-/

no worries...
the thing is that a converting from our tree to the representation of  
the Graphics Engine (possibly also a tree) costs time that you can  
save if you don't have to do it.

>> yep. Would be great to just pass a pointer to the graphics  
>> engine,  saying "here's my scene", now please render it. Well,  
>> this was the  initial idea of our approach with kerosin, and yes,  
>> it would be nice  to continue this idea even with other graphic  
>> engines. Might work, as  they will also use a tree internally. So  
>> we could use nodes of an  external graphics engine inside our  
>> scene tree, but of course that  would add a compile time  
>> dependency on a particular engine. I'm  currently looking into this.
>
> Hmm, yeah, it would be nice not to have these dependencies. Maybe  
> having two different scene trees (one for the physics, one in the  
> rendering engine) is not a bad idea after all.

it's more flexible, but you pay a price for that (see above). On the  
other hand, using the same tree means (as far as I see it now) that  
we have to change some of the fundamental classes in our framework  
(the node/leaf classes), so that we use the node class of an external  
scene graph. I'm not so sure if there's an easy way to do that  
(without breaking everything, that is). Something like 2 trees that  
share some nodes or so, but I haven't had much time to think about it.

>> something smarter, maybe --- the logging takes also a lot of  
>> cputime.  Logging keyframes and updates, maybe, or ...
>
> Yeah, something along the lines of the delta-scenes we have in the  
> current monitor maybe (just describing changes in the scene).  
> Keyframes with interpolation might be too crude for detailed frame  
> by frame analysis I'm afraid.

wasn't hesham looking for a job? ;-)

cheers
Oliver

-- 
Oliver Obst          ES208   form follows function (Louis Sullivan).
Fon: +61 2 492 16175                          http://oliver.obst.eu/
Uni Newcastle  School of Electrical Engineering and Computer Science