Hi Mahdi and All,
(CC Joschka, Markus and Oliver)
This is a long time that this task is on simspark TODO, and I hope that
Joschka can comment on these emails. I'm sorry but I'm not agree with
you (maybe it is because of lack of enough information on my side).
IMHO, if simspark's monitor + ogre is equal to ZigoratAssistant, we
might decide to drop Ogre from simspark's TODO and mark ZigoratAssistant
as the official monitor for simspark. If not, I think there are good
reasons for adding ogre support to simspark. (as I said, I'm not sure
about all what I'm saying, so I'll wait to hear from Joschka, Markus or
Oliver about it. Feng might be able to assist too).
1. We definitely want something more than a simple monitor (it could be
ZigoratAssistant though).
2. MC work is voluntary, so if someone want's to work on visual effects,
he can do it. We can have a prioritized list of tasks (I've called for
MC members' opinions several times), but at last there is no force on
anybody to select what he wants to do.
3. In fact (I think) using something like Ogre or OpenSceneGraph, could
really improve performance. Usually these graphic engines do
optimizations to make rendering faster. Ogre rendering loop is
customizable and it does not necessarily consume 100% CPU.
4. I wonder if we necessarily will need 2 sets of meshes. Also, it is
possible to export ogre meshes from blender, so at worst we can easily
generate ogre meshes from blender obj files.
5. I think that Ogre integration will not make code contribution harder
as it'll be cleanly separate from the other parts of the code. Anyway,
I'll have a look at Robolog's 2007 3DD code to be able to talk more
knowledgeable!
6. About node names, there is no need to use the same names for ogre and
simple monitor. First it might be possible to create a mapping so that
we can use unique names in Ogre only. Also, node names in ogre is
optional, and we might be able to work without using them.
Finally, (at least currently!) I don't consider myself the right person
to discuss this matter, and I hope others could assist in this
discussion. Currently, I assume that we are going to add Ogre support to
simspark (it could be through ZigoratAssistant or integrated into
simspark), that's enough for the plan!
Good luck,
Hedayat
/*Mahdi <zig...@gm...>*/ wrote on ۰۸/۱۲/۰۴ 12:30:03:
> 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...
> <mailto: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...> <mailto: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
>>
>
|
