Menu
▾
▴
simspark-devel — Discussion about Spark development
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(11) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
|
Feb
(1) |
Mar
(6) |
Apr
(4) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
(1) |
Dec
|
| 2007 |
Jan
|
Feb
(24) |
Mar
(19) |
Apr
(2) |
May
(45) |
Jun
(80) |
Jul
(1) |
Aug
|
Sep
(3) |
Oct
|
Nov
|
Dec
|
| 2008 |
Jan
(13) |
Feb
(57) |
Mar
(48) |
Apr
(71) |
May
(22) |
Jun
(26) |
Jul
(10) |
Aug
(1) |
Sep
|
Oct
(13) |
Nov
(21) |
Dec
(15) |
| 2009 |
Jan
(33) |
Feb
(36) |
Mar
(30) |
Apr
(8) |
May
(5) |
Jun
(29) |
Jul
(21) |
Aug
(4) |
Sep
(3) |
Oct
(9) |
Nov
(38) |
Dec
(17) |
| 2010 |
Jan
(13) |
Feb
(24) |
Mar
(18) |
Apr
(16) |
May
(13) |
Jun
(25) |
Jul
|
Aug
|
Sep
(4) |
Oct
|
Nov
(18) |
Dec
(2) |
| 2011 |
Jan
(2) |
Feb
(15) |
Mar
(15) |
Apr
(7) |
May
(16) |
Jun
|
Jul
(2) |
Aug
|
Sep
(4) |
Oct
(2) |
Nov
(4) |
Dec
(1) |
| 2012 |
Jan
(6) |
Feb
|
Mar
(9) |
Apr
(5) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
(2) |
| 2013 |
Jan
(4) |
Feb
(5) |
Mar
(2) |
Apr
|
May
(8) |
Jun
(15) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
(4) |
Feb
(1) |
Mar
(1) |
Apr
(5) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(3) |
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
|
From: Huang Y. <air...@gm...> - 2010-03-03 12:50:50
|
Hi, I have installed the latest version of simspark, and try to run it. But when I start it from terminal, I get the error message as follow: (ScriptServer) Running /usr/local/share/simspark//zeitgeist.rb... (ScriptServer) updating cached script variables (ScriptServer) Script ended OK /usr/local/share/simspark//zeitgeist.rb (ScriptServer) Running /usr/local/share/simspark//oxygen.rb... (ScriptServer) updating cached script variables (ScriptServer) Script ended OK /usr/local/share/simspark//oxygen.rb (ScriptServer) Running /home/airekans/.simspark/kerosin.rb... (ScriptServer) updating cached script variables (ScriptServer) Script ended OK /home/airekans/.simspark/kerosin.rb (ScriptServer) Running /usr/local/share/simspark//spark.rb... (spark.rb) setup (spark.rb) using ODE, to change the physics engine go to line 559 in spark.rb simspark: symbol lookup error: /usr/local/lib/simspark/odeimps.so: undefined symbol: dInitODE Does any thing goes wrong?? I installed the ODE-11.1, and it only built with static library. Is it necessary to build the shared library of ODE to make simspark work properly?? -- Best regards, Yaolong Huang(Curtis) Tianjin University, China |
|
From: <ah...@un...> - 2010-02-28 21:51:29
|
Thanks ;-) I was on a bug hunt today with Marian Buchta, who found some issues with a different compiler. Hopefully everything is resolved now. Apparently, there's already someone who is going to start implementing Bullet pretty much immediately. Either way, I'll keep my subscription to the mailing list, so if any questions arise about a certain aspect of my code or how to emulate something with Bullet, I'll still be around and will try to help. I'm sorry that I didn't get to implement Bullet, myself - I have to say it was definitely possible in the given time frame, but especially in the beginning, I really felt that I still have a lot to learn as a programmer. There were other things as well that made it really hard for me to keep working sometimes... On the bright side, I did succeed at outsourcing all the ODE-specific code to a plugin, which I think is really nice, so I wasn't a total failure. xD I would like to thank everyone for your continued support and your patience with me when I sent about a dozen design proposals to the mailing list, accidentally commited stuff to the trunk or sent cynical mails to the mailing list because I got frustrated with some compiler issues ;-) This especially goes to Joschka, who had to put up with the real-life me, and I got some comments from other people in this lab to whom I unintentionally tought some German curse words. :D see ya, Andreas |
|
From: Hedayat V. <hed...@ai...> - 2010-02-28 20:10:43
|
Hi Andreas! Your work on APL is really appreciated. Congratulations for finishing the first stage and merging back to the trunk. :) Good luck, Hedayat |
|
From: Hedayat V. <hed...@ai...> - 2010-02-28 19:39:28
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Hi,<br>
<br>
On ۱۰/۰۲/۲۸ 07:48, Marian Buchta wrote:
<blockquote cite="mid:4b8...@mx..."
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="Generator" content="Microsoft Word 12 (filtered medium)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri","sans-serif";
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;}
@page Section1
{size:612.0pt 792.0pt;
margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.Section1
{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="Section1">
<p class="MsoNormal"><span lang="EN-US">Hi all.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">From now projects Simspark
and Rcssserver3D
are compatible with Visual Studio 2010 (actually beta 2). Also I
updated
Simspark Wiki [1].</span></p>
</div>
</blockquote>
Thanks a lot for your efforts.<br>
<br>
Good luck,<br>
Hedayat<br>
<br>
<blockquote cite="mid:4b8...@mx..."
type="cite">
<div class="Section1">
<p class="MsoNormal"><span lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Best Regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Marian Buchta<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">[1]</span><span lang="EN-US">
</span><span lang="EN-US"><a moz-do-not-send="true"
href="http://simspark.sourceforge.net/wiki/index.php/Installation_on_Windows">http://simspark.sourceforge.net/wiki/index.php/Installation_on_Windows</a>
<o:p></o:p></span></p>
</div>
<br>
<br>
__________ Information from ESET NOD32 Antivirus, version of virus
signature database 4902 (20100228) __________<br>
<br>
The message was checked by ESET NOD32 Antivirus.<br>
<br>
<a moz-do-not-send="true" href="http://www.eset.com">http://www.eset.com</a><br>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
------------------------------------------------------------------------------
Download Intel&#174; 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.
<a class="moz-txt-link-freetext" href="http://p.sf.net/sfu/intel-sw-dev">http://p.sf.net/sfu/intel-sw-dev</a>
</pre>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
Simspark Generic Physical MAS Simulator
simspark-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:sim...@li...">sim...@li...</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/simspark-devel">https://lists.sourceforge.net/lists/listinfo/simspark-devel</a>
</pre>
</blockquote>
</body>
</html>
|
|
From: Marian B. <mar...@gm...> - 2010-02-28 16:18:40
|
Hi all. >From now projects Simspark and Rcssserver3D are compatible with Visual Studio 2010 (actually beta 2). Also I updated Simspark Wiki [1]. Best Regards, Marian Buchta [1] http://simspark.sourceforge.net/wiki/index.php/Installation_on_Windows |
|
From: Sander v. D. <sgv...@gm...> - 2010-02-26 13:14:59
|
Hey, I had a similar issue just now when doing an update: svn: PROPFIND of '/svnroot/simspark/!svn/vcc/default': Could not read status line: Secure connection truncated (https://simspark.svn.sourceforge.net) Retrying continues the update from where it stopped. Seems like a connection problem on the side of SF. Sander On Wed, Feb 24, 2010 at 8:10 PM, Hedayat Vatankhah <hed...@ai...>wrote: > Hi, > > > > On ۱۰/۰۲/۲۴ 10:31, ah...@un... wrote: > > Hi, > > > I just tried to merge the changes to the trunk into the branch, which > Joschka recommended as it makes merging the branch back into the trunk > easier. Here's SVN's output: > > andreas@andreas-desktop:~/simspark/branches/multiphys$ svn merge --dry-run > -r 102:171 https://simspark.svn.sourceforge.net/svnroot/simspark/trunk > svn: REPORT of '/svnroot/simspark/!svn/vcc/default': Could not read chunk > size: Secure connection truncated (https://simspark.svn.sourceforge.net) > > Googling this doesn't really help, but the dry-run worked on Joschka's > Mac, interestingly enough. Tomorrow, I'll bring my laptop to see if it > works on that machine, though chances are slim because it uses the same > Linux distribution and this is apparently a bug in SVN. > > > I'm using subversion 1.6.9 and I can run the command too. The error seems > to be something network related, but if it is a SVN bug you might consider > updating your subversion client. > > > Joschka had 26 conflicts, by the way, some of them in files that don't > exist. So there's some "fun" left for me as I have to find a way to modify > those nonexistant files ;-) > > > Good luck! ;) > > Thanks, > Hedayat > > > This is just an update, but any comments would be nice. > > > 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 lis...@li...https://lists.sourceforge.net/lists/listinfo/simspark-devel > > > > ------------------------------------------------------------------------------ > 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 > > -- Adaptive Systems Research Group Department of Computer Science University of Hertfordshire United Kingdom |
|
From: <ah...@un...> - 2010-02-24 07:01:31
|
Hi, I just tried to merge the changes to the trunk into the branch, which Joschka recommended as it makes merging the branch back into the trunk easier. Here's SVN's output: andreas@andreas-desktop:~/simspark/branches/multiphys$ svn merge --dry-run -r 102:171 https://simspark.svn.sourceforge.net/svnroot/simspark/trunk svn: REPORT of '/svnroot/simspark/!svn/vcc/default': Could not read chunk size: Secure connection truncated (https://simspark.svn.sourceforge.net) Googling this doesn't really help, but the dry-run worked on Joschka's Mac, interestingly enough. Tomorrow, I'll bring my laptop to see if it works on that machine, though chances are slim because it uses the same Linux distribution and this is apparently a bug in SVN. Joschka had 26 conflicts, by the way, some of them in files that don't exist. So there's some "fun" left for me as I have to find a way to modify those nonexistant files ;-) This is just an update, but any comments would be nice. Andreas |
|
From: Hedayat V. <hed...@ai...> - 2010-02-22 08:33:05
|
Hey Joschka,
Thanks for your continued support and encouragement ;)
Good luck,
Hedayat
On ۱۰/۰۲/۲۲ 11:33, Joschka Boedecker wrote:
> Hey Hedayat,
>
> On Feb 22, 2010, at 4:39 PM, Hedayat Vatankhah wrote:
>
>
>> Hi Andreas!
>>
>> On ۱۰/۰۲/۲۲ 10:49, ah...@un... wrote:
>>
>>> Hi,
>>>
>>>
>>> I am now one step closer to having the ODE classes as a plugin. I use the
>>> PhysicsServer for testing for now, because this is a class that is
>>> actually used, as opposed to the AngularMotor, and thus obviously more
>>> suited for testing. PhysicsServerImp now shows up in the scenegraph; the
>>> key was to build odeimps not as a library, but as a module (which is the
>>> desired method anyway, as building it as a library was merely a
>>> workaround).
>>>
>>> I changed spark.rb a bit so that it imports the odeimps bundle at the very
>>> beginning. The relevant part now looks like this:
>>>
>>> ----- begin excerpt from spark.rb -----
>>> #
>>> # setup spark
>>> #
>>>
>>> print "(spark.rb) setup\n"
>>>
>>> #import the implementations of the desired physics engine
>>> #currently supported: odeimps (uses Open Dynamics Engine)
>>> importBundle "odeimps"
>>> print "(spark.rb) using ODE, to change the physics engine go to line 559
>>> in spark.rb\n"
>>>
>>> #
>>> # set up logging
>>> logServer = get($serverPath+'log')
>>>
>>> if (logServer != nil)
>>> logServer.addStream(':cerr', 'eError')
>>> end
>>>
>>>
>>> #
>>> # setup the PhysicsServer
>>> sparkGetPhysicsServer()
>>> ----- end excerpt from spark.rb -----
>>>
>>> Here's a screenshot of rsgedit which proves that the odeimps bundle gets
>>> imported correctly, and also showcases that the PhysicsServerImp shows up
>>> at "/classes/PhysicsServerImp":
>>>
>>> http://www.uni-koblenz.de/~aheld/rsgeditscreen.png
>>>
>>> Since I can now be 100% sure that PhysicsServerImp is now registered at
>>> /classes/PhysicsServerImp _before_ the PhysicsServer is set up [as
>>> importbundle"odeimps" is called prior to sparkGetPhysicsServer()], I can
>>> now instanciate mPhysicsServerImp in the PhysicsServer's OnLink method
>>> like this:
>>>
>>> void PhysicsServer::OnLink(){
>>> mPhysicsServerImp = shared_dynamic_cast<PhysicsServerInt>
>>> (GetCore()->New("/classes/PhysicsServerImp"));
>>> }
>>>
>>> This leads to the following console output:
>>>
>>> ----- begin inexplicable console output ----
>>> (ScriptServer) Script ended OK /home/andreas/.simspark/kerosin.rb
>>> (ScriptServer) Running /usr/local/share/simspark//spark.rb...
>>> (spark.rb) setup
>>> (spark.rb) using ODE, to change the physics engine go to line 558 in spark.rb
>>> (Core::New) unkown class '/classes/PhysicsServerImp'
>>> (GeometryServer) MeshImporter 'oxygen/StdMeshImporter' registered
>>> ----- end inexplicable console output -----
>>>
>>> As even a trained monkey could see, the odeimps bundle is imported, and
>>> thus PhysicsServerImp registered at /classes/PhysicsServerImp immediately
>>> before Zeitgeist complains that PhysicsServerImp is not registered at
>>> /classes/PhysicsServerImp. The RSGEdit screenshot proves that
>>> PhysicsServerImp is registered at /classes/PhysicsServerImp.
>>>
>>> Soemhow the PhysicsServer is set up before PhysicsServerImp is registered
>>> even though spark.rb registers PhysicsServerImp before the PhysicsServer
>>> is set up. This is a time paradoxon. Maybe I'm using a quantum computer
>>> without knowing it?
>>>
>>> Any ideas would be appreciated.
>>>
>>>
>> IMHO, you should simply use
>>
>> GetCore()->New("PhysicsServerImp")
>>
>> Instead of
>>
>> GetCore()->New("/classes/PhysicsServerImp")
>>
>> And it should work fine!
>>
> That's it, thanks a bunch! :-)
>
> Cheers,
> Joschka=
>
|
|
From: Joschka B. <jos...@am...> - 2010-02-22 08:04:05
|
Hey Hedayat,
On Feb 22, 2010, at 4:39 PM, Hedayat Vatankhah wrote:
> Hi Andreas!
>
> On ۱۰/۰۲/۲۲ 10:49, ah...@un... wrote:
>> Hi,
>>
>>
>> I am now one step closer to having the ODE classes as a plugin. I use the
>> PhysicsServer for testing for now, because this is a class that is
>> actually used, as opposed to the AngularMotor, and thus obviously more
>> suited for testing. PhysicsServerImp now shows up in the scenegraph; the
>> key was to build odeimps not as a library, but as a module (which is the
>> desired method anyway, as building it as a library was merely a
>> workaround).
>>
>> I changed spark.rb a bit so that it imports the odeimps bundle at the very
>> beginning. The relevant part now looks like this:
>>
>> ----- begin excerpt from spark.rb -----
>> #
>> # setup spark
>> #
>>
>> print "(spark.rb) setup\n"
>>
>> #import the implementations of the desired physics engine
>> #currently supported: odeimps (uses Open Dynamics Engine)
>> importBundle "odeimps"
>> print "(spark.rb) using ODE, to change the physics engine go to line 559
>> in spark.rb\n"
>>
>> #
>> # set up logging
>> logServer = get($serverPath+'log')
>>
>> if (logServer != nil)
>> logServer.addStream(':cerr', 'eError')
>> end
>>
>>
>> #
>> # setup the PhysicsServer
>> sparkGetPhysicsServer()
>> ----- end excerpt from spark.rb -----
>>
>> Here's a screenshot of rsgedit which proves that the odeimps bundle gets
>> imported correctly, and also showcases that the PhysicsServerImp shows up
>> at "/classes/PhysicsServerImp":
>>
>> http://www.uni-koblenz.de/~aheld/rsgeditscreen.png
>>
>> Since I can now be 100% sure that PhysicsServerImp is now registered at
>> /classes/PhysicsServerImp _before_ the PhysicsServer is set up [as
>> importbundle"odeimps" is called prior to sparkGetPhysicsServer()], I can
>> now instanciate mPhysicsServerImp in the PhysicsServer's OnLink method
>> like this:
>>
>> void PhysicsServer::OnLink(){
>> mPhysicsServerImp = shared_dynamic_cast<PhysicsServerInt>
>> (GetCore()->New("/classes/PhysicsServerImp"));
>> }
>>
>> This leads to the following console output:
>>
>> ----- begin inexplicable console output ----
>> (ScriptServer) Script ended OK /home/andreas/.simspark/kerosin.rb
>> (ScriptServer) Running /usr/local/share/simspark//spark.rb...
>> (spark.rb) setup
>> (spark.rb) using ODE, to change the physics engine go to line 558 in spark.rb
>> (Core::New) unkown class '/classes/PhysicsServerImp'
>> (GeometryServer) MeshImporter 'oxygen/StdMeshImporter' registered
>> ----- end inexplicable console output -----
>>
>> As even a trained monkey could see, the odeimps bundle is imported, and
>> thus PhysicsServerImp registered at /classes/PhysicsServerImp immediately
>> before Zeitgeist complains that PhysicsServerImp is not registered at
>> /classes/PhysicsServerImp. The RSGEdit screenshot proves that
>> PhysicsServerImp is registered at /classes/PhysicsServerImp.
>>
>> Soemhow the PhysicsServer is set up before PhysicsServerImp is registered
>> even though spark.rb registers PhysicsServerImp before the PhysicsServer
>> is set up. This is a time paradoxon. Maybe I'm using a quantum computer
>> without knowing it?
>>
>> Any ideas would be appreciated.
>>
> IMHO, you should simply use
>
> GetCore()->New("PhysicsServerImp")
>
> Instead of
>
> GetCore()->New("/classes/PhysicsServerImp")
>
> And it should work fine!
That's it, thanks a bunch! :-)
Cheers,
Joschka
|
|
From: Hedayat V. <hed...@ai...> - 2010-02-22 07:41:00
|
Hi Andreas!
On ۱۰/۰۲/۲۲ 10:49, ah...@un... wrote:
> Hi,
>
>
> I am now one step closer to having the ODE classes as a plugin. I use the
> PhysicsServer for testing for now, because this is a class that is
> actually used, as opposed to the AngularMotor, and thus obviously more
> suited for testing. PhysicsServerImp now shows up in the scenegraph; the
> key was to build odeimps not as a library, but as a module (which is the
> desired method anyway, as building it as a library was merely a
> workaround).
>
> I changed spark.rb a bit so that it imports the odeimps bundle at the very
> beginning. The relevant part now looks like this:
>
> ----- begin excerpt from spark.rb -----
> #
> # setup spark
> #
>
> print "(spark.rb) setup\n"
>
> #import the implementations of the desired physics engine
> #currently supported: odeimps (uses Open Dynamics Engine)
> importBundle "odeimps"
> print "(spark.rb) using ODE, to change the physics engine go to line 559
> in spark.rb\n"
>
> #
> # set up logging
> logServer = get($serverPath+'log')
>
> if (logServer != nil)
> logServer.addStream(':cerr', 'eError')
> end
>
>
> #
> # setup the PhysicsServer
> sparkGetPhysicsServer()
> ----- end excerpt from spark.rb -----
>
> Here's a screenshot of rsgedit which proves that the odeimps bundle gets
> imported correctly, and also showcases that the PhysicsServerImp shows up
> at "/classes/PhysicsServerImp":
>
> http://www.uni-koblenz.de/~aheld/rsgeditscreen.png
>
> Since I can now be 100% sure that PhysicsServerImp is now registered at
> /classes/PhysicsServerImp _before_ the PhysicsServer is set up [as
> importbundle"odeimps" is called prior to sparkGetPhysicsServer()], I can
> now instanciate mPhysicsServerImp in the PhysicsServer's OnLink method
> like this:
>
> void PhysicsServer::OnLink(){
> mPhysicsServerImp = shared_dynamic_cast<PhysicsServerInt>
> (GetCore()->New("/classes/PhysicsServerImp"));
> }
>
> This leads to the following console output:
>
> ----- begin inexplicable console output ----
> (ScriptServer) Script ended OK /home/andreas/.simspark/kerosin.rb
> (ScriptServer) Running /usr/local/share/simspark//spark.rb...
> (spark.rb) setup
> (spark.rb) using ODE, to change the physics engine go to line 558 in spark.rb
> (Core::New) unkown class '/classes/PhysicsServerImp'
> (GeometryServer) MeshImporter 'oxygen/StdMeshImporter' registered
> ----- end inexplicable console output -----
>
> As even a trained monkey could see, the odeimps bundle is imported, and
> thus PhysicsServerImp registered at /classes/PhysicsServerImp immediately
> before Zeitgeist complains that PhysicsServerImp is not registered at
> /classes/PhysicsServerImp. The RSGEdit screenshot proves that
> PhysicsServerImp is registered at /classes/PhysicsServerImp.
>
> Soemhow the PhysicsServer is set up before PhysicsServerImp is registered
> even though spark.rb registers PhysicsServerImp before the PhysicsServer
> is set up. This is a time paradoxon. Maybe I'm using a quantum computer
> without knowing it?
>
> Any ideas would be appreciated.
>
IMHO, you should simply use
GetCore()->New("PhysicsServerImp")
Instead of
GetCore()->New("/classes/PhysicsServerImp")
And it should work fine!
Good luck,
Hedayat
>
> 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: <ah...@un...> - 2010-02-22 07:20:04
|
Hi,
I am now one step closer to having the ODE classes as a plugin. I use the
PhysicsServer for testing for now, because this is a class that is
actually used, as opposed to the AngularMotor, and thus obviously more
suited for testing. PhysicsServerImp now shows up in the scenegraph; the
key was to build odeimps not as a library, but as a module (which is the
desired method anyway, as building it as a library was merely a
workaround).
I changed spark.rb a bit so that it imports the odeimps bundle at the very
beginning. The relevant part now looks like this:
----- begin excerpt from spark.rb -----
#
# setup spark
#
print "(spark.rb) setup\n"
#import the implementations of the desired physics engine
#currently supported: odeimps (uses Open Dynamics Engine)
importBundle "odeimps"
print "(spark.rb) using ODE, to change the physics engine go to line 559
in spark.rb\n"
#
# set up logging
logServer = get($serverPath+'log')
if (logServer != nil)
logServer.addStream(':cerr', 'eError')
end
#
# setup the PhysicsServer
sparkGetPhysicsServer()
----- end excerpt from spark.rb -----
Here's a screenshot of rsgedit which proves that the odeimps bundle gets
imported correctly, and also showcases that the PhysicsServerImp shows up
at "/classes/PhysicsServerImp":
http://www.uni-koblenz.de/~aheld/rsgeditscreen.png
Since I can now be 100% sure that PhysicsServerImp is now registered at
/classes/PhysicsServerImp _before_ the PhysicsServer is set up [as
importbundle"odeimps" is called prior to sparkGetPhysicsServer()], I can
now instanciate mPhysicsServerImp in the PhysicsServer's OnLink method
like this:
void PhysicsServer::OnLink(){
mPhysicsServerImp = shared_dynamic_cast<PhysicsServerInt>
(GetCore()->New("/classes/PhysicsServerImp"));
}
This leads to the following console output:
----- begin inexplicable console output ----
(ScriptServer) Script ended OK /home/andreas/.simspark/kerosin.rb
(ScriptServer) Running /usr/local/share/simspark//spark.rb...
(spark.rb) setup
(spark.rb) using ODE, to change the physics engine go to line 558 in spark.rb
(Core::New) unkown class '/classes/PhysicsServerImp'
(GeometryServer) MeshImporter 'oxygen/StdMeshImporter' registered
----- end inexplicable console output -----
As even a trained monkey could see, the odeimps bundle is imported, and
thus PhysicsServerImp registered at /classes/PhysicsServerImp immediately
before Zeitgeist complains that PhysicsServerImp is not registered at
/classes/PhysicsServerImp. The RSGEdit screenshot proves that
PhysicsServerImp is registered at /classes/PhysicsServerImp.
Soemhow the PhysicsServer is set up before PhysicsServerImp is registered
even though spark.rb registers PhysicsServerImp before the PhysicsServer
is set up. This is a time paradoxon. Maybe I'm using a quantum computer
without knowing it?
Any ideas would be appreciated.
thanks,
Andreas
|
|
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=
>
|
|
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 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 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-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: <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: <Oli...@cs...> - 2010-02-08 21:16:50
|
On 09/02/2010, at 1:16 AM, Simon Raffeiner wrote: > Apparently the downloads can be activated again, restoring the old behaviour. Could one of the project admins check that? > > I still think the whole situation is unacceptable, but if we're back to the old status this should give us the time to come up with a permanent solution after Singapore. assuming now it can be changed so that it works for everyone I think SF provides a more than acceptable service. cheers Oliver -- Oliver Obst form follows function (Louis Sullivan). Adaptive Systems Team CSIRO ICT Centre http://research.ict.csiro.au/ +61 2 9372 4710 http://oliver.obst.eu/ |
|
From: Simon R. <sra...@st...> - 2010-02-08 14:16:26
|
SourceForge maybe just announced a partial solution: http://sourceforge.net/blog/some-good-news-SourceForge-removes-blanket-blocking/ Apparently the downloads can be activated again, restoring the old behaviour. Could one of the project admins check that? I still think the whole situation is unacceptable, but if we're back to the old status this should give us the time to come up with a permanent solution after Singapore. regards Simon Raffeiner -- mit freundlichen Grüßen/regards Simon Raffeiner University of Applied Sciences Offenburg, Germany Department of Computer Science, RoboCup Team |
|
From: <Oli...@cs...> - 2010-02-08 14:09:21
|
Hi all, On 08/02/2010, at 8:07 PM, Hedayat Vatankhah wrote: > As you might know, SourceForge has recently blocked access to its > contents (downloading released files) to Iranian users (and users of > other countries under sanctions by USA). And Iranians should use > workarounds to access these files. apologies for my ignorance, I must admit I wasn't really aware of this issue. I agree this is an issue (but as I read they are workarounds for the time being). I have checked the explanation on sourceforge, and unless there is other evidence I tend to believe SF was required to follow this step because of how lawyers would possibly interpret US law. Joschka and I have OK experience using Origo (http://www.origo.ethz.ch/), a service similar to SF based at the ETH at Zurich. The service is simpler than the one at SF, but I believe it would provide everything required. Also, SVN is the only system in place (i.e. no git or cvs). I we consider a move, I would anyway propose to not shift from SVN to something else at the same time if possible. Also I would be happy if the project name stayed as either spark or simspark if possible. SF provided good and reliable service over the past years, so it would be nice trying to find out what we can expect over the next months before moving over to somewhere else (in the past, US laws also prohibited exporting strong encryption but this was relaxed eventually). I have sent the guys at SF an email to double check what their feeling about this issue is (even though I don't expect much to come out of it). I'll post the answer here if I get one. Finally, there would also be some work / friction involved in actually moving everything, so I would propose to do this long enough before, or right after RC2010. cheers Oliver |
|
From: Simon R. <sra...@st...> - 2010-02-08 10:52:51
|
Am Montag 08 Februar 2010 10:07:01 am schrieb Hedayat Vatankhah: > But considering the large number of Iranians participating in RoboCup, > the recent act of sf.net to block Iranians is really irritating; and is > IMHO (notice that I'm Iranian ;) ) unacceptable specially that it is not > a US product! Salam Hedayat, sadly it's not just SourceForge, but also Google Code and Fedora Hosted. After the alleged Google attacks and recent "predictions" about cyber attacks by the USA authorities I expect the list of blocked countries to grow, maybe they'll even add China or Russia. We had a lot of controversy about it here in Germany, and I have some very strong opinions about the whole thing, but since this is not the place for political ranting I'll just express my full support for the move to a different hosting service. > So, I would like to know your opinions about moving > simspark/rcssserver3d to a different project hosting service (e.g. > BerliOS, SourceForge.jp) which doesn't impose such restrictions (and > preferably is not a USA based service provider). BerliOS had multiple security breaches in recent years (http://cyberinsecure.com/berlios-open-source-project-portal-hacked-and-defaced/), and their management team doesn't really seem to care. > As a side note, IF we decided to move to a new project hosting service > provider, we could also consider moving from using Subversion to Git, > which seems to be better than Subversion in many ways. Many open-source projects already completed the move to CMake and git, so I don't see a problem. Most users will probably just have to replace "svn checkout" with "git clone". There even is a shiny TortoiseGit GUI for Windows users. > But I'm not a > hard proponent of this move, specially that it'll need contributors to > get used to a new system. Even without moving to git, it is possible to > use git-svn by those who prefer it. We might even consider other > versioning systems. The only viable one that comes to mind would be Bazar, but I don't think there are many hosting providers around supporting it (besides Launchpad, which is again hosted in the USA). -- mit freundlichen Grüßen/regards Simon Raffeiner University of Applied Sciences Offenburg, Germany Department of Computer Science, RoboCup Team |
|
From: Hedayat V. <hed...@ai...> - 2010-02-08 09:08:05
|
Hi all, As you might know, SourceForge has recently blocked access to its contents (downloading released files) to Iranian users (and users of other countries under sanctions by USA). And Iranians should use workarounds to access these files. For a long time, SourceForge has been blocking such users from logging in into sf.net servers and being able to contribute, and as a result we were forced to use workarounds to be able to contribute to it. This problem created difficulties for Iranian contributors (including myself), but since it didn't affect users, I could live with it. But considering the large number of Iranians participating in RoboCup, the recent act of sf.net to block Iranians is really irritating; and is IMHO (notice that I'm Iranian ;) ) unacceptable specially that it is not a US product! So, I would like to know your opinions about moving simspark/rcssserver3d to a different project hosting service (e.g. BerliOS, SourceForge.jp) which doesn't impose such restrictions (and preferably is not a USA based service provider). As a side note, IF we decided to move to a new project hosting service provider, we could also consider moving from using Subversion to Git, which seems to be better than Subversion in many ways. But I'm not a hard proponent of this move, specially that it'll need contributors to get used to a new system. Even without moving to git, it is possible to use git-svn by those who prefer it. We might even consider other versioning systems. Anyway, this is not a priority at all! So if you are unsure, we could remain with SVN happily! Thanks Anyway, Hedayat |
|
From: Hedayat V. <hed...@ai...> - 2010-02-02 11:35:39
|
Hi Andreas, On ۱۰/۰۲/۰۲ 02:46, ah...@un... wrote: > Hi, > > > Just a few things... > > 1) Joschka and I have reflected on the design and decided that we want to > employ the physicsserver and use it as the (exclusive) interface between > the physics classes and the rest of simspark. Right now, the RSGImporter > creates physics objects by itself and adds them to the scene graph, and we > want to move this functionality to the physicsserver. The physicsserver > will also be in charge of creating implementation objects, so the > ImpFactory will be completely removed over the course of this. > That's very nice! > 2) Thanks to Hedayat's input, I was able to get rid of the > staticphysicsmethods class completely. :-) I'm actually very happy about > this, since this was the workaround I felt the most uncomfortable about. > :) > 3) It turned out that deriving engine-specific classes from the > engine-unspecific version of their superclass does not help me fix the > Joint problem. I'm now contemplating undoing this change - it doesn't harm > the functionality or the performance, but it "feels" weird and it causes > engine-specific classes to be derivied from BaseNode, which is something > we said we wanted to avoin in the beginning. > :P Yes I figured it out myself last night that I was thinking a little more about it. Sorry! I have another solution in mind but I prefer to say it after a little more thinking and checking with the code to make sure that I don't do a similar mistake again. :( > --- > And now for two completely new things: > --- > > 4) Right now, all header files in the /int and /ode directories are > completely undocumented. Doing this would be redundant, as the methods > that the calls are delegated to usually have the same name and the same > functionality as the documented method which calls them. I.e. I would just > be copy-pasting most comments. I assume I'll have to do this anyway, > though, because it's good sport, right? ;-) > :) About the classes in the int/ directory, yes I think it is needed as they are interfaces which should be implemented for each engine and the one who is implementing them should have a reference in a reasonable place. And these interface classes might have functions which differ a little from the abstract classes who use them. But about the ode/ classes, I'm neutral at this point! > 5) In the standard text that precedes each source file, I find a line like: > > "$Id: boxcollider.h 155 2010-02-01 05:08:06Z a-held $" > > I observed that SVN updates this line automatically when the file is > changed in a commit. However, no matter what I do, this does not work for > new files. So what do I do with them? > You should add "Id" keyword to "svn:keywords" property of the new files. Thanks, Hedayat > > > thanks, > > Andreas > > > ------------------------------------------------------------------------------ > The Planet: dedicated and managed hosting, cloud storage, colocation > Stay online with enterprise data centers and the best network in the business > Choose flexible plans and management services without long-term contracts > Personal 24x7 support from experience hosting pros just a phone call away. > http://p.sf.net/sfu/theplanet-com > _______________________________________________ > Simspark Generic Physical MAS Simulator > simspark-devel mailing list > sim...@li... > https://lists.sourceforge.net/lists/listinfo/simspark-devel > |
|
From: <ah...@un...> - 2010-02-02 11:16:32
|
Hi, Just a few things... 1) Joschka and I have reflected on the design and decided that we want to employ the physicsserver and use it as the (exclusive) interface between the physics classes and the rest of simspark. Right now, the RSGImporter creates physics objects by itself and adds them to the scene graph, and we want to move this functionality to the physicsserver. The physicsserver will also be in charge of creating implementation objects, so the ImpFactory will be completely removed over the course of this. 2) Thanks to Hedayat's input, I was able to get rid of the staticphysicsmethods class completely. :-) I'm actually very happy about this, since this was the workaround I felt the most uncomfortable about. 3) It turned out that deriving engine-specific classes from the engine-unspecific version of their superclass does not help me fix the Joint problem. I'm now contemplating undoing this change - it doesn't harm the functionality or the performance, but it "feels" weird and it causes engine-specific classes to be derivied from BaseNode, which is something we said we wanted to avoin in the beginning. --- And now for two completely new things: --- 4) Right now, all header files in the /int and /ode directories are completely undocumented. Doing this would be redundant, as the methods that the calls are delegated to usually have the same name and the same functionality as the documented method which calls them. I.e. I would just be copy-pasting most comments. I assume I'll have to do this anyway, though, because it's good sport, right? ;-) 5) In the standard text that precedes each source file, I find a line like: "$Id: boxcollider.h 155 2010-02-01 05:08:06Z a-held $" I observed that SVN updates this line automatically when the file is changed in a commit. However, no matter what I do, this does not work for new files. So what do I do with them? thanks, Andreas |
|
From: Hedayat V. <hed...@ai...> - 2010-01-29 11:46:20
|
Hi again, On ۱۰/۰۱/۲۹ 07:44, ah...@un... wrote: > Hi, > > First of all, thanks for the suggestions. > :) You are welcome. > 1) I admit that the paper is currently misleading about these "invisible" > implementation objects. The only problem that was directly caused by this > was that storing variables inside the implementation objects created the > possibility of unwillingly using a different object where that variable is > still zero or a null pointer. This has been completely ruled out by not > storing anything inside the implementations. > > The problem with the Joint classes is caused by a pretty tricky design, > which defines two pure virtual methods, SetParameter and GetParameter. It > implements a load (around 20) other methods that call SetParam and > GetParam with ODE-specific constants. Subclasses of Joint then inherit the > implemented methods and overwrite SetParam and GetParam so it will work. > > However, since the methods that call GetParam and SetParam use > engine-specific constants, I have to implement them in ODEJoint. But I > don't know in ODEJoint whether I will have to call ODEBallJoint::SetParam > or ODEHingeJoint::SetParam etc. Try looking at joint.cpp, hingejoint.cpp > and odejoint.cpp to see what is going on, I admit that this is VERY hard > to explain. > OK, I'll checkout your branch and take a look at the code to better understand what you are talking about. > I thought it was impossible to solve this in any other way than the one I > use currently, but now that I think about it, deriving ODEBallJoint from > Joint instead of ODEJoint (which I think is what you suggested) might > actually solve the problem. I'll have to test if this has any side > effects, but I'll definitely try it out. > Nice. And I'll try to know more about the code till then ;) > 2) That's some great input. Maybe I can get rid of the > StaticPhysicsMethods class completely by declaring the pointers to the > implementation objects as static, which I should do anyway now that I > think about it. Then, I can use these within the static methods and > implement these with the bridge pattern as usual. I'll try this out. > > 3) So, if I understand correctly, you want me to add the ImpFactory into > the scenegraph and then retrieve the parent ImpFactory node of a physics > object instead of using a GetInstance method? > Yes, something like this (as the factory is a single object, it should be probably in an address like "/server/physicsobjectfactory" and referenced by this rather than using relative addressing like getting the factory of the parent node). > Joschka has already said that with the Factory I made this week, it should > be possible to write a ruby script that allows choosing the engine at > runtime. I have too little knowledge of both zeitgeist and ruby to judge > the likeliness of that possibility, though. However, Joschka and I planned > to look at this anyway, so I'll keep this at the back of my head. > :) So you are going with that anyway. That's nice. > And yeah, I isolated the engine-specific code pretty well at this point. > Great! Thanks a lot, Hedayat > > thanks again, > > Andreas > > >> Thanks a lot for all your efforts in developing the APL. >> I have a few comments regarding the paper and also your recent commits. >> 1. (This might be out dated with regard to the recent commits) About the >> Implementation classes: In the paper, you've said that some classes have >> 2 instances of their parent implementation class (e.g. SphereColliderImp >> has two instances of ColliderImp class): one of them through direct >> inheritance and another one inherited from the Collider class. My >> suggestion is to eliminate the inherited one and use the inherited >> Collider instance instead (as it functions as a gateway for the internal >> Implementation class) or get the Implementation object of the Collider >> class if the implementation object itself is needed and the >> functionality is not provided through the Collider class (I might have >> missed some points as I'm not aware of the code very much). >> It seems that you've changed the design and now there is only one object >> of each Imp. class globally. If it is possible (so the Imp. classes >> probably doesn't have any variables), so this is a good solution too. :P >> And their case will be similar to the case of static functions >> (explained below). >> >> 2. The Static Functions: if I've understood correctly, there are a set >> of static methods with engine specific implementation. Instead of having >> a class with different implementations based on the selected physics >> engine, my proposal is to either use a single object of an engine >> specific implementation and call its member functions (the object >> reference can be obtained from either from the Zeitgeist framework or >> having a static GetSingleton() function in the StaticMethods class), or >> by using the bridge pattern for the StaticMethods class too: this class >> could have a static private refrence to an implmentation class which is >> used by the static functions. >> >> 3. In your recent commit, you've introduced a factory class which >> currently contains the instances of Imp. classes. I've two comments >> about it: first, the same pattern have been used throughout the code but >> with a slightly different style: references are stored in the zeitgeist >> hierarchy and accessed using its methods. You might use the same style >> for more consistency (or might not!). >> Second, the instance of the factory class itself is usually obtained >> using Zeitgeist framework too, instead of calling a static method like >> TheFactory::GetInstance(). Beside from consistency point of view, this >> style provides the flexibility to create the desired object in .rb >> scripts (the actual engine is selected there). (Notice that I've NOT >> checked to see where you create the actual factory instance, so your >> solution might be as flexible as this one!). >> Also you could use this factory to create any engine specific objects >> and not only storing single instances (but apparently you do not have >> any such engine specific classes and all of them are single instance >> classes?!). >> >> Finally, I feel that you are reaching a point where you can completely >> detach the ODE specific code into a separate plugin rather than being in >> the Oxygen library itself. This would be nice! :) >> >> Thanks a lot, >> Hedayat >> >> >> >> >>> thanks, >>> >>> Andreas > |
45 messages has been excluded from this view by a project administrator.
