Re: [simspark-devel] [Fwd: Re: MC Plan/CMake integration]

[Mahdi <zig...@gm...>]

Hi Hedayat

  In last mail, I only talked about the problems this would cause on
simsparks users. Now just consider it again, this time for the developers.
I'talk about both good points, and bad points of this integration:

Good points:
  * We could have a user interface setup easily
  * We could have better graphics
  * We could better use the graphics hardware for simulation monitoring

 I can't think of much more

Bad points/controversies:
  * Not much a user interface needed for a basic monitor, consider the 2D
league's rcssmonitor, Almost no GUI
  * Currently we have sky, seas, transparent textures, lightings, and a
fully working scene graph usage, In my opinion other graphic effects or
possible usage of shaders, do not help development of the simulator itself,
nor add new usefull features for the simulation.
Consider that we are going to advance the simulator, we could use the effort
of the community on more important matters.
  * Although this is a good point, currently our simulation graphics are
simple, and we should run on more capable graphic cards, even a typical 128M
memoried graphic card can do the work. (But not the typical intel cards on
laptops, these should be considered buried!)
  * If the ogre integration is put in an optional way, then there should be
two types of meshes, both having the same name and version, and be updated
together. Special care should be paid to this matter.
  * the ogre handling loop of the graphical rendering costs a lot of code.
This make would surely make contributing to the simulator harder both for
the ogre development, and for the simple monitor development. The changes
should not collide.
  * Node names should be handled so that no two nodes have a same name,
which is a just overhead in the simple monitor.
  * Ogre startup just without any material loading needs about two seconds.
This is not a huge problem, but I don't like simpark to startup in 5 seconds
in a near future.
  **** Ogre consumes all of CPU's usage when runned, cause it has a loop
like this: start frame - render frame - finish frame. This would absolutely
effect the simulators performance. Check it out if you don't beleive me!

  There would be more if I want to say more. And consider that if we change
the simulator's data exchange protocol with the monitor, any guy can create
a monitor or trainer for their own usage, which would essentially fulfill
their own needs, and there is one application in simulators packages, which
currently is using the OGRE, so I don't think it's wise that ogre usage be
duplicated in the simulator.


Cheers
Mahdi


On Thu, Dec 4, 2008 at 12:08 AM, Hedayat Vatankhah <hed...@ai...>wrote:

>  Hi Mahdi,
> I think OGRE Render system could be an optional part of the simulator, so
> there is no problem with having it in the simulator. And 8mb dependency is
> not too much I think (cegui and ois are small enough). Finally, even
> currently
> Intel graphic cards are not much usable... :(
>
> Good luck,
> Hedayat
>
> *Mahdi <zig...@gm...> <zig...@gm...>* wrote on ۰۸/۱۲/۰۳
> 12:35:44:
>
> Hi Hedayat and Feng
>
> Sure, that would be great. You might start with RoboLog's 2007 3DD source
>> (I think they have implemented some OGRE related stuff for simspark), or
>> start from scratch. Also you might be able to cooperate with Zigorat people,
>> but I'm not sure about it. It seems that (as Mahdi told me) ZigoratAssistant
>> is not going to replace rcssmonitor3d (formerly known as monitorspark ;) ),
>> so providing OGRE support inside simspark is still a separate task I think.
>> (?!)
>> Anyway, I think we should discuss about it after ChinaOpen 2008.
>>
>
> I was against ogre entrance in rcssmonitor3d, since it required a 33Mb
> download excess on source compilation of the simulator, and 8 Mb excess on
> only installing binary packages in Fedora systems. That was why I did not
> want ZigoratAssistant to get in the simulator's code. This measures are only
> for the ogre's size, for sure the real download size is much much more,
> cause for sure there are some other packages to be installed for the
> rcssmonitor3d to be able to work correctly with ogre, like OIS, CEGUI, Cg,
> etc. Just think about the updates of ogre or it's packages, which would put
> lots of difficulties on the developers for tuning the sources. (Although
> this is much much smaller problem than the first one). Currently the
> rcssmonitor3d is working well on systems with low graphic processing
> capabilities, but introducing ogre to the monitor, will sure make it
> difficult (although with its really hich quality code) for graphic cards
> like intel's series to continue rendering the simulation @ 50 fps. Take a
> look at all these, and please make it simple for the simulator to be
> compiled more independently and be runned on most regular hardware.
>
> Cheers
> Mahdi
>
>