Re: [simspark-devel] discussion

[Joschka B. <jbo...@un...>]

Hi Oli,

Oliver Obst wrote:
> [...]
>> 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.

Of course, you're right. Sorry, I forgot about the plan to change to an 
external graphics lib for a moment there :-/

>> 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.

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.

>
>> 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.

We can try with locking first and then see what happens :-) I think the 
locking shouldn't be a big problem either though.

>
>>> - 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 ...

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.

Cheers,
Joschka