Re: [simspark-devel] discussion

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

Hi Joschka,

On 05/02/2007, at 9:30 PM, Joschka Boedecker wrote:

> I think we could start with 1a) and guarantee mutually exclusive
> operation on the SceneGraph between the different threads. You can  
> set a
> Mutex for this if you want to use the SceneGraph, then you'll have
> exclusive access, and then remove that Mutex once you're done. This  
> way,
> another thread might have to wait for a while to get access, but  
> you'll
> have correct data all the time. The only way the system could  
> 'hang' is,
> if a Mutex doesn't get removed. But even then, there are time out
> mechanisms that can be used. Since the physics thread runs a lot  
> faster
> than visualization and agent updates, these locks won't occur too  
> often,
> I think. If 1a) turns out to be too slow, we could consider option  
> 1b).

1a should at least not be (much) slower than using no separate  
threads at all. If we find a way to program everything so that we can  
switch back to single thread easily, that would be really great (for  
debugging), but I'm not sure if this can be done.

> What visual information do you mean? Position and orientation are  
> needed
> by both physics and visuals, and stuff like textures and the meshes
> (usually) don't change much I think. Oh, but maybe you're thinking of
> animation data?

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.

> I think having all the necessary information in one scene structure
> (like the scene tree) is nice if you have internal rendering.

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.

> If you want to copy, you have to lock anyways if you're using  
> threads, I
> think. Otherwise you might have inconsistent data to display.

yes, but I'm not sure if this would be a big problem. The updates  
between single steps are usually not large, so it should be possible  
to ignore inconsistencies. But as I said, I'm not sure.

>> - if we want the agents to run as fast as possible, we should use
>> something like a syncmode in 2D, but for giving the agents enough
>> time to think, the simulator should wait with the physics if it is
>> faster than real time for competition settings.
>>
>
> Yeah, a sync mode would definitely be a nice feature :-)

especially for machine learning and a new internet league, some speed  
improvements would be really good.

We also have to think about a logfile format... and what get's logged  
with the more complex bodies anyway. A mpeg or quicktime from a match  
would certainly be nice (and probably not much bigger than  
textlogging everything), but if you want to kind of replay the match  
from every possible angle, that's not enough. We should think about  
something smarter, maybe --- the logging takes also a lot of cputime.  
Logging keyframes and updates, maybe, or ...

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