Menu
▾
▴
simspark-devel
|
From: <ah...@un...> - 2010-02-19 05:57:49
|
Hi, As you see in my recent commit, all classes that implement ODE physics objects are now in a separated plugin directory. The plan right now is to rename them from ODE(...) to (...)Imp. So, there would be BoxColliderImp, RigidBodyImp, JointImp et.al. in the odeimps directory. For other Physics engines, we'd have a bulletimps or physximps directory that redifine those classes with their corresponding engine-specific code. The abstract physics classes will then retrieve an instance of their corresponding implementation class from the scenegraph and upcast it to (...)Int. By delegating calls to this instance, they will be able to work with it without even knowing which engine is currently in use. All I need to know now is how to make these Imp classes show up in the scenegraph. Right now, I tried to do this with AngularMotorImp and did the following: - derived AngularMotorImp from BaseNode - put "DECLARE_CLASS(AngularMotorImp)" in odeangularmotor.h - created odeangularmotor_c.cpp with CLASS(AngularMotorImp)::DefineClass() - created an export.cpp file with ZEITGEIST_EXPORT(AngularMotorImp); - put "importbundle(odeimps)" at the bottom of spark.rb According to rsgedit, AngularMotorImp is still not showing up in the SceneGraph, so maybe someone can tell me what I forgot or even give me a step-by-step guide on how to put these classes in the SceneGraph (and later retrieve objects). thanks, Andreas |
|
From: Hedayat V. <hed...@ai...> - 2010-02-19 14:42:31
|
Hi Andreas!
On ۱۰/۰۲/۱۹ 09:27, ah...@un... wrote:
> Hi,
>
>
> As you see in my recent commit, all classes that implement ODE physics
> objects are now in a separated plugin directory.
>
> The plan right now is to rename them from ODE(...) to (...)Imp. So, there
> would be BoxColliderImp, RigidBodyImp, JointImp et.al. in the odeimps
> directory. For other Physics engines, we'd have a bulletimps or physximps
> directory that redifine those classes with their corresponding
> engine-specific code.
> The abstract physics classes will then retrieve an instance of their
> corresponding implementation class from the scenegraph and upcast it to
> (...)Int. By delegating calls to this instance, they will be able to work
> with it without even knowing which engine is currently in use.
>
Well, there is no need to have these classes in the scenegraph. All you
need is to register them with zeitgeist (as you've apparently done with
the AngularMotorImp class), and then you should be able to retrieve new
class instances in ruby or in C++ (e.g. using
GetCore()->New("AngularMotorImp") in C++).
But, as you mentioned before, you've planned to have a PhysicsServer
class implementation for each engine which acts as a factory for other
engine implementation classes. I prefer that approach too! Specially
notice that the above case is still inflexible: consider that we have
both Bullet and ODE classes, which one is going to be registered as
AngularMotorImp?
Another possibility is to register classes with prefixes, e.g.
"ode/AngularMotorImp", which can be done as it is done in kerosin.cpp.
And then, the prefix can be specified for the Oxygen's PhysicsServer
class by a function call in spark.rb script.
The factory class can also be created and specified in spark.rb script.
For an example, you can have a look at the way the OpenGLSystem is sent
to the OpenGLServer class in spark.rb.
AFAIK, what you can expect to see in the scenegraph is the generic
physics classes attached to the agent bodies, the soccer field, etc.
Thanks for your great work,
Hedayat
> All I need to know now is how to make these Imp classes show up in the
> scenegraph. Right now, I tried to do this with AngularMotorImp and did the
> following:
>
> - derived AngularMotorImp from BaseNode
> - put "DECLARE_CLASS(AngularMotorImp)" in odeangularmotor.h
> - created odeangularmotor_c.cpp with CLASS(AngularMotorImp)::DefineClass()
> - created an export.cpp file with ZEITGEIST_EXPORT(AngularMotorImp);
> - put "importbundle(odeimps)" at the bottom of spark.rb
>
> According to rsgedit, AngularMotorImp is still not showing up in the
> SceneGraph, so maybe someone can tell me what I forgot or even give me a
> step-by-step guide on how to put these classes in the SceneGraph (and
> later retrieve objects).
>
>
> thanks,
>
> Andreas
>
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Simspark Generic Physical MAS Simulator
> simspark-devel mailing list
> sim...@li...
> https://lists.sourceforge.net/lists/listinfo/simspark-devel
>
|
|
From: Joschka B. <jos...@am...> - 2010-02-20 06:32:11
|
Hi Hedayat and all,
On Feb 19, 2010, at 11:41 PM, Hedayat Vatankhah wrote:
> Hi Andreas!
>
> On ۱۰/۰۲/۱۹ 09:27, ah...@un... wrote:
>> Hi,
>>
>>
>> As you see in my recent commit, all classes that implement ODE physics
>> objects are now in a separated plugin directory.
>>
>> The plan right now is to rename them from ODE(...) to (...)Imp. So, there
>> would be BoxColliderImp, RigidBodyImp, JointImp et.al. in the odeimps
>> directory. For other Physics engines, we'd have a bulletimps or physximps
>> directory that redifine those classes with their corresponding
>> engine-specific code.
>> The abstract physics classes will then retrieve an instance of their
>> corresponding implementation class from the scenegraph and upcast it to
>> (...)Int. By delegating calls to this instance, they will be able to work
>> with it without even knowing which engine is currently in use.
>>
> Well, there is no need to have these classes in the scenegraph. All you
> need is to register them with zeitgeist (as you've apparently done with
> the AngularMotorImp class), and then you should be able to retrieve new
> class instances in ruby or in C++ (e.g. using
> GetCore()->New("AngularMotorImp") in C++).
IIRC the ClassObjects (i.e. the factories) are installed in the scene graph under /sys/classes (or just /classes ?) when the bundle is imported. In the call you described above, the core would get the ClassObject from there and use it to create an instance of that class.
>
> But, as you mentioned before, you've planned to have a PhysicsServer
> class implementation for each engine which acts as a factory for other
> engine implementation classes. I prefer that approach too! Specially
> notice that the above case is still inflexible: consider that we have
> both Bullet and ODE classes, which one is going to be registered as
> AngularMotorImp?
>
I guess it depends on whether we will need to have Bullet and ODE classes (and maybe others in the future) registered at the same time. I actually don't think we do, since I can't imagine a case where we would need to switch between engines during run-time, but if anyone has a good example of why we should implement that, we can discuss it.
If we don't need different engine-specific sets of classes loaded at the same time, we will not need separate PhysicsServers for each engine, and the approach described by Andreas above should work fine. I argued against having a separate factory because it kind of duplicates work that Zeitgeist gives us for free anyways.
> Another possibility is to register classes with prefixes, e.g.
> "ode/AngularMotorImp", which can be done as it is done in kerosin.cpp.
> And then, the prefix can be specified for the Oxygen's PhysicsServer
> class by a function call in spark.rb script.
>
Yes, we've been thinking about sth like that also.
> The factory class can also be created and specified in spark.rb script.
> For an example, you can have a look at the way the OpenGLSystem is sent
> to the OpenGLServer class in spark.rb.
>
You're right, I also think that we should handle the engine specific stuff in the ruby scripts. One important difference to the OpenGLSystem or the SoundSystem cases is that the physics system needs to create lots of objects. But if we use a prefix for the path like you suggested above, and specify that prefix in the ruby script, it should even be possible to load several physics engine bundles (although I still don't see the usefulness of that).
> AFAIK, what you can expect to see in the scenegraph is the generic
> physics classes attached to the agent bodies, the soccer field, etc.
>
Right, I think these will be below the /sys/scene part of the tree. But the ClassObjects should be showing up below /sys/classes after the bundle was imported, I think.
>> All I need to know now is how to make these Imp classes show up in the
>> scenegraph. Right now, I tried to do this with AngularMotorImp and did the
>> following:
>>
>> - derived AngularMotorImp from BaseNode
>> - put "DECLARE_CLASS(AngularMotorImp)" in odeangularmotor.h
>> - created odeangularmotor_c.cpp with CLASS(AngularMotorImp)::DefineClass()
>> - created an export.cpp file with ZEITGEIST_EXPORT(AngularMotorImp);
>> - put "importbundle(odeimps)" at the bottom of spark.rb
>>
>> According to rsgedit, AngularMotorImp is still not showing up in the
>> SceneGraph, so maybe someone can tell me what I forgot or even give me a
>> step-by-step guide on how to put these classes in the SceneGraph (and
>> later retrieve objects).
@Andreas: did you have a look below /sys/classes in the scene graph? Are you sure the bundle was imported correctly? If they were not there, maybe a step is missing to get the bundle imported. The steps you described look correct to me though. I'll try to have a look.
Cheers,
Joschka
|
|
From: Hedayat V. <hed...@ai...> - 2010-02-20 08:54:57
|
Hi!
On ۱۰/۰۲/۲۰ 09:40, Joschka Boedecker wrote:
> Hi Hedayat and all,
>
> On Feb 19, 2010, at 11:41 PM, Hedayat Vatankhah wrote:
>
>
>> Hi Andreas!
>>
>> On ۱۰/۰۲/۱۹ 09:27, ah...@un... wrote:
>>
>>> Hi,
>>>
>>>
>>> As you see in my recent commit, all classes that implement ODE physics
>>> objects are now in a separated plugin directory.
>>>
>>> The plan right now is to rename them from ODE(...) to (...)Imp. So, there
>>> would be BoxColliderImp, RigidBodyImp, JointImp et.al. in the odeimps
>>> directory. For other Physics engines, we'd have a bulletimps or physximps
>>> directory that redifine those classes with their corresponding
>>> engine-specific code.
>>> The abstract physics classes will then retrieve an instance of their
>>> corresponding implementation class from the scenegraph and upcast it to
>>> (...)Int. By delegating calls to this instance, they will be able to work
>>> with it without even knowing which engine is currently in use.
>>>
>>>
>> Well, there is no need to have these classes in the scenegraph. All you
>> need is to register them with zeitgeist (as you've apparently done with
>> the AngularMotorImp class), and then you should be able to retrieve new
>> class instances in ruby or in C++ (e.g. using
>> GetCore()->New("AngularMotorImp") in C++).
>>
> IIRC the ClassObjects (i.e. the factories) are installed in the scene graph under /sys/classes (or just /classes ?) when the bundle is imported. In the call you described above, the core would get the ClassObject from there and use it to create an instance of that class.
>
Oops, yes you should be right :P.
>
>> But, as you mentioned before, you've planned to have a PhysicsServer
>> class implementation for each engine which acts as a factory for other
>> engine implementation classes. I prefer that approach too! Specially
>> notice that the above case is still inflexible: consider that we have
>> both Bullet and ODE classes, which one is going to be registered as
>> AngularMotorImp?
>>
>>
> I guess it depends on whether we will need to have Bullet and ODE classes (and maybe others in the future) registered at the same time. I actually don't think we do, since I can't imagine a case where we would need to switch between engines during run-time, but if anyone has a good example of why we should implement that, we can discuss it.
>
> If we don't need different engine-specific sets of classes loaded at the same time, we will not need separate PhysicsServers for each engine, and the approach described by Andreas above should work fine. I argued against having a separate factory because it kind of duplicates work that Zeitgeist gives us for free anyways.
>
Sorry again! It was because of my mistake, I just didn't notice that if
we don't want to use a physics engine, we won't import its bundle at the
first place! :P So, I thought that we WILL register all physics engine
at the same time and I was looking for a solution. Therefore, my
comments were completely misleading! We will certainly import a single
physics implementation bundle each time, so there is no need for a
factory class (I was not comfortable with having another factory when
Zeitgeist is already there too!!), and there is no need for a prefix as
I said before. So the whole email was garbage! :D :P Sorry for that.
> [...]All I need to know now is how to make these Imp classes show up
> in the
>>> scenegraph. Right now, I tried to do this with AngularMotorImp and did the
>>> following:
>>>
>>> - derived AngularMotorImp from BaseNode
>>> - put "DECLARE_CLASS(AngularMotorImp)" in odeangularmotor.h
>>> - created odeangularmotor_c.cpp with CLASS(AngularMotorImp)::DefineClass()
>>> - created an export.cpp file with ZEITGEIST_EXPORT(AngularMotorImp);
>>> - put "importbundle(odeimps)" at the bottom of spark.rb
>>>
>>> According to rsgedit, AngularMotorImp is still not showing up in the
>>> SceneGraph, so maybe someone can tell me what I forgot or even give me a
>>> step-by-step guide on how to put these classes in the SceneGraph (and
>>> later retrieve objects).
>>>
> @Andreas: did you have a look below /sys/classes in the scene graph? Are you sure the bundle was imported correctly? If they were not there, maybe a step is missing to get the bundle imported. The steps you described look correct to me though. I'll try to have a look.
>
The gendot utility in simspark-utilities is another way to look at the
registered classes. Import your odeimps bundle in gendot.rb and look at
the zeitgeist.dot output file. You should be able to see the classes.
Good luck!
Hedayat
> Cheers,
> Joschka=
>
|
|
From: Joschka B. <jos...@am...> - 2010-02-20 11:46:55
|
Hey Hedayat!
On Feb 20, 2010, at 5:53 PM, Hedayat Vatankhah wrote:
> Hi!
>
> On ۱۰/۰۲/۲۰ 09:40, Joschka Boedecker wrote:
>> Hi Hedayat and all,
>>
>> On Feb 19, 2010, at 11:41 PM, Hedayat Vatankhah wrote:
>>
>>
>>> Hi Andreas!
>>>
>>> On ۱۰/۰۲/۱۹ 09:27, ah...@un... wrote:
>>>
>>>> Hi,
>>>>
>>>>
>>>> As you see in my recent commit, all classes that implement ODE physics
>>>> objects are now in a separated plugin directory.
>>>>
>>>> The plan right now is to rename them from ODE(...) to (...)Imp. So, there
>>>> would be BoxColliderImp, RigidBodyImp, JointImp et.al. in the odeimps
>>>> directory. For other Physics engines, we'd have a bulletimps or physximps
>>>> directory that redifine those classes with their corresponding
>>>> engine-specific code.
>>>> The abstract physics classes will then retrieve an instance of their
>>>> corresponding implementation class from the scenegraph and upcast it to
>>>> (...)Int. By delegating calls to this instance, they will be able to work
>>>> with it without even knowing which engine is currently in use.
>>>>
>>>>
>>> Well, there is no need to have these classes in the scenegraph. All you
>>> need is to register them with zeitgeist (as you've apparently done with
>>> the AngularMotorImp class), and then you should be able to retrieve new
>>> class instances in ruby or in C++ (e.g. using
>>> GetCore()->New("AngularMotorImp") in C++).
>>>
>> IIRC the ClassObjects (i.e. the factories) are installed in the scene graph under /sys/classes (or just /classes ?) when the bundle is imported. In the call you described above, the core would get the ClassObject from there and use it to create an instance of that class.
>>
> Oops, yes you should be right :P.
>
:-)
>>
>>> But, as you mentioned before, you've planned to have a PhysicsServer
>>> class implementation for each engine which acts as a factory for other
>>> engine implementation classes. I prefer that approach too! Specially
>>> notice that the above case is still inflexible: consider that we have
>>> both Bullet and ODE classes, which one is going to be registered as
>>> AngularMotorImp?
>>>
>>>
>> I guess it depends on whether we will need to have Bullet and ODE classes (and maybe others in the future) registered at the same time. I actually don't think we do, since I can't imagine a case where we would need to switch between engines during run-time, but if anyone has a good example of why we should implement that, we can discuss it.
>>
>> If we don't need different engine-specific sets of classes loaded at the same time, we will not need separate PhysicsServers for each engine, and the approach described by Andreas above should work fine. I argued against having a separate factory because it kind of duplicates work that Zeitgeist gives us for free anyways.
>>
> Sorry again! It was because of my mistake, I just didn't notice that if we don't want to use a physics engine, we won't import its bundle at the first place! :P So, I thought that we WILL register all physics engine at the same time and I was looking for a solution. Therefore, my comments were completely misleading! We will certainly import a single physics implementation bundle each time, so there is no need for a factory class (I was not comfortable with having another factory when Zeitgeist is already there too!!), and there is no need for a prefix as I said before. So the whole email was garbage! :D :P Sorry for that.
>
No no, as I told you on other occasions, your comments are highly appreciated!! It's always good to think these things through together :-)
>> [...]All I need to know now is how to make these Imp classes show up in the
>>>> scenegraph. Right now, I tried to do this with AngularMotorImp and did the
>>>> following:
>>>>
>>>> - derived AngularMotorImp from BaseNode
>>>> - put "DECLARE_CLASS(AngularMotorImp)" in odeangularmotor.h
>>>> - created odeangularmotor_c.cpp with CLASS(AngularMotorImp)::DefineClass()
>>>> - created an export.cpp file with ZEITGEIST_EXPORT(AngularMotorImp);
>>>> - put "importbundle(odeimps)" at the bottom of spark.rb
>>>>
>>>> According to rsgedit, AngularMotorImp is still not showing up in the
>>>> SceneGraph, so maybe someone can tell me what I forgot or even give me a
>>>> step-by-step guide on how to put these classes in the SceneGraph (and
>>>> later retrieve objects).
>>>>
>> @Andreas: did you have a look below /sys/classes in the scene graph? Are you sure the bundle was imported correctly? If they were not there, maybe a step is missing to get the bundle imported. The steps you described look correct to me though. I'll try to have a look.
>>
> The gendot utility in simspark-utilities is another way to look at the registered classes. Import your odeimps bundle in gendot.rb and look at the zeitgeist.dot output file. You should be able to see the classes.
Great, I didn't know about that.
Thanks,
Joschka
|
|
From: Hedayat V. <hed...@ai...> - 2010-02-20 13:05:39
|
Hi again,
Thanks! :)
Good luck,
Hedayat
On ۱۰/۰۲/۲۰ 03:16, Joschka Boedecker wrote:
> Hey Hedayat!
>
> On Feb 20, 2010, at 5:53 PM, Hedayat Vatankhah wrote:
>
>
>> Hi!
>>
>> On ۱۰/۰۲/۲۰ 09:40, Joschka Boedecker wrote:
>>
>>> Hi Hedayat and all,
>>>
>>> On Feb 19, 2010, at 11:41 PM, Hedayat Vatankhah wrote:
>>>
>>>
>>>
>>>> Hi Andreas!
>>>>
>>>> On ۱۰/۰۲/۱۹ 09:27, ah...@un... wrote:
>>>>
>>>>
>>>>> Hi,
>>>>>
>>>>>
>>>>> As you see in my recent commit, all classes that implement ODE physics
>>>>> objects are now in a separated plugin directory.
>>>>>
>>>>> The plan right now is to rename them from ODE(...) to (...)Imp. So, there
>>>>> would be BoxColliderImp, RigidBodyImp, JointImp et.al. in the odeimps
>>>>> directory. For other Physics engines, we'd have a bulletimps or physximps
>>>>> directory that redifine those classes with their corresponding
>>>>> engine-specific code.
>>>>> The abstract physics classes will then retrieve an instance of their
>>>>> corresponding implementation class from the scenegraph and upcast it to
>>>>> (...)Int. By delegating calls to this instance, they will be able to work
>>>>> with it without even knowing which engine is currently in use.
>>>>>
>>>>>
>>>>>
>>>> Well, there is no need to have these classes in the scenegraph. All you
>>>> need is to register them with zeitgeist (as you've apparently done with
>>>> the AngularMotorImp class), and then you should be able to retrieve new
>>>> class instances in ruby or in C++ (e.g. using
>>>> GetCore()->New("AngularMotorImp") in C++).
>>>>
>>>>
>>> IIRC the ClassObjects (i.e. the factories) are installed in the scene graph under /sys/classes (or just /classes ?) when the bundle is imported. In the call you described above, the core would get the ClassObject from there and use it to create an instance of that class.
>>>
>>>
>> Oops, yes you should be right :P.
>>
>>
> :-)
>
>
>>>
>>>
>>>> But, as you mentioned before, you've planned to have a PhysicsServer
>>>> class implementation for each engine which acts as a factory for other
>>>> engine implementation classes. I prefer that approach too! Specially
>>>> notice that the above case is still inflexible: consider that we have
>>>> both Bullet and ODE classes, which one is going to be registered as
>>>> AngularMotorImp?
>>>>
>>>>
>>>>
>>> I guess it depends on whether we will need to have Bullet and ODE classes (and maybe others in the future) registered at the same time. I actually don't think we do, since I can't imagine a case where we would need to switch between engines during run-time, but if anyone has a good example of why we should implement that, we can discuss it.
>>>
>>> If we don't need different engine-specific sets of classes loaded at the same time, we will not need separate PhysicsServers for each engine, and the approach described by Andreas above should work fine. I argued against having a separate factory because it kind of duplicates work that Zeitgeist gives us for free anyways.
>>>
>>>
>> Sorry again! It was because of my mistake, I just didn't notice that if we don't want to use a physics engine, we won't import its bundle at the first place! :P So, I thought that we WILL register all physics engine at the same time and I was looking for a solution. Therefore, my comments were completely misleading! We will certainly import a single physics implementation bundle each time, so there is no need for a factory class (I was not comfortable with having another factory when Zeitgeist is already there too!!), and there is no need for a prefix as I said before. So the whole email was garbage! :D :P Sorry for that.
>>
>>
> No no, as I told you on other occasions, your comments are highly appreciated!! It's always good to think these things through together :-)
>
>
>>> [...]All I need to know now is how to make these Imp classes show up in the
>>>
>>>>> scenegraph. Right now, I tried to do this with AngularMotorImp and did the
>>>>> following:
>>>>>
>>>>> - derived AngularMotorImp from BaseNode
>>>>> - put "DECLARE_CLASS(AngularMotorImp)" in odeangularmotor.h
>>>>> - created odeangularmotor_c.cpp with CLASS(AngularMotorImp)::DefineClass()
>>>>> - created an export.cpp file with ZEITGEIST_EXPORT(AngularMotorImp);
>>>>> - put "importbundle(odeimps)" at the bottom of spark.rb
>>>>>
>>>>> According to rsgedit, AngularMotorImp is still not showing up in the
>>>>> SceneGraph, so maybe someone can tell me what I forgot or even give me a
>>>>> step-by-step guide on how to put these classes in the SceneGraph (and
>>>>> later retrieve objects).
>>>>>
>>>>>
>>> @Andreas: did you have a look below /sys/classes in the scene graph? Are you sure the bundle was imported correctly? If they were not there, maybe a step is missing to get the bundle imported. The steps you described look correct to me though. I'll try to have a look.
>>>
>>>
>> The gendot utility in simspark-utilities is another way to look at the registered classes. Import your odeimps bundle in gendot.rb and look at the zeitgeist.dot output file. You should be able to see the classes.
>>
> Great, I didn't know about that.
>
> Thanks,
>
> Joschka=
>
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X