simspark-devel — Discussion about Spark development

Re: [simspark-devel] APL Completion

[<ah...@un...>]

Hi,

First of all, thanks for the suggestions.

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.

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.

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?

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.

And yeah, I isolated the engine-specific code pretty well at this point.


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
>>
>>
>> ------------------------------------------------------------------------------
>> Throughout its 18-year history, RSA Conference consistently attracts the
>> world's best and brightest in the field, creating opportunities for
>> Conference
>> attendees to learn about information security's most important issues
>> through
>> interactions with peers, luminaries and emerging and established
>> companies.
>> http://p.sf.net/sfu/rsaconf-dev2dev
>> _______________________________________________
>> Simspark Generic Physical MAS Simulator
>> simspark-devel mailing list
>> sim...@li...
>> https://lists.sourceforge.net/lists/listinfo/simspark-devel
>>
>
>

Re: [simspark-devel] About APL design

[Hedayat V. <hed...@ai...>]

Hi,

On ۱۰/۰۱/۲۸  08:13, Ben wrote:
> Hi,
>
> About Hedayat's point *3*, I think Andreas tries to concentrate the 
> abstract information
> only in class *impfactory* and the particular engine is created at the
> constructor function of ImpFactory. Otherwise the engine-special info 
> will be
> added into every class, such as body, joint which should be avoid.
>
> I believe the current design is the same with OpenGLServer as Hedayat
> mentioned before.
>
> The superficial differences are:
>
> 1. ImpFactory instead of PhysicsSystem
> 2. PhysicsServer is null, not like OpenGLServer (the code is in 
> ImpFactory)
>
> However, essentially they are the same, since both use bridge pattern.
>
> Please point out if I'm wrong. Thanks a lot!
Yes, as I've noted in point 3 the final design somewhat follows the 
pattern used in other areas like the OpenGLServer/OpenGLSystem classes. 
IMHO, the set of abstract classes do what OpenGLServer class does in 
that context (because of the complexity of physics classes compare to 
the OpenGLServer class, this is reasonable). And as you said, ImpFactory 
class has the same role as engine specific PhysicsSystem classes.
I think with some slight changes, the code will be as flexible as those 
classes (e.g. creating the engine specific class in the constructor 
which determines the engine at compile time).

Thanks,
Hedayat



>
> Regards
> Ben
>
>
> ------------------------------------------------------------------------------
> 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
>    

[simspark-devel] About APL design

[Ben <lgp...@16...>]

Hi,

About Hedayat's point *3*, I think Andreas tries to concentrate the abstract
information
only in class *impfactory* and the particular engine is created at the
constructor function of ImpFactory. Otherwise the engine-special info will
be
added into every class, such as body, joint which should be avoid.

I believe the current design is the same with OpenGLServer as Hedayat
mentioned before.

The superficial differences are:

1. ImpFactory instead of PhysicsSystem
2. PhysicsServer is null, not like OpenGLServer (the code is in ImpFactory)

However, essentially they are the same, since both use bridge pattern.

Please point out if I'm wrong. Thanks a lot!

Regards
Ben

Re: [simspark-devel] APL Completion

[Hedayat V. <hed...@ai...>]

Hi Andreas,


On ۱۰/۰۱/۱۵  03:01, ah...@un... wrote:
> Hello,
>
>
> To "celebrate" the completion of the abstract physics layer, I wrote a
> small paper that exmplains all my design choices and detours I had to take
> during the implementation. It will serve as the foundation for the thesis
> I will have to write on this, but is currently not very well-written. I
> would greatly appreciate it if anyone could take some of his time during
> the weekend to read this, and give me any kind of feedback!
>
> http://www.uni-koblenz.de/~aheld/APL_Paper.pdf
>    
Conguratulations! :)
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
>
>
> ------------------------------------------------------------------------------
> Throughout its 18-year history, RSA Conference consistently attracts the
> world's best and brightest in the field, creating opportunities for Conference
> attendees to learn about information security's most important issues through
> interactions with peers, luminaries and emerging and established companies.
> http://p.sf.net/sfu/rsaconf-dev2dev
> _______________________________________________
> Simspark Generic Physical MAS Simulator
> simspark-devel mailing list
> sim...@li...
> https://lists.sourceforge.net/lists/listinfo/simspark-devel
>    

Re: [simspark-devel] simspark-0.2 and Ruby 1.8.5 on CentOS 5.3

[Hedayat V. <hed...@ai...>]

Hi Simon,


/*Simon Raffeiner <sra...@st...>*/ wrote on ‫یکشنبه ۲۴ 
ژانویه ۱۰، ۰۰:۳۱:۵۹‬:
> Hello list,
>
> I have an older CentOS 5.3 machine with Ruby 1.8.5 standing in a data center. simspark-0.2 cannot be compiled on this machine because RSTRING_PTR(x) in lib/zeitgeist/scriptserver/rubywrapper.cpp and RARRAY_LEN(x) in lib/zeitgeist/scriptserver/scriptserver.cpp have to be changed back to RSTRING(x)->ptr and RARRAY(x)->len, like in simspark-0.1.
>    
It is a long time that Ruby 1.8.6 is noted as a requirement, so dropping 
support for older versions is not unexpected. And usually there is no 
reason for maintaining such backward compatibility. But since that 
change is not too much, I'm not against the patch; specially if others 
face such problem :P . Anyway, thanks so much for your interest and 
activity.

Cheers,
Hedayat

> If anybody else is having problems using older Ruby versions too we should probably introduce #ifdefs of the following form
>
> #ifndef RSTRING_PTR
>      # define RSTRING_PTR(s) (RSTRING(s)->ptr)
> #endif
>
> #ifndef RARRAY_LEN
>      # define RARRAY_LEN(s) (RARRAY(s)->ptr)
> #endif
>
> so the new code works for everybody.
>
>    

[simspark-devel] simspark-0.2 and Ruby 1.8.5 on CentOS 5.3

[Simon R. <sra...@st...>]

Hello list,

I have an older CentOS 5.3 machine with Ruby 1.8.5 standing in a data center. simspark-0.2 cannot be compiled on this machine because RSTRING_PTR(x) in lib/zeitgeist/scriptserver/rubywrapper.cpp and RARRAY_LEN(x) in lib/zeitgeist/scriptserver/scriptserver.cpp have to be changed back to RSTRING(x)->ptr and RARRAY(x)->len, like in simspark-0.1.

If anybody else is having problems using older Ruby versions too we should probably introduce #ifdefs of the following form

#ifndef RSTRING_PTR
	# define RSTRING_PTR(s) (RSTRING(s)->ptr)
#endif

#ifndef RARRAY_LEN
	# define RARRAY_LEN(s) (RARRAY(s)->ptr)
#endif

so the new code works for everybody.

-- 

mit freundlichen Grüßen/regards
Simon Raffeiner

University of Applied Sciences Offenburg, Germany
Department of Computer Science, RoboCup Team

Re: [simspark-devel] Can't find fmod

[Hedayat V. <hed...@ai...>]

<!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 text="#000000" bgcolor="#ffffff">
Hi,<br>
<br>
On ۱۰/۰۱/۲۰  05:06, yu liu wrote:
<blockquote   cite="mid:896...@ma..."   type="cite">
  <div>hi,</div>
  <div>�</div>
  <div>I am a fresh man .I want to install simspark in my computer.But
when I install,there is a error.''Can't find fmod".However ,I have
installed fmodex in the /usr/local/include�, /usr/include and
/include.Moreover,I have move the fmod(include 4 header file) in the
path /usr/local/include�and /include.Why the error� still show.Can
somebody give me solution.Thanks.</div>
  <div>�</div>
  <div>�</div>
</blockquote>
FMOD is an optional requirement, and it is not actually used in the
current simulator. So, you can just skip the error message and compile
and install the simulator. Later, we'll take a look at the mentioned
problem.<br>
<br>
Thanks,<br>
Hedayat<br>
<br>
<blockquote   cite="mid:896...@ma..."   type="cite">
  <pre wrap="">
<hr size="4" width="90%">
------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
<a class="moz-txt-link-freetext" href="http://p.sf.net/sfu/rsaconf-dev2dev">http://p.sf.net/sfu/rsaconf-dev2dev</a>
  </pre>
  <pre wrap="">
<hr size="4" width="90%">
_______________________________________________
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>

[simspark-devel] Can't find fmod

[yu l. <lig...@gm...>]

hi,

I am a fresh man .I want to install simspark in my computer.But when I
install,there is a error.''Can't find fmod".However ,I have installed fmodex
in the /usr/local/include , /usr/include and /include.Moreover,I have move
the fmod(include 4 header file) in the path /usr/local/include and
/include.Why the error  still show.Can somebody give me solution.Thanks.

[simspark-devel] APL Completion

[<ah...@un...>]

Hello,


To "celebrate" the completion of the abstract physics layer, I wrote a
small paper that exmplains all my design choices and detours I had to take
during the implementation. It will serve as the foundation for the thesis
I will have to write on this, but is currently not very well-written. I
would greatly appreciate it if anyone could take some of his time during
the weekend to read this, and give me any kind of feedback!

http://www.uni-koblenz.de/~aheld/APL_Paper.pdf

thanks,

Andreas

Re: [simspark-devel] More trouble with changes to trunk

[Hedayat V. <hed...@ai...>]

Hi,

On ۱۰/۰۱/۰۴  08:05, ah...@un... wrote:
> Hi,
>
>
> When trying to compile the trunk (revision 133), I get the following
> linker error:
>
> Scanning dependencies of target coretest
> [ 96%] Building CXX object test/coretest/CMakeFiles/coretest.dir/main.cpp.o
> Linking CXX executable coretest
> ../../lib/oxygen/liboxygen.so.3.2.4: undefined reference to
> `boost::this_thread::sleep(boost::posix_time::ptime const&)'
> collect2: ld returned 1 exit status
> make[2]: *** [test/coretest/coretest] Error 1
> make[1]: *** [test/coretest/CMakeFiles/coretest.dir/all] Error 2
> make: *** [all] Error 2
> andreas@andreas-desktop:~/simspark/trunk/spark/build$
>
> I'm at a complete loss here since the linker (being who he is) doesn't
> even bother telling me where this is coming from. Any ideas on how to fix
> this?
>    
This is used in on of proxyserver classes. Its weird that the code is 
successfully compiled but not linked. The function is defined in boost's 
thread library which should be linked by the linker. Maybe you've 
multiple versions of Boost installed on your system?! To get more 
informative messages, would you please try running:
make VERBOSE=1
to see if we can discover the main cause?

Thanks,
Hedayat

>
> thanks,
>
> Andreas
>
>
>
>    

[simspark-devel] More trouble with changes to trunk

[<ah...@un...>]

Hi,


When trying to compile the trunk (revision 133), I get the following
linker error:

Scanning dependencies of target coretest
[ 96%] Building CXX object test/coretest/CMakeFiles/coretest.dir/main.cpp.o
Linking CXX executable coretest
../../lib/oxygen/liboxygen.so.3.2.4: undefined reference to
`boost::this_thread::sleep(boost::posix_time::ptime const&)'
collect2: ld returned 1 exit status
make[2]: *** [test/coretest/coretest] Error 1
make[1]: *** [test/coretest/CMakeFiles/coretest.dir/all] Error 2
make: *** [all] Error 2
andreas@andreas-desktop:~/simspark/trunk/spark/build$

I'm at a complete loss here since the linker (being who he is) doesn't
even bother telling me where this is coming from. Any ideas on how to fix
this?


thanks,

Andreas

Re: [simspark-devel] Documentation updates request (and another question!)

[Hedayat V. <hed...@ai...>]

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
<span>Hi,<br>
<br>
<style type="text/css">blockquote {color: navy !important; background-color: RGB(245,245,245) !important; padding: 0 15 10 15 !important; margin: 15 0 0 0; border-left: #1010ff 2px solid;}  blockquote blockquote {color: maroon !important; background-color: RGB(235,235,235) !important; border-left-color:maroon !important}  blockquote blockquote blockquote {color: green !important; background-color: RGB(225,225,225) !important; border-left-color:teal !important}  blockquote blockquote blockquote blockquote {color: purple !important; background-color: RGB(215,215,215) !important; border-left-color: purple !important}  blockquote blockquote blockquote blockquote blockquote {color: teal !important; background-color: RGB(205,205,205) !important; border-left-color: green !important}</style><i><b>Sander
van Dijk <a class="moz-txt-link-rfc2396E" href="mailto:sgv...@gm...">&lt;sgv...@gm...&gt;</a></b></i> wrote on ‫پنجشنبه ۳۱
دسامبر ۰۹، ۱۴:۲۹:۵۶‬:</span>
<blockquote   style="border-left: 2px solid rgb(16, 16, 255); color: navy; background-color: rgb(245, 245, 245); padding-left: 15px;"   cite="mid:efd...@ma..."   type="cite">Hey,<br>
  <br>
  <div class="gmail_quote">On Thu, Dec 31, 2009 at 11:20 AM, Hedayat
Vatankhah <span dir="ltr">&lt;<a moz-do-not-send="true"   href="mailto:hed...@ai...">hed...@ai...</a>&gt;</span> wrote:<br>
  <blockquote class="gmail_quote"   style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
    <div style="direction: ltr;" text="#000000" bgcolor="#ffffff">
    <p style="margin-bottom: 0cm; margin-top: 0pt;">Something off topic
which I remembered now: as simspark doesn't run a
monitor by default anymore, we can have a small script which runs both
the server and a monitor (like rcsoccersim in 2D). This could provide a
chance for name correction without destroying name's history and also
compatibility: we can rename "simspark" to "rcssserver3d", and name the
mentioned script as "simspark". So, simspark will run rcssserver3d and
rcssmonitor3d. What's your opinions?<br>
    </p>
    </div>
  </blockquote>
  <div><br>
The script is a good idea, also the renaming of the binaries. But I
think it's also fine to rename the script, maybe to rcs3d or something.
I find it always confuses new users that simspark is supplied by
rcsserver3d instead of by spark.<br>
  </div>
  </div>
</blockquote>
Yes, you are correct. Personally I liked to rename simspark to
rcssserver3d at the time of CVS to SVN transition just like others
(monitorspark and agentspark), but Joschka expressed some concern about
the simspark name used in some papers and also for backward
compatibility (as it was the most used software in our simulator). At
that time, I thought that creating a symbolic link named simspark would
suffice, but decided not to rename simspark as there was not much
interest in it (or at least I thought so). <br>
So, if there aren't any objections (specially from the veterans!), we
could create the script called rcs3d, rcss3d or even maybe
rcsoccersim3d (or any better options?) and create a link named
simspark; to serve both new users and compatibility. <br>
<br>
Good luck,<br>
Hedayat<br>
<br>
<blockquote   style="border-left: 2px solid rgb(16, 16, 255); color: navy; background-color: rgb(245, 245, 245); padding-left: 15px;"   cite="mid:efd...@ma..."   type="cite">
  <div class="gmail_quote">
  <div><br>
Cheers,<br>
Sander<br>
  </div>
  </div>
  <br>
-- <br>
Adaptive Systems Research Group<br>
Department of Computer Science<br>
University of Hertfordshire<br>
United Kingdom<br>
</blockquote>
</body>
</html>

Re: [simspark-devel] Documentation updates request (and another question!)

[Sander v. D. <sgv...@gm...>]

Hey,

On Thu, Dec 31, 2009 at 11:20 AM, Hedayat Vatankhah <hed...@ai...>wrote:

>  Something off topic which I remembered now: as simspark doesn't run a
> monitor by default anymore, we can have a small script which runs both the
> server and a monitor (like rcsoccersim in 2D). This could provide a chance
> for name correction without destroying name's history and also
> compatibility: we can rename "simspark" to "rcssserver3d", and name the
> mentioned script as "simspark". So, simspark will run rcssserver3d and
> rcssmonitor3d. What's your opinions?
>

The script is a good idea, also the renaming of the binaries. But I think
it's also fine to rename the script, maybe to rcs3d or something. I find it
always confuses new users that simspark is supplied by rcsserver3d instead
of by spark.

Cheers,
Sander

-- 
Adaptive Systems Research Group
Department of Computer Science
University of Hertfordshire
United Kingdom

[simspark-devel] Documentation updates request (and another question!)

[Hedayat V. <hed...@ai...>]

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body style="direction: ltr;" text="#000000" bgcolor="#ffffff">
<p style="margin-bottom: 0cm; margin-top: 0pt;">Hi again,<br>
As we are going to have a new release of the simulator soon, it would
be nice if we can have updated documentation about the recent changes.
Most notably, the new accelerometer sensor and the new way of running
simulator (which needs running rcssmonitor3d in addition to simspark). <br>
</p>
<p style="margin-bottom: 0cm; margin-top: 0pt;"><br>
Something off topic which I remembered now: as simspark doesn't run a
monitor by default anymore, we can have a small script which runs both
the server and a monitor (like rcsoccersim in 2D). This could provide a
chance for name correction without destroying name's history and also
compatibility: we can rename "simspark" to "rcssserver3d", and name the
mentioned script as "simspark". So, simspark will run rcssserver3d and
rcssmonitor3d. What's your opinions? <br>
</p>
<p style="margin-bottom: 0cm; margin-top: 0pt;"><br>
Thanks,<br>
Hedayat<br>
</p>
</body>
</html>

[simspark-devel] Real and visual mismatch in dimensions: goal and penalty area

[Hedayat V. <hed...@ai...>]

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html style="direction: ltr;">
<head>

<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body style="direction: ltr;" text="#000000" bgcolor="#ffffff">
Hi all,<br>
<br>
First of all, happy new year to you! :)<br>
<br>
As you might have noticed, I've recently committed some changes
including new field and goal dimensions. Those dimensions (length and
width of the field, the penalty area, and goal dimensions) were
multiplied by 1.5, except the goal height. But I've noticed some
effects which could be problematic:<br>
1. The visible penalty area is NOT controlled with PenaltyWidth and
PenaltyHeight variables right now. But it should not be hard to fix.<br>
<br>
2. While I've not changed the GoalHeight variable, the visible goal
height have been enlarged. The visible goal object is just scaled and
it retains it's original aspect ratio. I think it should be possible to
fix it by modifying the scale sentence in goal.rsg, but I'm not sure if
that is the right thing to do.<br>
<br>
It would be nice if someone can solve these issues. <br>
<br>
Best wishes,<br>
Hedayat<br>
</body>
</html>

Re: [simspark-devel] Field size

[Hedayat V. <hed...@ai...>]

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi again!<br>
According to some discussions between IranOpen and GermanOpen people,
18x12 seems to be a good option. Any comments?<br>
What about the goal size?<br>
Yes, I think the goal area should be enlarged with the same proportion.
<br>
<br>
Thanks,<br>
Hedayat<br>
<br>
On ۰۹/۱۲/۱۵  02:28, Sander van Dijk wrote:
<blockquote   cite="mid:efd...@ma..."   type="cite">If we take those proportions, the field is still smaller
than our current size of 12x8m (11.5 * 0.5 &lt; 8, 23 * 0.5 &lt; 12).
How about 20x10? This has connection with real rules as half of a real
indoor field and (about) doubles the surface of the field, which makes
sense when doubling the amount of players.<br>
  <br>
I am not sure if the goal should be made much bigger, if it's too big
keepers will have too much trouble blocking a ball. But if we want to
be consistent with the indoor football/futsal dimensions [1], which say
the goal should be 3m wide, we can increase it to 1.5m perhaps.<br>
  <br>
Another issue, which Klaus brought up, is the goal area. Firstly, the
size. I guess we just grow it in proportion to the rest of the field?
And secondly, we probably want to put some rules in place to prevent
pile ups of robots in front of the goal. The kid size league for
instance has the illegal defence/offense rule, which states that you
can' t have more than 1 player in the goal area for longer than 10
seconds. Klaus suggested a version of this rule increasing the maximum
number to 2, which I think is reasonable since our goal area will be
bigger than that of the kid size league.<br>
  <br>
Cheers,<br>
Sander<br>
  <br>
[1] <a moz-do-not-send="true"   href="http://www.fifa.com/mm/51/44/50/futsal%5flotg%5f2008%5fen.pdf">http://www.fifa.com/mm/51/44/50/futsal%5flotg%5f2008%5fen.pdf</a><br>
  <br>
  <div class="gmail_quote">On Tue, Dec 15, 2009 at 9:13 AM, Hedayat
Vatankhah <span dir="ltr">&lt;<a moz-do-not-send="true"   href="mailto:hed...@ai...">hed...@ai...</a>&gt;</span> wrote:<br>
  <blockquote class="gmail_quote"   style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
    <div bgcolor="#ffffff" text="#000000">Hi,<br>
Thank you for the feedback. AFAIK the unit of our field is in meters,
so there is no problem with that. The only problem that might be in
using the official size is that NAO robots are about 50cm in height
which is less than 1/3 of the height of real players, so maybe we
should define the field size according to that ?!<br>
    <br>
Thanks,<br>
    <font color="#888888">Hedayat</font>
    <div>
    <div class="h5"><br>
    <br>
    <br>
On ۰۹/۱۲/۱۵  12:22, <a moz-do-not-send="true"   href="mailto:ah...@un..." target="_blank">ah...@un...</a>
wrote:
    <blockquote type="cite">
      <pre>Hi,


Since 6 vs 6 games are used for indoor soccer competitions, why not use
official regulations from these matches? The DFB defines the size of an
indoor soccer field as 20m x 40m. If metres are hard to represent in ODE,
maybe you should use the size of Nao as a landmark and adjust the size of
the soccer field to him. If we assume Nao to be about 177cm in height, the
field should be 11.5 times as wide as him and 23 times as long as him. I
have no idea if these settings would work, but at least then you'd be very
close to real-life proportions for 6 vs 6 matches.

As for the goals, they should be 2m high and either 3 or 5 metres wide
(that's what the rules say, you can choose).


I hope this helps,

Andreas

  </pre>
      <blockquote type="cite">
        <pre>IranOpen 2010 competitions are coming, and we are preparing for that
competitions. For that competitions we are going to have 6 vs 6 games,
as Khashayar has tested the latest server with the external monitor on
a separate system and it seems that we can run 6 vs 6 games. Khashayar
noticed that the current field size is too small for 12 players, and he
proposes to increase the field size. &lt;br&gt;
IMHO, as the number of players is going to be twice as before, we can
double the size of the field. Also it might be appropriate to increase
the length of the goal (may be twice the current size?).&lt;br&gt;
&lt;br&gt;
What do you think about it?&lt;br&gt;
&lt;br&gt;
Another thing: as the current SVN includes some useful changes, and to
make teams get used to using the external monitor, I think it is nice
to have a new minor version release after adjusting the field size. Any
comments?&lt;br&gt;
Also if there are any small changes which you'd like to have in this
release, please let me know. I hope to have another release including
bigger changes before the deadline for this year's competitions.&lt;br&gt;
    </pre>
      </blockquote>
      <pre>------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
<a moz-do-not-send="true" href="http://p.sf.net/sfu/google-dev2dev"   target="_blank">http://p.sf.net/sfu/google-dev2dev</a>
_______________________________________________
Simspark Generic Physical MAS Simulator
simspark-devel mailing list
<a moz-do-not-send="true"   href="mailto:sim...@li..." target="_blank">sim...@li...</a>
<a moz-do-not-send="true"   href="https://lists.sourceforge.net/lists/listinfo/simspark-devel"   target="_blank">https://lists.sourceforge.net/lists/listinfo/simspark-devel</a>
  </pre>
    </blockquote>
    </div>
    </div>
    </div>
    <br>
------------------------------------------------------------------------------<br>
Return on Information:<br>
Google Enterprise Search pays you back<br>
Get the facts.<br>
    <a moz-do-not-send="true" href="http://p.sf.net/sfu/google-dev2dev"   target="_blank">http://p.sf.net/sfu/google-dev2dev</a><br>
    <br>
_______________________________________________<br>
Simspark Generic Physical MAS Simulator<br>
simspark-devel mailing list<br>
    <a moz-do-not-send="true"   href="mailto:sim...@li...">sim...@li...</a><br>
    <a moz-do-not-send="true"   href="https://lists.sourceforge.net/lists/listinfo/simspark-devel"   target="_blank">https://lists.sourceforge.net/lists/listinfo/simspark-devel</a><br>
    <br>
  </blockquote>
  </div>
  <br>
  <br clear="all">
  <br>
-- <br>
Adaptive Systems Research Group<br>
Department of Computer Science<br>
University of Hertfordshire<br>
United Kingdom<br>
</blockquote>
</body>
</html>

Re: [simspark-devel] Accelerometer

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

Hi Andreas,

I think because you enable the double precision in ODE, then dReal is double.
I recommend to fix the problem in another way:

Vector3f
Body::GetLocalAngularVelocity() const
{
    const dReal* vel = dBodyGetAngularVel(mODEBody);
    dReal w[3];
    dBodyVectorFromWorld(mODEBody, vel[0], vel[1], vel[2], w);
    return Vector3f(w[0],w[1],w[2]);
}

 "(nd Accelerometer" makes problem because I forgot to commit in the
change of spark.rb, sorry

2009/12/18  <ah...@un...>:
> Hi,
>
>
> I just wanted to remark that one of the two functions added to the body
> class together with the Accelerometer does not compile on my computer. I
> get the following compiler error:
>
> /home/andreas/simspark/trunk/spark/lib/oxygen/physicsserver/body.cpp:424:
> error: cannot convert ‘float*’ to ‘dReal*’ for argument ‘5’ to ‘void
> dBodyVectorFromWorld(dxBody*, dReal, dReal, dReal, dReal*)’
>
> It's probably caused by me either having a newer version of ODE (I had to
> rename the CCylinders to Capsules to make it compile) or me using Linux or
> something. Anyway, it was pretty easy to fix:
>
> Vector3f ODERigidBody::GetLocalAngularVelocity() const
> {
>    const dReal* vel = dBodyGetAngularVel(mODEBody);
>    Vector3f w;
>    dReal* wData = (dReal*) w.GetData();
>    dBodyVectorFromWorld(mODEBody, vel[0], vel[1], vel[2], wData);
>    return w;
> }
>
> That code compiles on my computer and from my experiences from casting
> between pointers, shouldn't cause a problem.
>
> Also, the "(nd Accelerometer" in the RSG file makes the RubySceneImporter
> crash. I assume this is already a known issue since it was commented out
> in R124.
>
> Nevertheless, the branch is now up to date with the changes made to the
> trunk.
>
>
> Andreas
>
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> Simspark Generic Physical MAS Simulator
> simspark-devel mailing list
> sim...@li...
> https://lists.sourceforge.net/lists/listinfo/simspark-devel
>



-- 
King Regards,

Xu, Yuan

[simspark-devel] Accelerometer

[<ah...@un...>]

Hi,


I just wanted to remark that one of the two functions added to the body
class together with the Accelerometer does not compile on my computer. I
get the following compiler error:

/home/andreas/simspark/trunk/spark/lib/oxygen/physicsserver/body.cpp:424:
error: cannot convert ‘float*’ to ‘dReal*’ for argument ‘5’ to ‘void
dBodyVectorFromWorld(dxBody*, dReal, dReal, dReal, dReal*)’

It's probably caused by me either having a newer version of ODE (I had to
rename the CCylinders to Capsules to make it compile) or me using Linux or
something. Anyway, it was pretty easy to fix:

Vector3f ODERigidBody::GetLocalAngularVelocity() const
{
    const dReal* vel = dBodyGetAngularVel(mODEBody);
    Vector3f w;
    dReal* wData = (dReal*) w.GetData();
    dBodyVectorFromWorld(mODEBody, vel[0], vel[1], vel[2], wData);
    return w;
}

That code compiles on my computer and from my experiences from casting
between pointers, shouldn't cause a problem.

Also, the "(nd Accelerometer" in the RSG file makes the RubySceneImporter
crash. I assume this is already a known issue since it was commented out
in R124.

Nevertheless, the branch is now up to date with the changes made to the
trunk.


Andreas

Re: [simspark-devel] Field size

[Hedayat V. <hed...@ai...>]

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
<span>Hi,<br>
<br>
<style type="text/css">blockquote {color: navy !important; background-color: RGB(245,245,245) !important; padding: 0 15 10 15 !important; margin: 15 0 0 0; border-left: #1010ff 2px solid;}  blockquote blockquote {color: maroon !important; background-color: RGB(235,235,235) !important; border-left-color:maroon !important}  blockquote blockquote blockquote {color: green !important; background-color: RGB(225,225,225) !important; border-left-color:teal !important}  blockquote blockquote blockquote blockquote {color: purple !important; background-color: RGB(215,215,215) !important; border-left-color: purple !important}  blockquote blockquote blockquote blockquote blockquote {color: teal !important; background-color: RGB(205,205,205) !important; border-left-color: green !important}</style><i><b>Yuan
Xu <a class="moz-txt-link-rfc2396E" href="mailto:xuy...@gm...">&lt;xuy...@gm...&gt;</a></b></i> wrote on ‫سه‌شنبه ۱۵ دسامبر ۰۹،
۱۳:۴۷:۴۰‬:</span>
<blockquote   style="border-left: 2px solid rgb(16, 16, 255); color: navy; background-color: rgb(245, 245, 245); padding-left: 15px;"   cite="mid:18a...@ma..."   type="cite">
  <pre wrap="">Hi,

It is very exciting to have 6 vs 6 game!
  </pre>
</blockquote>
:)<br>
<blockquote   style="border-left: 2px solid rgb(16, 16, 255); color: navy; background-color: rgb(245, 245, 245); padding-left: 15px;"   cite="mid:18a...@ma..."   type="cite">
  <pre wrap="">
I proposed to include the accelerometer, maybe it helps some team.
  </pre>
</blockquote>
Thank you for the accelerometer. It's nice to have more sensors. I
don't see any reason for not including such a sensor in games. :P <br>
<br>
Thanks again,<br>
Hedayat<br>
<br>
<blockquote   style="border-left: 2px solid rgb(16, 16, 255); color: navy; background-color: rgb(245, 245, 245); padding-left: 15px;"   cite="mid:18a...@ma..."   type="cite">
  <pre wrap="">
2009/12/15 Hedayat Vatankhah <a class="moz-txt-link-rfc2396E" href="mailto:hed...@ai...">&lt;hed...@ai...&gt;</a>:
  </pre>
  <blockquote type="cite">
    <pre wrap="">Hi,
Thank you for the feedback. AFAIK the unit of our field is in meters, so
there is no problem with that. The only problem that might be in using the
official size is that NAO robots are about 50cm in height which is less than
1/3 of the height of real players, so maybe we should define the field size
according to that ?!

Thanks,
Hedayat


On ۰۹/۱۲/۱۵  12:22, <a class="moz-txt-link-abbreviated" href="mailto:ah...@un...">ah...@un...</a> wrote:

Hi,


Since 6 vs 6 games are used for indoor soccer competitions, why not use
official regulations from these matches? The DFB defines the size of an
indoor soccer field as 20m x 40m. If metres are hard to represent in ODE,
maybe you should use the size of Nao as a landmark and adjust the size of
the soccer field to him. If we assume Nao to be about 177cm in height, the
field should be 11.5 times as wide as him and 23 times as long as him. I
have no idea if these settings would work, but at least then you'd be very
close to real-life proportions for 6 vs 6 matches.

As for the goals, they should be 2m high and either 3 or 5 metres wide
(that's what the rules say, you can choose).


I hope this helps,

Andreas



IranOpen 2010 competitions are coming, and we are preparing for that
competitions. For that competitions we are going to have 6 vs 6 games,
as Khashayar has tested the latest server with the external monitor on
a separate system and it seems that we can run 6 vs 6 games. Khashayar
noticed that the current field size is too small for 12 players, and he
proposes to increase the field size. &lt;br&gt;
IMHO, as the number of players is going to be twice as before, we can
double the size of the field. Also it might be appropriate to increase
the length of the goal (may be twice the current size?).&lt;br&gt;
&lt;br&gt;
What do you think about it?&lt;br&gt;
&lt;br&gt;
Another thing: as the current SVN includes some useful changes, and to
make teams get used to using the external monitor, I think it is nice
to have a new minor version release after adjusting the field size. Any
comments?&lt;br&gt;
Also if there are any small changes which you'd like to have in this
release, please let me know. I hope to have another release including
bigger changes before the deadline for this year's competitions.&lt;br&gt;


------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
<a class="moz-txt-link-freetext" href="http://p.sf.net/sfu/google-dev2dev">http://p.sf.net/sfu/google-dev2dev</a>
_______________________________________________
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>


------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
<a class="moz-txt-link-freetext" href="http://p.sf.net/sfu/google-dev2dev">http://p.sf.net/sfu/google-dev2dev</a>

_______________________________________________
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>
  <pre wrap=""><!---->


  </pre>
</blockquote>
</body>
</html>

Re: [simspark-devel] Field size

[Sander v. D. <sgv...@gm...>]

If we take those proportions, the field is still smaller than our current
size of 12x8m (11.5 * 0.5 < 8, 23 * 0.5 < 12). How about 20x10? This has
connection with real rules as half of a real indoor field and (about)
doubles the surface of the field, which makes sense when doubling the amount
of players.

I am not sure if the goal should be made much bigger, if it's too big
keepers will have too much trouble blocking a ball. But if we want to be
consistent with the indoor football/futsal dimensions [1], which say the
goal should be 3m wide, we can increase it to 1.5m perhaps.

Another issue, which Klaus brought up, is the goal area. Firstly, the size.
I guess we just grow it in proportion to the rest of the field? And
secondly, we probably want to put some rules in place to prevent pile ups of
robots in front of the goal. The kid size league for instance has the
illegal defence/offense rule, which states that you can' t have more than 1
player in the goal area for longer than 10 seconds. Klaus suggested a
version of this rule increasing the maximum number to 2, which I think is
reasonable since our goal area will be bigger than that of the kid size
league.

Cheers,
Sander

[1] http://www.fifa.com/mm/51/44/50/futsal%5flotg%5f2008%5fen.pdf

On Tue, Dec 15, 2009 at 9:13 AM, Hedayat Vatankhah <hed...@ai...>wrote:

>  Hi,
> Thank you for the feedback. AFAIK the unit of our field is in meters, so
> there is no problem with that. The only problem that might be in using the
> official size is that NAO robots are about 50cm in height which is less than
> 1/3 of the height of real players, so maybe we should define the field size
> according to that ?!
>
> Thanks,
> Hedayat
>
>
>
> On ۰۹/۱۲/۱۵  12:22, ah...@un... wrote:
>
> Hi,
>
>
> Since 6 vs 6 games are used for indoor soccer competitions, why not use
> official regulations from these matches? The DFB defines the size of an
> indoor soccer field as 20m x 40m. If metres are hard to represent in ODE,
> maybe you should use the size of Nao as a landmark and adjust the size of
> the soccer field to him. If we assume Nao to be about 177cm in height, the
> field should be 11.5 times as wide as him and 23 times as long as him. I
> have no idea if these settings would work, but at least then you'd be very
> close to real-life proportions for 6 vs 6 matches.
>
> As for the goals, they should be 2m high and either 3 or 5 metres wide
> (that's what the rules say, you can choose).
>
>
> I hope this helps,
>
> Andreas
>
>
>
>  IranOpen 2010 competitions are coming, and we are preparing for that
> competitions. For that competitions we are going to have 6 vs 6 games,
> as Khashayar has tested the latest server with the external monitor on
> a separate system and it seems that we can run 6 vs 6 games. Khashayar
> noticed that the current field size is too small for 12 players, and he
> proposes to increase the field size. <br>
> IMHO, as the number of players is going to be twice as before, we can
> double the size of the field. Also it might be appropriate to increase
> the length of the goal (may be twice the current size?).<br>
> <br>
> What do you think about it?<br>
> <br>
> Another thing: as the current SVN includes some useful changes, and to
> make teams get used to using the external monitor, I think it is nice
> to have a new minor version release after adjusting the field size. Any
> comments?<br>
> Also if there are any small changes which you'd like to have in this
> release, please let me know. I hope to have another release including
> bigger changes before the deadline for this year's competitions.<br>
>
>
>  ------------------------------------------------------------------------------
> Return on Information:
> Google Enterprise Search pays you back
> Get the facts.http://p.sf.net/sfu/google-dev2dev
> _______________________________________________
> Simspark Generic Physical MAS Simulator
> simspark-devel mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/simspark-devel
>
>
>
> ------------------------------------------------------------------------------
> Return on Information:
> Google Enterprise Search pays you back
> Get the facts.
> http://p.sf.net/sfu/google-dev2dev
>
> _______________________________________________
> 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

Re: [simspark-devel] Field size

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

Hi,

It is very exciting to have 6 vs 6 game!

I proposed to include the accelerometer, maybe it helps some team.

2009/12/15 Hedayat Vatankhah <hed...@ai...>:
> Hi,
> Thank you for the feedback. AFAIK the unit of our field is in meters, so
> there is no problem with that. The only problem that might be in using the
> official size is that NAO robots are about 50cm in height which is less than
> 1/3 of the height of real players, so maybe we should define the field size
> according to that ?!
>
> Thanks,
> Hedayat
>
>
> On ۰۹/۱۲/۱۵  12:22, ah...@un... wrote:
>
> Hi,
>
>
> Since 6 vs 6 games are used for indoor soccer competitions, why not use
> official regulations from these matches? The DFB defines the size of an
> indoor soccer field as 20m x 40m. If metres are hard to represent in ODE,
> maybe you should use the size of Nao as a landmark and adjust the size of
> the soccer field to him. If we assume Nao to be about 177cm in height, the
> field should be 11.5 times as wide as him and 23 times as long as him. I
> have no idea if these settings would work, but at least then you'd be very
> close to real-life proportions for 6 vs 6 matches.
>
> As for the goals, they should be 2m high and either 3 or 5 metres wide
> (that's what the rules say, you can choose).
>
>
> I hope this helps,
>
> Andreas
>
>
>
> IranOpen 2010 competitions are coming, and we are preparing for that
> competitions. For that competitions we are going to have 6 vs 6 games,
> as Khashayar has tested the latest server with the external monitor on
> a separate system and it seems that we can run 6 vs 6 games. Khashayar
> noticed that the current field size is too small for 12 players, and he
> proposes to increase the field size. <br>
> IMHO, as the number of players is going to be twice as before, we can
> double the size of the field. Also it might be appropriate to increase
> the length of the goal (may be twice the current size?).<br>
> <br>
> What do you think about it?<br>
> <br>
> Another thing: as the current SVN includes some useful changes, and to
> make teams get used to using the external monitor, I think it is nice
> to have a new minor version release after adjusting the field size. Any
> comments?<br>
> Also if there are any small changes which you'd like to have in this
> release, please let me know. I hope to have another release including
> bigger changes before the deadline for this year's competitions.<br>
>
>
> ------------------------------------------------------------------------------
> Return on Information:
> Google Enterprise Search pays you back
> Get the facts.
> http://p.sf.net/sfu/google-dev2dev
> _______________________________________________
> Simspark Generic Physical MAS Simulator
> simspark-devel mailing list
> sim...@li...
> https://lists.sourceforge.net/lists/listinfo/simspark-devel
>
>
> ------------------------------------------------------------------------------
> Return on Information:
> Google Enterprise Search pays you back
> Get the facts.
> http://p.sf.net/sfu/google-dev2dev
>
> _______________________________________________
> Simspark Generic Physical MAS Simulator
> simspark-devel mailing list
> sim...@li...
> https://lists.sourceforge.net/lists/listinfo/simspark-devel
>
>



-- 
King Regards,

Xu, Yuan

Re: [simspark-devel] Field size

[Hedayat V. <hed...@ai...>]

<!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>
Thank you for the feedback. AFAIK the unit of our field is in meters,
so there is no problem with that. The only problem that might be in
using the official size is that NAO robots are about 50cm in height
which is less than 1/3 of the height of real players, so maybe we
should define the field size according to that ?!<br>
<br>
Thanks,<br>
Hedayat<br>
<br>
<br>
On ۰۹/۱۲/۱۵  12:22, <a class="moz-txt-link-abbreviated" href="mailto:ah...@un...">ah...@un...</a> wrote:
<blockquote   cite="mid:187...@ma..."   type="cite">
  <pre wrap="">Hi,


Since 6 vs 6 games are used for indoor soccer competitions, why not use
official regulations from these matches? The DFB defines the size of an
indoor soccer field as 20m x 40m. If metres are hard to represent in ODE,
maybe you should use the size of Nao as a landmark and adjust the size of
the soccer field to him. If we assume Nao to be about 177cm in height, the
field should be 11.5 times as wide as him and 23 times as long as him. I
have no idea if these settings would work, but at least then you'd be very
close to real-life proportions for 6 vs 6 matches.

As for the goals, they should be 2m high and either 3 or 5 metres wide
(that's what the rules say, you can choose).


I hope this helps,

Andreas

  </pre>
  <blockquote type="cite">
    <pre wrap="">IranOpen 2010 competitions are coming, and we are preparing for that
competitions. For that competitions we are going to have 6 vs 6 games,
as Khashayar has tested the latest server with the external monitor on
a separate system and it seems that we can run 6 vs 6 games. Khashayar
noticed that the current field size is too small for 12 players, and he
proposes to increase the field size. &lt;br&gt;
IMHO, as the number of players is going to be twice as before, we can
double the size of the field. Also it might be appropriate to increase
the length of the goal (may be twice the current size?).&lt;br&gt;
&lt;br&gt;
What do you think about it?&lt;br&gt;
&lt;br&gt;
Another thing: as the current SVN includes some useful changes, and to
make teams get used to using the external monitor, I think it is nice
to have a new minor version release after adjusting the field size. Any
comments?&lt;br&gt;
Also if there are any small changes which you'd like to have in this
release, please let me know. I hope to have another release including
bigger changes before the deadline for this year's competitions.&lt;br&gt;
    </pre>
  </blockquote>
  <pre wrap="">

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
<a class="moz-txt-link-freetext" href="http://p.sf.net/sfu/google-dev2dev">http://p.sf.net/sfu/google-dev2dev</a>
_______________________________________________
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>

Re: [simspark-devel] Field size

[<ah...@un...>]

Hi,


Since 6 vs 6 games are used for indoor soccer competitions, why not use
official regulations from these matches? The DFB defines the size of an
indoor soccer field as 20m x 40m. If metres are hard to represent in ODE,
maybe you should use the size of Nao as a landmark and adjust the size of
the soccer field to him. If we assume Nao to be about 177cm in height, the
field should be 11.5 times as wide as him and 23 times as long as him. I
have no idea if these settings would work, but at least then you'd be very
close to real-life proportions for 6 vs 6 matches.

As for the goals, they should be 2m high and either 3 or 5 metres wide
(that's what the rules say, you can choose).


I hope this helps,

Andreas

> IranOpen 2010 competitions are coming, and we are preparing for that
> competitions. For that competitions we are going to have 6 vs 6 games,
> as Khashayar has tested the latest server with the external monitor on
> a separate system and it seems that we can run 6 vs 6 games. Khashayar
> noticed that the current field size is too small for 12 players, and he
> proposes to increase the field size. <br>
> IMHO, as the number of players is going to be twice as before, we can
> double the size of the field. Also it might be appropriate to increase
> the length of the goal (may be twice the current size?).<br>
> <br>
> What do you think about it?<br>
> <br>
> Another thing: as the current SVN includes some useful changes, and to
> make teams get used to using the external monitor, I think it is nice
> to have a new minor version release after adjusting the field size. Any
> comments?<br>
> Also if there are any small changes which you'd like to have in this
> release, please let me know. I hope to have another release including
> bigger changes before the deadline for this year's competitions.<br>

[simspark-devel] Field size

[Hedayat V. <hed...@ai...>]

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html style="direction: ltr;">
<head>

<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body style="direction: ltr;" bgcolor="#ffffff" text="#000000">
Hi all,<br>
IranOpen 2010 competitions are coming, and we are preparing for that
competitions. For that competitions we are going to have 6 vs 6 games,
as Khashayar has tested the latest server with the external monitor on
a separate system and it seems that we can run 6 vs 6 games. Khashayar
noticed that the current field size is too small for 12 players, and he
proposes to increase the field size. <br>
IMHO, as the number of players is going to be twice as before, we can
double the size of the field. Also it might be appropriate to increase
the length of the goal (may be twice the current size?).<br>
<br>
What do you think about it?<br>
<br>
Another thing: as the current SVN includes some useful changes, and to
make teams get used to using the external monitor, I think it is nice
to have a new minor version release after adjusting the field size. Any
comments?<br>
Also if there are any small changes which you'd like to have in this
release, please let me know. I hope to have another release including
bigger changes before the deadline for this year's competitions.<br>
<br>
Good luck,<br>
Hedayat<br>
<br>
</body>
</html>

Re: [simspark-devel] [simspark-svn] SF.net SVN: simspark:[118] branches/multiphys

[Hedayat V. <hed...@ai...>]

Hi,
IMHO using a GenericPhysicsObject class for passing all parameters is 
not very nice. For example, it doesn't show that CRM function needs a 
matrix. I suggest defining a class for each type: e.g. 
GenericPhysicsMatrix for functions which need a matrix.
Also, if engine specific classes inherit from generic classes 
(ODEMatrixClass inherited from both GenericPhysicsMatrix and dMatrix3, 
or inherited from GenericPhysicsMatrix and having a dMatrix3 member), 
you won't need to cast the object to the Generic class when passing 
object as a function parameter.

BTW, use whatever you prefer.

Thanks a lot,
Hedayat

On ۰۹/۱۲/۱۰  12:04, a-...@us... wrote:
> Revision: 118
>            http://simspark.svn.sourceforge.net/simspark/?rev=118&view=rev
> Author:   a-held
> Date:     2009-12-10 08:34:56 +0000 (Thu, 10 Dec 2009)
>
> Log Message:
> -----------
> Searched and renamed all CCylinders, CappedCylinders and Capped Cylinders to Capsule
> Implemented bridge pattern for CapsuleCollider
> Provided bridge pattern for ConeCollider
> Declared GenericPhysicsObject class that can be cast to in order to pass pointers
>      to engine-specific objects on to the abstract layer (like void*, but cleaner)
>