Re: [simspark-devel] discussion

[Yuan X. <xuy...@gm...>]

2007/2/3, Oliver Obst <Oli...@ne...>:
> sounds all quite good.
> I've also found this hints for timing the physics loop (in a computer
> game) here: [1], it's an interesting read, at least. From this page,
> there are also more interesting articles.
>
> I'm also re-directing this thread to the simspark-devel mailing list
> (I know you're all subscribed :-), because the advantage of this list
> is that everybody interested can read what's going on and the emails
> get archived automatically. Please, let's continue our discussions
> there.
>
> cheers
> Oliver
>
> [1] http://www.gaffer.org/game-physics/fix-your-timestep/
>

The article is great!
There is a similar implementation in the simspark ( See void
SimulationServer::Step() ).
Set the mSimStep to 0.01, then the physics will run in 10ms step.

I face a problem when try introduce the threads:
there is only one scene information in the simulator,
then, different threads can not operate the scene information at the same time.
For example, when the agent-management-thread encodes the perception messages,
the scene information should not be changed,
so the physics-thread should be hang up.
As a result, this kind multi-threads is meaningless, I think.

Maybe we need a buffer, like the frame buffer in OpenGL,
saving the scene information which will be handled by
agent-management-thread to the buffer.
But it is not a straight-forward work, for the scene information is
stored in different objects.

If there is a class or struct represent the scene information, the
work will be easier.
But the plug-in mechanism makes the scene changes, so build such a
scene class is not simple.

Any ideas?

-- 
Best wishes!

Xu Yuan
School of Automation
Southeast University, Nanjing, China

mail:   xuy...@gm...
          xy...@ya...
web:   http://xuyuan.cn.googlepages.com
--------------------------------------------------