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: Hedayat V. <hed...@ai...> - 2009-12-10 08:59:34
|
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) > > Modified Paths: > -------------- > branches/multiphys/rcssserver3d/data/rsg/agent/hoap2.rsg > branches/multiphys/rcssserver3d/data/rsg/agent/nao/naoneckhead.rsg > branches/multiphys/rcssserver3d/data/rsg/agent/soccerbot055.rsg > branches/multiphys/rcssserver3d/data/rsg/agent/soccerbot056.rsg > branches/multiphys/rcssserver3d/data/rsg/agent/soccerbot058/lowerarm.rsg > branches/multiphys/rcssserver3d/data/rsg/agent/soccerbot058/soccerbot.rsg > branches/multiphys/rcssserver3d/data/rsg/agent/soccerbotcomp.rsg > branches/multiphys/rcssserver3d/doc/users/robots.tex > branches/multiphys/spark/data/ros/aibo.rsi > branches/multiphys/spark/data/ros/blockworld.ros > branches/multiphys/spark/data/rsg/boxspheres/simspark.rsg > branches/multiphys/spark/lib/kerosin/CMakeLists.txt > branches/multiphys/spark/lib/kerosin/kerosin.cpp > branches/multiphys/spark/lib/kerosin/kerosin.h > branches/multiphys/spark/lib/oxygen/CMakeLists.txt > branches/multiphys/spark/lib/oxygen/geometryserver/stdmeshimporter.cpp > branches/multiphys/spark/lib/oxygen/geometryserver/stdmeshimporter.h > branches/multiphys/spark/lib/oxygen/physicsserver/capsulecollider.cpp > branches/multiphys/spark/lib/oxygen/physicsserver/capsulecollider.h > branches/multiphys/spark/lib/oxygen/physicsserver/capsulecollider_c.cpp > branches/multiphys/spark/lib/oxygen/physicsserver/collider.cpp > branches/multiphys/spark/lib/oxygen/physicsserver/conecollider.h > branches/multiphys/spark/lib/oxygen/physicsserver/int/boxcolliderint.h > branches/multiphys/spark/lib/oxygen/physicsserver/int/physicsobjectint.h > branches/multiphys/spark/lib/oxygen/physicsserver/int/spherecolliderint.h > branches/multiphys/spark/lib/oxygen/physicsserver/int/worldint.h > branches/multiphys/spark/lib/oxygen/physicsserver/ode/odecollider.cpp > branches/multiphys/spark/lib/oxygen/physicsserver/ode/odephysicsobject.cpp > branches/multiphys/spark/lib/oxygen/physicsserver/ode/odephysicsobject.h > branches/multiphys/spark/lib/oxygen/physicsserver/ode/oderigidbody.cpp > branches/multiphys/spark/lib/oxygen/physicsserver/physicsobject.cpp > branches/multiphys/spark/lib/oxygen/physicsserver/physicsobject.h > branches/multiphys/spark/lib/oxygen/physicsserver/rigidbody.cpp > branches/multiphys/spark/lib/oxygen/physicsserver/rigidbody.h > branches/multiphys/spark/lib/oxygen/physicsserver/rigidbody_c.cpp > branches/multiphys/spark/plugin/rosimporter/roselements.cpp > branches/multiphys/spark/plugin/rosimporter/roselements.h > branches/multiphys/spark/plugin/rosimporter/rosimporter.cpp > branches/multiphys/spark/plugin/rosimporter/rosimporter.h > > Added Paths: > ----------- > branches/multiphys/rcssserver3d/data/rsg/agent/nao/capsule_appearance.rsg > branches/multiphys/rcssserver3d/data/rsg/agent/nao/capsule_physics.rsg > branches/multiphys/rcssserver3d/data/rsg/agent/nao/capsule_physics_nocollider.rsg > branches/multiphys/rcssserver3d/data/rsg/agent/soccerbot058/box_with_hj_with_capsule.rsg > branches/multiphys/spark/data/rsg/boxspheres/capsule.rsg > branches/multiphys/spark/data/rsg/boxspheres/staticcapsule.rsg > branches/multiphys/spark/lib/kerosin/sceneserver/capsule.cpp > branches/multiphys/spark/lib/kerosin/sceneserver/capsule.h > branches/multiphys/spark/lib/kerosin/sceneserver/capsule_c.cpp > branches/multiphys/spark/lib/oxygen/physicsserver/conecollider.cpp > branches/multiphys/spark/lib/oxygen/physicsserver/genericphysicsobject.h > branches/multiphys/spark/lib/oxygen/physicsserver/int/capsulecolliderint.h > branches/multiphys/spark/lib/oxygen/physicsserver/int/conecolliderint.h > branches/multiphys/spark/lib/oxygen/physicsserver/ode/odecapsulecollider.cpp > branches/multiphys/spark/lib/oxygen/physicsserver/ode/odecapsulecollider.h > branches/multiphys/spark/lib/oxygen/physicsserver/ode/odeconecollider.cpp > branches/multiphys/spark/lib/oxygen/physicsserver/ode/odeconecollider.h > > Removed Paths: > ------------- > branches/multiphys/rcssserver3d/data/rsg/agent/nao/ccylinder_appearance.rsg > branches/multiphys/rcssserver3d/data/rsg/agent/nao/ccylinder_physics.rsg > branches/multiphys/rcssserver3d/data/rsg/agent/nao/ccylinder_physics_nocollider.rsg > branches/multiphys/rcssserver3d/data/rsg/agent/soccerbot058/box_with_hj_with_ccylinder.rsg > branches/multiphys/spark/data/rsg/boxspheres/ccylinder.rsg > branches/multiphys/spark/data/rsg/boxspheres/staticccylinder.rsg > branches/multiphys/spark/lib/kerosin/sceneserver/ccylinder.cpp > branches/multiphys/spark/lib/kerosin/sceneserver/ccylinder.h > branches/multiphys/spark/lib/kerosin/sceneserver/ccylinder_c.cpp > > Modified: branches/multiphys/rcssserver3d/data/rsg/agent/hoap2.rsg > =================================================================== > --- branches/multiphys/rcssserver3d/data/rsg/agent/hoap2.rsg 2009-12-09 08:42:42 UTC (rev 117) > +++ branches/multiphys/rcssserver3d/data/rsg/agent/hoap2.rsg 2009-12-10 08:34:56 UTC (rev 118) > @@ -142,7 +142,7 @@ > (nd Transform > (setLocalPos $offsetLeftShoulderCylX $offsetLeftShoulderCylY $offsetLeftShoulderCylZ) > (setLocalRotation 0 90 0) > - (nd CCylinder > + (nd Capsule > (setMaterial matGrey) > (setParams $TorsoCylinderRadius $TorsoCylinderLength) > ) > @@ -151,7 +151,7 @@ > (nd Transform > (setLocalPos $offsetRightShoulderCylX $offsetRightShoulderCylY $offsetRightShoulderCylZ) > (setLocalRotation 0 90 0) > - (nd CCylinder > + (nd Capsule > (setMaterial matGrey) > (setParams $TorsoCylinderRadius $TorsoCylinderLength) > ) > @@ -373,7 +373,7 @@ > (nd Transform > (setLocalPos 0 0 (eval -1 * (eval (eval $UpperarmHeight / 2.0) + (eval $ElbowRadius / 2.0)))) > (setLocalRotation 0 90 0) > - (nd CCylinder > + (nd Capsule > (setMaterial matGrey) > (setParams $ElbowRadius $ElbowLength) > ) > @@ -410,7 +410,7 @@ > (nd Transform > (setLocalPos 0 0 (eval -1 * (eval (eval $UpperarmHeight / 2.0) + (eval $ElbowRadius / 2.0)))) > (setLocalRotation 0 90 0) > - (nd CCylinder > + (nd Capsule > (setMaterial matGrey) > (setParams $ElbowRadius $ElbowLength) > ) > > Added: branches/multiphys/rcssserver3d/data/rsg/agent/nao/capsule_appearance.rsg > =================================================================== > --- branches/multiphys/rcssserver3d/data/rsg/agent/nao/capsule_appearance.rsg (rev 0) > +++ branches/multiphys/rcssserver3d/data/rsg/agent/nao/capsule_appearance.rsg 2009-12-10 08:34:56 UTC (rev 118) > @@ -0,0 +1,11 @@ > +; -*- mode: lisp; -*- > + > +(RSG 0 1) > +( > + (templ $radius $length $material) > + > + (nd Capsule > + (setParams $radius $length) > + (setMaterial $material) > + ) > +) > > Added: branches/multiphys/rcssserver3d/data/rsg/agent/nao/capsule_physics.rsg > =================================================================== > --- branches/multiphys/rcssserver3d/data/rsg/agent/nao/capsule_physics.rsg (rev 0) > +++ branches/multiphys/rcssserver3d/data/rsg/agent/nao/capsule_physics.rsg 2009-12-10 08:34:56 UTC (rev 118) > @@ -0,0 +1,19 @@ > +; -*- mode: lisp; -*- > + > +(RSG 0 1) > +( > + (templ $radius $length $totalMass) > + > + (nd RigidBody > + (setName capsuleBody) > + (setCapsuleTotal $totalMass $radius $length) > + > + (importScene rsg/agent/nao/dragcontroller.rsg) > + ) > + > + (nd CapsuleCollider > + (setParams $radius $length) > + > + (importScene rsg/agent/nao/contactjointhandler.rsg) > + ) > + ) > > Added: branches/multiphys/rcssserver3d/data/rsg/agent/nao/capsule_physics_nocollider.rsg > =================================================================== > --- branches/multiphys/rcssserver3d/data/rsg/agent/nao/capsule_physics_nocollider.rsg (rev 0) > +++ branches/multiphys/rcssserver3d/data/rsg/agent/nao/capsule_physics_nocollider.rsg 2009-12-10 08:34:56 UTC (rev 118) > @@ -0,0 +1,13 @@ > +; -*- mode: lisp; -*- > + > +(RSG 0 1) > +( > + (templ $radius $length $totalMass) > + > + (nd RigidBody > + (setName capsuleBody) > + (setCapsuleTotal $totalMass $radius) > + > + (importScene rsg/agent/nao/dragcontroller.rsg) > + ) > +) > > Deleted: branches/multiphys/rcssserver3d/data/rsg/agent/nao/ccylinder_appearance.rsg > =================================================================== > --- branches/multiphys/rcssserver3d/data/rsg/agent/nao/ccylinder_appearance.rsg 2009-12-09 08:42:42 UTC (rev 117) > +++ branches/multiphys/rcssserver3d/data/rsg/agent/nao/ccylinder_appearance.rsg 2009-12-10 08:34:56 UTC (rev 118) > @@ -1,11 +0,0 @@ > -; -*- mode: lisp; -*- > - > -(RSG 0 1) > -( > - (templ $radius $length $material) > - > - (nd CCylinder > - (setParams $radius $length) > - (setMaterial $material) > - ) > -) > > Deleted: branches/multiphys/rcssserver3d/data/rsg/agent/nao/ccylinder_physics.rsg > =================================================================== > --- branches/multiphys/rcssserver3d/data/rsg/agent/nao/ccylinder_physics.rsg 2009-12-09 08:42:42 UTC (rev 117) > +++ branches/multiphys/rcssserver3d/data/rsg/agent/nao/ccylinder_physics.rsg 2009-12-10 08:34:56 UTC (rev 118) > @@ -1,19 +0,0 @@ > -; -*- mode: lisp; -*- > - > -(RSG 0 1) > -( > - (templ $radius $length $totalMass) > - > - (nd RigidBody > - (setName ccylinderBody) > - (setCappedCylinderTotal $totalMass $radius $length) > - > - (importScene rsg/agent/nao/dragcontroller.rsg) > - ) > - > - (nd CCylinderCollider > - (setParams $radius $length) > - > - (importScene rsg/agent/nao/contactjointhandler.rsg) > - ) > - ) > > Deleted: branches/multiphys/rcssserver3d/data/rsg/agent/nao/ccylinder_physics_nocollider.rsg > =================================================================== > --- branches/multiphys/rcssserver3d/data/rsg/agent/nao/ccylinder_physics_nocollider.rsg 2009-12-09 08:42:42 UTC (rev 117) > +++ branches/multiphys/rcssserver3d/data/rsg/agent/nao/ccylinder_physics_nocollider.rsg 2009-12-10 08:34:56 UTC (rev 118) > @@ -1,13 +0,0 @@ > -; -*- mode: lisp; -*- > - > -(RSG 0 1) > -( > - (templ $radius $length $totalMass) > - > - (nd RigidBody > - (setName ccylinderBody) > - (setCappedCylinderTotal $totalMass $radius) > - > - (importScene rsg/agent/nao/dragcontroller.rsg) > - ) > -) > > Modified: branches/multiphys/rcssserver3d/data/rsg/agent/nao/naoneckhead.rsg > =================================================================== > --- branches/multiphys/rcssserver3d/data/rsg/agent/nao/naoneckhead.rsg 2009-12-09 08:42:42 UTC (rev 117) > +++ branches/multiphys/rcssserver3d/data/rsg/agent/nao/naoneckhead.rsg 2009-12-10 08:34:56 UTC (rev 118) > @@ -43,12 +43,12 @@ > (setName neck) > (setLocalPos $Neck_X $Neck_Y $Neck_Z) > > - (importScene rsg/agent/nao/ccylinder_appearance.rsg $Neck_Radius $Neck_Length matDarkGrey) > - (importScene rsg/agent/nao/ccylinder_physics.rsg $Neck_Radius $Neck_Length $Neck_Mass) > + (importScene rsg/agent/nao/capsule_appearance.rsg $Neck_Radius $Neck_Length matDarkGrey) > + (importScene rsg/agent/nao/capsule_physics.rsg $Neck_Radius $Neck_Length $Neck_Mass) > > (importScene rsg/agent/nao/hingejoint.rsg > hj1 he1 > - ../ccylinderBody ../../body/boxBody > + ../capsuleBody ../../body/boxBody > 0 0 0 > 0 0 1 > $he1_min $he1_max) > @@ -80,7 +80,7 @@ > > (importScene rsg/agent/nao/hingejoint.rsg > hj2 he2 > - ../sphereBody ../../neck/ccylinderBody > + ../sphereBody ../../neck/capsuleBody > ;../boxBody ../../body/boxBody > 0 0 -0.005 > 1 0 0 > > Modified: branches/multiphys/rcssserver3d/data/rsg/agent/soccerbot055.rsg > =================================================================== > --- branches/multiphys/rcssserver3d/data/rsg/agent/soccerbot055.rsg 2009-12-09 08:42:42 UTC (rev 117) > +++ branches/multiphys/rcssserver3d/data/rsg/agent/soccerbot055.rsg 2009-12-10 08:34:56 UTC (rev 118) > @@ -168,7 +168,7 @@ > (nd Transform > (setLocalPos $offsetLeftShoulderCylX $offsetLeftShoulderCylY $offsetLeftShoulderCylZ) > (setLocalRotation 0 90 0) > - (nd CCylinder > + (nd Capsule > (setName leftshoulderpin) > (setMaterial matDarkGrey) > (setParams $TorsoCylinderRadius $TorsoCylinderLength) > @@ -178,7 +178,7 @@ > (nd Transform > (setLocalPos $offsetRightShoulderCylX $offsetRightShoulderCylY $offsetRightShoulderCylZ) > (setLocalRotation 0 90 0) > - (nd CCylinder > + (nd Capsule > (setName rightshoulderpin) > (setMaterial matDarkGrey) > (setParams $TorsoCylinderRadius $TorsoCylinderLength) > @@ -336,7 +336,7 @@ > (nd Transform > (setLocalPos 0 0 (eval -1 * (eval (eval $UpperarmHeight / 2.0) + (eval $ElbowRadius / 2.0)))) > (setLocalRotation 0 90 0) > - (nd CCylinder > + (nd Capsule > (setMaterial matGrey) > (setParams $ElbowRadius $ElbowLength) > ) > @@ -374,7 +374,7 @@ > (nd Transform > (setLocalPos 0 0 (eval -1 * (eval (eval $UpperarmHeight / 2.0) + (eval $ElbowRadius / 2.0)))) > (setLocalRotation 0 90 0) > - (nd CCylinder > + (nd Capsule > (setMaterial matGrey) > (setParams $ElbowRadius $ElbowLength) > ) > > Modified: branches/multiphys/rcssserver3d/data/rsg/agent/soccerbot056.rsg > =================================================================== > --- branches/multiphys/rcssserver3d/data/rsg/agent/soccerbot056.rsg 2009-12-09 08:42:42 UTC (rev 117) > +++ branches/multiphys/rcssserver3d/data/rsg/agent/soccerbot056.rsg 2009-12-10 08:34:56 UTC (rev 118) > @@ -204,7 +204,7 @@ > (nd Transform > (setLocalPos $offsetLeftShoulderCylX $offsetLeftShoulderCylY $offsetLeftShoulderCylZ) > (setLocalRotation 0 90 0) > - (nd CCylinder > + (nd Capsule > (setName leftshoulderpin) > (setMaterial matDarkGrey) > (setParams $TorsoCylinderRadius $TorsoCylinderLength) > @@ -214,7 +214,7 @@ > (nd Transform > (setLocalPos $offsetRightShoulderCylX $offsetRightShoulderCylY $offsetRightShoulderCylZ) > (setLocalRotation 0 90 0) > - (nd CCylinder > + (nd Capsule > (setName rightshoulderpin) > (setMaterial matDarkGrey) > (setParams $TorsoCylinderRadius $TorsoCylinderLength) > @@ -409,7 +409,7 @@ > (nd Transform > (setLocalPos 0 0 (eval -1 * (eval (eval $UpperarmHeight / 2.0) + (eval $ElbowRadius / 2.0)))) > (setLocalRotation 0 90 0) > - (nd CCylinder > + (nd Capsule > (setMaterial matGrey) > (setParams $ElbowRadius $ElbowLength) > ) > @@ -455,7 +455,7 @@ > (nd Transform > (setLocalPos 0 0 (eval -1 * (eval (eval $UpperarmHeight / 2.0) + (eval $ElbowRadius / 2.0)))) > (setLocalRotation 0 90 0) > - (nd CCylinder > + (nd Capsule > (setMaterial matGrey) > (setParams $ElbowRadius $ElbowLength) > ) > @@ -771,7 +771,7 @@ > (nd Transform > (setLocalPos 0 0 (eval (eval $ThighHeight * -0.5) - 0.025)) > (setLocalRotation 0 90 0) > - (nd CCylinder > + (nd Capsule > (setMaterial matRed) > (setParams 0.1 (eval $ThighLength - 0.2)) > ) > @@ -812,7 +812,7 @@ > (nd Transform > (setLocalPos 0 0 (eval (eval $ThighHeight * -0.5) - 0.025)) > (setLocalRotation 0 90 0) > - (nd CCylinder > + (nd Capsule > (setMaterial matRed) > (setParams 0.1 (eval $ThighLength - 0.2)) > ) > > Added: branches/multiphys/rcssserver3d/data/rsg/agent/soccerbot058/box_with_hj_with_capsule.rsg > =================================================================== > --- branches/multiphys/rcssserver3d/data/rsg/agent/soccerbot058/box_with_hj_with_capsule.rsg (rev 0) > +++ branches/multiphys/rcssserver3d/data/rsg/agent/soccerbot058/box_with_hj_with_capsule.rsg 2009-12-10 08:34:56 UTC (rev 118) > @@ -0,0 +1,37 @@ > +;; -*- mode: lisp; -*- > + > +(RSG 0 1) > +( > + (templ $name $perceptorName $effectorName $attach > + $x $y $z > + $lenX $lenY $lenZ > + $anchorX $anchorY $anchorZ > + $axisX $axisY $axisZ $minDeg $maxDeg > + $totalMass $material $ElbowRadius $ElbowLen) > + > + (nd Transform > + (setName $name) > + (setLocalPos $x $y $z) > + (importScene rsg/agent/soccerbot058/box.rsg > + $lenX $lenY $lenZ > + $totalMass $material) > + > + ;; install hinge joint > + (importScene rsg/agent/nao/hingejoint.rsg > + $perceptorName $effectorName > + ../boxBody $attach > + $anchorX $anchorY $anchorZ > + $axisX $axisY $axisZ > + $minDeg $maxDeg) > + > + ;; static cylinder for the elbow > + (nd Transform > + (setLocalPos $anchorX $anchorY $anchorZ) > + (setLocalRotation 0 90 0) > + (nd Capsule > + (setMaterial matGrey) > + (setParams $ElbowRadius $ElbowLen) > + ) > + ) > + ) > + ) > > Deleted: branches/multiphys/rcssserver3d/data/rsg/agent/soccerbot058/box_with_hj_with_ccylinder.rsg > =================================================================== > --- branches/multiphys/rcssserver3d/data/rsg/agent/soccerbot058/box_with_hj_with_ccylinder.rsg 2009-12-09 08:42:42 UTC (rev 117) > +++ branches/multiphys/rcssserver3d/data/rsg/agent/soccerbot058/box_with_hj_with_ccylinder.rsg 2009-12-10 08:34:56 UTC (rev 118) > @@ -1,37 +0,0 @@ > -;; -*- mode: lisp; -*- > - > -(RSG 0 1) > -( > - (templ $name $perceptorName $effectorName $attach > - $x $y $z > - $lenX $lenY $lenZ > - $anchorX $anchorY $anchorZ > - $axisX $axisY $axisZ $minDeg $maxDeg > - $totalMass $material $ElbowRadius $ElbowLen) > - > - (nd Transform > - (setName $name) > - (setLocalPos $x $y $z) > - (importScene rsg/agent/soccerbot058/box.rsg > - $lenX $lenY $lenZ > - $totalMass $material) > - > - ;; install hinge joint > - (importScene rsg/agent/nao/hingejoint.rsg > - $perceptorName $effectorName > - ../boxBody $attach > - $anchorX $anchorY $anchorZ > - $axisX $axisY $axisZ > - $minDeg $maxDeg) > - > - ;; static cylinder for the elbow > - (nd Transform > - (setLocalPos $anchorX $anchorY $anchorZ) > - (setLocalRotation 0 90 0) > - (nd CCylinder > - (setMaterial matGrey) > - (setParams $ElbowRadius $ElbowLen) > - ) > - ) > - ) > - ) > > Modified: branches/multiphys/rcssserver3d/data/rsg/agent/soccerbot058/lowerarm.rsg > =================================================================== > --- branches/multiphys/rcssserver3d/data/rsg/agent/soccerbot058/lowerarm.rsg 2009-12-09 08:42:42 UTC (rev 117) > +++ branches/multiphys/rcssserver3d/data/rsg/agent/soccerbot058/lowerarm.rsg 2009-12-10 08:34:56 UTC (rev 118) > @@ -38,7 +38,7 @@ > (nd Transform > (setLocalPos $anchorX $anchorY $anchorZ) > (setLocalRotation 0 90 0) > - (nd CCylinder > + (nd Capsule > (setMaterial matGrey) > (setParams $ElbowRadius $ElbowLen) > ) > > Modified: branches/multiphys/rcssserver3d/data/rsg/agent/soccerbot058/soccerbot.rsg > =================================================================== > --- branches/multiphys/rcssserver3d/data/rsg/agent/soccerbot058/soccerbot.rsg 2009-12-09 08:42:42 UTC (rev 117) > +++ branches/multiphys/rcssserver3d/data/rsg/agent/soccerbot058/soccerbot.rsg 2009-12-10 08:34:56 UTC (rev 118) > @@ -216,7 +216,7 @@ > $offsetLeftShoulderCylY > $offsetLeftShoulderCylZ) > (setLocalRotation 0 90 0) > - (nd CCylinder > + (nd Capsule > (setName leftshoulderpin) > (setMaterial matDarkGrey) > (setParams $TorsoCylinderRadius $TorsoCylinderLength) > @@ -228,7 +228,7 @@ > $offsetRightShoulderCylY > $offsetRightShoulderCylZ) > (setLocalRotation 0 90 0) > - (nd CCylinder > + (nd Capsule > (setName rightshoulderpin) > (setMaterial matDarkGrey) > (setParams $TorsoCylinderRadius $TorsoCylinderLength) > @@ -434,7 +434,7 @@ > - (eval $ShankHeight / 2.0) > - (eval 0.05 * $scale))) > (def $ShankAnchorZ (eval $ShankHeight * 0.5)) > - (importScene rsg/agent/soccerbot058/box_with_hj_with_ccylinder.rsg > + (importScene rsg/agent/soccerbot058/box_with_hj_with_capsule.rsg > leftshank llj4 lle4 ../../leftthigh/boxBody > $LeftShankPosX $LeftShankPosY $LeftShankPosZ > $ShankLength $ShankWidth $ShankHeight > @@ -447,7 +447,7 @@ > (def $RightShankPosX $RightThighPosX) > (def $RightShankPosY $RightThighPosY) > (def $RightShankPosZ $LeftShankPosZ) > - (importScene rsg/agent/soccerbot058/box_with_hj_with_ccylinder.rsg > + (importScene rsg/agent/soccerbot058/box_with_hj_with_capsule.rsg > rightshank rlj4 rle4 ../../rightthigh/boxBody > $RightShankPosX $RightShankPosY $RightShankPosZ > $ShankLength $ShankWidth $ShankHeight > > Modified: branches/multiphys/rcssserver3d/data/rsg/agent/soccerbotcomp.rsg > =================================================================== > --- branches/multiphys/rcssserver3d/data/rsg/agent/soccerbotcomp.rsg 2009-12-09 08:42:42 UTC (rev 117) > +++ branches/multiphys/rcssserver3d/data/rsg/agent/soccerbotcomp.rsg 2009-12-10 08:34:56 UTC (rev 118) > @@ -203,7 +203,7 @@ > (nd Transform > (setLocalPos $offsetLeftShoulderCylX $offsetLeftShoulderCylY $offsetLeftShoulderCylZ) > (setLocalRotation 0 90 0) > - (nd CCylinder > + (nd Capsule > (setName leftshoulderpin) > (setMaterial matDarkGrey) > (setParams $TorsoCylinderRadius $TorsoCylinderLength) > @@ -213,7 +213,7 @@ > (nd Transform > (setLocalPos $offsetRightShoulderCylX $offsetRightShoulderCylY $offsetRightShoulderCylZ) > (setLocalRotation 0 90 0) > - (nd CCylinder > + (nd Capsule > (setName rightshoulderpin) > (setMaterial matDarkGrey) > (setParams $TorsoCylinderRadius $TorsoCylinderLength) > @@ -369,7 +369,7 @@ > (nd Transform > (setLocalPos 0 0 (eval -1 * (eval (eval $UpperarmHeight / 2.0) + (eval $ElbowRadius / 2.0)))) > (setLocalRotation 0 90 0) > - (nd CCylinder > + (nd Capsule > (setMaterial matGrey) > (setParams $ElbowRadius $ElbowLength) > ) > @@ -415,7 +415,7 @@ > (nd Transform > (setLocalPos 0 0 (eval -1 * (eval (eval $UpperarmHeight / 2.0) + (eval $ElbowRadius / 2.0)))) > (setLocalRotation 0 90 0) > - (nd CCylinder > + (nd Capsule > (setMaterial matGrey) > (setParams $ElbowRadius $ElbowLength) > ) > @@ -621,7 +621,7 @@ > (nd Transform > (setLocalPos 0 0 (eval (eval $ThighHeight * -0.5) - 0.025)) > (setLocalRotation 0 90 0) > - (nd CCylinder > + (nd Capsule > (setMaterial matRed) > (setParams 0.1 (eval $ThighLength - 0.2)) > ) > @@ -662,7 +662,7 @@ > (nd Transform > (setLocalPos 0 0 (eval (eval $ThighHeight * -0.5) - 0.025)) > (setLocalRotation 0 90 0) > - (nd CCylinder > + (nd Capsule > (setMaterial matRed) > (setParams 0.1 (eval $ThighLength - 0.2)) > ) > > Modified: branches/multiphys/rcssserver3d/doc/users/robots.tex > =================================================================== > --- branches/multiphys/rcssserver3d/doc/users/robots.tex 2009-12-09 08:42:42 UTC (rev 117) > +++ branches/multiphys/rcssserver3d/doc/users/robots.tex 2009-12-10 08:34:56 UTC (rev 118) > @@ -237,11 +237,11 @@ > box\_physics\_with\_handler.rsg& Not only do the job as file > “box\_physics.rsg”, but also install a touchperceptorhandler under > the BoxCollider Node. \\ > - ccylinder\_appearance.rsg& Install a capped cylinder which is > + capsule\_appearance.rsg& Install a capsule which is > for the GL render. \\ > - ccylinder\_physics.rsg& Install a capped cylinder that has > + capsule\_physics.rsg& Install a capsule that has > physics effect(ODE related) \\ > - ccylinder\_physics\_nocollider.rsg& Install a capped cylinder that > + capsule\_physics\_nocollider.rsg& Install a capsule that > only has dynamics effect (mass, linear velocity, etc). But it can > never collide to the others. \\ > contactjointhandler.rsg& Install a contactjointhandler to > > Modified: branches/multiphys/spark/data/ros/aibo.rsi > =================================================================== > --- branches/multiphys/spark/data/ros/aibo.rsi 2009-12-09 08:42:42 UTC (rev 117) > +++ branches/multiphys/spark/data/ros/aibo.rsi 2009-12-10 08:34:56 UTC (rev 118) > @@ -12184,13 +12184,13 @@ > </PhysicalAttributes> > </SimpleBox> > <!-- > -<SimpleCappedCylinder name="larm3Capped" radius="0.016" height="0.03"> > +<SimpleCapsule name="larm3Capped" radius="0.016" height="0.03"> > <Translation x="-0.003" y="-0.028" z="0.0"/> > <Rotation x="-90.0" y="0.0" z="-25.0"/> > <PhysicalAttributes> > <Mass value="0.05"/> > </PhysicalAttributes> > -</SimpleCappedCylinder> > +</SimpleCapsule> > --> > </PhysicalRepresentation> > </ComplexShape> > @@ -15442,13 +15442,13 @@ > </PhysicalAttributes> > </SimpleBox> > <!-- > -<SimpleCappedCylinder name="rarm3Capped" radius="0.016" height="0.03"> > +<SimpleCapsule name="rarm3Capped" radius="0.016" height="0.03"> > <Translation x="-0.003" y="-0.028" z="0.0"/> > <Rotation x="-90.0" y="0.0" z="-25.0"/> > <PhysicalAttributes> > <Mass value="0.05"/> > </PhysicalAttributes> > -</SimpleCappedCylinder> > +</SimpleCapsule> > --> > </PhysicalRepresentation> > </ComplexShape> > @@ -24870,13 +24870,13 @@ > </Polygon> > </GraphicalRepresentation> > <PhysicalRepresentation> > -<SimpleCappedCylinder name="headCCylinder" radius="0.026" height="0.075"> > +<SimpleCapsule name="headCapsule" radius="0.026" height="0.075"> > <Translation x="-0.023" y="0.005" z="0.0"/> > <Rotation x="0.0" y="90.0" z="20.0"/> > <PhysicalAttributes> > <Mass value="0.25"/> > </PhysicalAttributes> > -</SimpleCappedCylinder> > +</SimpleCapsule> > <SimpleSphere name="headSphere" radius="0.032"> > <Translation x="0.012" y="0.012" z="0.0"/> > <PhysicalAttributes> > @@ -25191,13 +25191,13 @@ > </Polygon> > </GraphicalRepresentation> > <PhysicalRepresentation> > -<SimpleCappedCylinder name="neckCCylinder" radius="0.013" height="0.034"> > +<SimpleCapsule name="neckCapsule" radius="0.013" height="0.034"> > <Translation x="0.0" y="0.038" z="0.0"/> > <Rotation x="90.0" y="0.0" z="0.0"/> > <PhysicalAttributes> > <Mass value="0.05"/> > </PhysicalAttributes> > -</SimpleCappedCylinder> > +</SimpleCapsule> > <SimpleSphere name="neckSphere" radius="0.032"> > <Translation x="0.0" y="0.08" z="0.0"/> > <PhysicalAttributes> > @@ -27630,13 +27630,13 @@ > <Mass value="1.0"/> > </PhysicalAttributes> > </SimpleSphere> > -<SimpleCappedCylinder name="bodyCCylinder" radius="0.04" height="0.05"> > +<SimpleCapsule name="bodyCapsule" radius="0.04" height="0.05"> > <Translation x="0.0" y="-0.005" z="0.0"/> > <Rotation x="0.0" y="90.0" z="0.0"/> > <PhysicalAttributes> > <Mass value="2.5"/> > </PhysicalAttributes> > -</SimpleCappedCylinder> > +</SimpleCapsule> > <SimpleSphere name="bodySphere2" radius="0.055"> > <Translation x="0.06" y="0.004" z="0.0"/> > <PhysicalAttributes> > @@ -27764,4 +27764,4 @@ > </Elements> > </Movable> > </Macro> > -</RoSiIncludeFile> > \ No newline at end of file > +</RoSiIncludeFile> > > Modified: branches/multiphys/spark/data/ros/blockworld.ros > =================================================================== > --- branches/multiphys/spark/data/ros/blockworld.ros 2009-12-09 08:42:42 UTC (rev 117) > +++ branches/multiphys/spark/data/ros/blockworld.ros 2009-12-10 08:34:56 UTC (rev 118) > @@ -273,16 +273,16 @@ > </Box> > </Elements> > </Movable> > -<Movable name="cappedcylinder"> > +<Movable name="capsule"> > <Elements> > -<CappedCylinder name="CappedCylinder" radius="0.05" height="0.15"> > +<Capsule name="Capsule" radius="0.05" height="0.15"> > <Translation x="0.3" y="-0.5" z="0.5"/> > <Rotation x="0" y="80" z="0"/> > <Appearance ref="green"/> > <PhysicalAttributes> > <Mass value="1"/> > </PhysicalAttributes> > -</CappedCylinder> > +</Capsule> > </Elements> > </Movable> > </Elements> > > Added: branches/multiphys/spark/data/rsg/boxspheres/capsule.rsg > =================================================================== > --- branches/multiphys/spark/data/rsg/boxspheres/capsule.rsg (rev 0) > +++ branches/multiphys/spark/data/rsg/boxspheres/capsule.rsg 2009-12-10 08:34:56 UTC (rev 118) > @@ -0,0 +1,35 @@ > +; -*- mode: lisp; -*- > + > +(RSG 0 1) > +( > + (templ $radius $length $totalMass $material) > + > + (nd Capsule > + (setParams $radius $length) > + (setMaterial $material) > + ) > + > + (nd RigidBody > + (setName capsuleBody) > + ;(setCapsuleTotal $totalMass $radius $length) > + (setCapsule $totalMass $radius $length) > + ) > + > + (nd CapsuleCollider > + (setParams $radius $length) > + (nd ContactJointHandler > + (setContactBounceMode false) > + > + (setContactSlipMode true) > + (setContactSlip 0.1 0.1) > + > + (setContactSoftERPMode true) > + (setContactSoftERP 0.2) > + > + (setContactSoftCFM true) > + (setContactSoftCFM 0.01) > + ) > + ) > + ) > + > + > > Deleted: branches/multiphys/spark/data/rsg/boxspheres/ccylinder.rsg > =================================================================== > --- branches/multiphys/spark/data/rsg/boxspheres/ccylinder.rsg 2009-12-09 08:42:42 UTC (rev 117) > +++ branches/multiphys/spark/data/rsg/boxspheres/ccylinder.rsg 2009-12-10 08:34:56 UTC (rev 118) > @@ -1,35 +0,0 @@ > -; -*- mode: lisp; -*- > - > -(RSG 0 1) > -( > - (templ $radius $length $totalMass $material) > - > - (nd CCylinder > - (setParams $radius $length) > - (setMaterial $material) > - ) > - > - (nd RigidBody > - (setName ccylinderBody) > - ;(setCappedCylinderTotal $totalMass $radius $length) > - (setCappedCylinder $totalMass $radius $length) > - ) > - > - (nd CCylinderCollider > - (setParams $radius $length) > - (nd ContactJointHandler > - (setContactBounceMode false) > - > - (setContactSlipMode true) > - (setContactSlip 0.1 0.1) > - > - (setContactSoftERPMode true) > - (setContactSoftERP 0.2) > - > - (setContactSoftCFM true) > - (setContactSoftCFM 0.01) > - ) > - ) > - ) > - > - > > Modified: branches/multiphys/spark/data/rsg/boxspheres/simspark.rsg > =================================================================== > --- branches/multiphys/spark/data/rsg/boxspheres/simspark.rsg 2009-12-09 08:42:42 UTC (rev 117) > +++ branches/multiphys/spark/data/rsg/boxspheres/simspark.rsg 2009-12-10 08:34:56 UTC (rev 118) > @@ -35,15 +35,15 @@ > ) > ) > > -; add capped cylinder > +; add capsule > (nd Transform > (setLocalPos -4 0 20) > - (importScene rsg/boxspheres/ccylinder.rsg 1 3 2 matBlue) > + (importScene rsg/boxspheres/capsule.rsg 1 3 2 matBlue) > ) > > (nd Transform > (setLocalPos -6 3 20) > - (importScene rsg/boxspheres/ccylinder.rsg 1 10 2 matWhite) > + (importScene rsg/boxspheres/capsule.rsg 1 10 2 matWhite) > ) > > ; add two layer of spheres > @@ -58,4 +58,4 @@ > (importScene rsg/boxspheres/layer.rsg 1 1) > ) > > -) > \ No newline at end of file > +) > > Added: branches/multiphys/spark/data/rsg/boxspheres/staticcapsule.rsg > =================================================================== > --- branches/multiphys/spark/data/rsg/boxspheres/staticcapsule.rsg (rev 0) > +++ branches/multiphys/spark/data/rsg/boxspheres/staticcapsule.rsg 2009-12-10 08:34:56 UTC (rev 118) > @@ -0,0 +1,17 @@ > +; -*- mode: lisp; -*- > + > +(RSG 0 1) > +( > + (templ $radius $length $density $material) > + > + (nd Capsule > + (setParams $radius $length) > + (setMaterial $material) > + ) > + > + (nd CapsuleCollider > + (setParams $radius $length) > + ) > + ) > + > + > > Deleted: branches/multiphys/spark/data/rsg/boxspheres/staticccylinder.rsg > =================================================================== > --- branches/multiphys/spark/data/rsg/boxspheres/staticccylinder.rsg 2009-12-09 08:42:42 UTC (rev 117) > +++ branches/multiphys/spark/data/rsg/boxspheres/staticccylinder.rsg 2009-12-10 08:34:56 UTC (rev 118) > @@ -1,17 +0,0 @@ > -; -*- mode: lisp; -*- > - > -(RSG 0 1) > -( > - (templ $radius $length $density $material) > - > - (nd CCylinder > - (setParams $radius $length) > - (setMaterial $material) > - ) > - > - (nd CCylinderCollider > - (setParams $radius $length) > - ) > - ) > - > - > > Modified: branches/multiphys/spark/lib/kerosin/CMakeLists.txt > =================================================================== > --- branches/multiphys/spark/lib/kerosin/CMakeLists.txt 2009-12-09 08:42:42 UTC (rev 117) > +++ branches/multiphys/spark/lib/kerosin/CMakeLists.txt 2009-12-10 08:34:56 UTC (rev 118) > @@ -25,7 +25,7 @@ > sceneserver/light.h > sceneserver/sphere.h > sceneserver/box.h > - sceneserver/ccylinder.h > + sceneserver/capsule.h > sceneserver/cylinder.h > sceneserver/staticmesh.h > soundserver/soundeffect.h > @@ -90,8 +90,8 @@ > sceneserver/box_c.cpp > sceneserver/sphere.cpp > sceneserver/sphere_c.cpp > - sceneserver/ccylinder.cpp > - sceneserver/ccylinder_c.cpp > + sceneserver/capsule.cpp > + sceneserver/capsule_c.cpp > sceneserver/cylinder.cpp > sceneserver/cylinder_c.cpp > sceneserver/staticmesh.cpp > > Modified: branches/multiphys/spark/lib/kerosin/kerosin.cpp > =================================================================== > --- branches/multiphys/spark/lib/kerosin/kerosin.cpp 2009-12-09 08:42:42 UTC (rev 117) > +++ branches/multiphys/spark/lib/kerosin/kerosin.cpp 2009-12-10 08:34:56 UTC (rev 118) > @@ -58,7 +58,7 @@ > zg.GetCore()->RegisterClassObject(new CLASS(Light), "kerosin/"); > zg.GetCore()->RegisterClassObject(new CLASS(StaticMesh), "kerosin/"); > zg.GetCore()->RegisterClassObject(new CLASS(Box), "kerosin/"); > - zg.GetCore()->RegisterClassObject(new CLASS(CCylinder), "kerosin/"); > + zg.GetCore()->RegisterClassObject(new CLASS(Capsule), "kerosin/"); > zg.GetCore()->RegisterClassObject(new CLASS(Cylinder), "kerosin/"); > zg.GetCore()->RegisterClassObject(new CLASS(Sphere), "kerosin/"); > > > Modified: branches/multiphys/spark/lib/kerosin/kerosin.h > =================================================================== > --- branches/multiphys/spark/lib/kerosin/kerosin.h 2009-12-09 08:42:42 UTC (rev 117) > +++ branches/multiphys/spark/lib/kerosin/kerosin.h 2009-12-10 08:34:56 UTC (rev 118) > @@ -61,7 +61,7 @@ > #include "sceneserver/axis.h" > #include "sceneserver/light.h" > #include "sceneserver/sphere.h" > -#include "sceneserver/ccylinder.h" > +#include "sceneserver/capsule.h" > #include "sceneserver/cylinder.h" > #include "sceneserver/staticmesh.h" > > > Added: branches/multiphys/spark/lib/kerosin/sceneserver/capsule.cpp > =================================================================== > --- branches/multiphys/spark/lib/kerosin/sceneserver/capsule.cpp (rev 0) > +++ branches/multiphys/spark/lib/kerosin/sceneserver/capsule.cpp 2009-12-10 08:34:56 UTC (rev 118) > @@ -0,0 +1,65 @@ > +/* -*- mode: c++; c-basic-offset: 4; indent-tabs-mode: nil -*- > + > + this file is part of rcssserver3D > + Fri May 9 2003 > + Copyright (C) 2002,2003 Koblenz University > + Copyright (C) 2003 RoboCup Soccer Server 3D Maintenance Group > + $Id: capsule.cpp 3 2008-11-21 02:38:08Z hedayat $ > + > + This program is free software; you can redistribute it and/or modify > + it under the terms of the GNU General Public License as published by > + the Free Software Foundation; version 2 of the License. > + > + This program is distributed in the hope that it will be useful, > + but WITHOUT ANY WARRANTY; without even the implied warranty of > + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + GNU General Public License for more details. > + > + You should have received a copy of the GNU General Public License > + along with this program; if not, write to the Free Software > + Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. > +*/ > +#include "capsule.h" > +#include<kerosin/openglserver/openglserver.h> > +#include<kerosin/materialserver/material.h> > + > +using namespace boost; > +using namespace kerosin; > +using namespace zeitgeist; > +using namespace salt; > + > +Capsule::Capsule() : SingleMatNode() > +{ > +} > + > +Capsule::~Capsule() > +{ > +} > + > +void Capsule::SetParams(float radius, float length) > +{ > + ParameterList parameter; > + parameter.AddValue(radius); > + parameter.AddValue(length); > + > + Load("StdCapsule",parameter); > + > + mRadius = radius; > + mLength = length; > +} > + > +void Capsule::GetParams(float& radius, float& length) const > +{ > + radius = mRadius; > + length = mLength; > +} > + > +float Capsule::GetRadius() > +{ > + return mRadius; > +} > + > +float Capsule::GetLength() > +{ > + return mLength; > +} > > Added: branches/multiphys/spark/lib/kerosin/sceneserver/capsule.h > =================================================================== > --- branches/multiphys/spark/lib/kerosin/sceneserver/capsule.h (rev 0) > +++ branches/multiphys/spark/lib/kerosin/sceneserver/capsule.h 2009-12-10 08:34:56 UTC (rev 118) > @@ -0,0 +1,78 @@ > +/* -*- mode: c++; c-basic-offset: 4; indent-tabs-mode: nil -*- > + > + this file is part of rcssserver3D > + Fri May 9 2003 > + Copyright (C) 2002,2003 Koblenz University > + Copyright (C) 2003 RoboCup Soccer Server 3D Maintenance Group > + $Id: capsule.h 57 2009-03-18 07:26:56Z hedayat $ > + > + This program is free software; you can redistribute it and/or modify > + it under the terms of the GNU General Public License as published by > + the Free Software Foundation; version 2 of the License. > + > + This program is distributed in the hope that it will be useful, > + but WITHOUT ANY WARRANTY; without even the implied warranty of > + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + GNU General Public License for more details. > + > + You should have received a copy of the GNU General Public License > + along with this program; if not, write to the Free Software > + Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. > +*/ > +#ifndef KEROSIN_CAPSULE_H > +#define KEROSIN_CAPSULE_H > + > +#include<kerosin/kerosin_defines.h> > +#include "singlematnode.h" > + > +namespace kerosin > +{ > +class Material; > + > +/** Capsule is a SingleMatNode that creates and renders a capsule > + mesh with the given length and radius > + */ > +class KEROSIN_API Capsule : public SingleMatNode > +{ > + // > + // Function > + // > +public: > + Capsule(); > + virtual ~Capsule(); > + > + /** sets the parameters of the capsule. > + > + \param radius is the radius of the caps, and of the cylinder > + itself > + > + \param length is the height of the cylinder, not counting the > + caps > + */ > + void SetParams(float radius, float length); > + > + /** returns the parameters of the capsule */ > + void GetParams(float& radius, float& length) const; > + > + /** returns the radius of the capsule */ > + float GetRadius(); > + > + /** returns the length of the capsule */ > + float GetLength(); > + > + // > + // Members > + // > +protected: > + /** the radius of the caps and the cylinder */ > + float mRadius; > + > + /** the height of the clinder, not counting the caps */ > + float mLength; > +}; > + > +DECLARE_CLASS(Capsule); > + > +} //namespace kerosin > + > +#endif //KEROSIN_CAPSULE_H > > Added: branches/multiphys/spark/lib/kerosin/sceneserver/capsule_c.cpp > =================================================================== > --- branches/multiphys/spark/lib/kerosin/sceneserver/capsule_c.cpp (rev 0) > +++ branches/multiphys/spark/lib/kerosin/sceneserver/capsule_c.cpp 2009-12-10 08:34:56 UTC (rev 118) > @@ -0,0 +1,62 @@ > +/* -*- mode: c++; c-basic-offset: 4; indent-tabs-mode: nil -*- > + > + this file is part of rcssserver3D > + Fri May 9 2003 > + Copyright (C) 2002,2003 Koblenz University > + Copyright (C) 2003 RoboCup Soccer Server 3D Maintenance Group > + $Id: capsule_c.cpp 3 2008-11-21 02:38:08Z hedayat $ > + > + This program is free software; you can redistribute it and/or modify > + it under the terms of the GNU General Public License as published by > + the Free Software Foundation; version 2 of the License. > + > + This program is distributed in the hope that it will be useful, > + but WITHOUT ANY WARRANTY; without even the implied warranty of > + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + GNU General Public License for more details. > + > + You should have received a copy of the GNU General Public License > + along with this program; if not, write to the Free Software > + Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. > +*/ > +#include "capsule.h" > + > +using namespace boost; > +using namespace kerosin; > +using namespace salt; > + > +FUNCTION(Capsule,setParams) > +{ > + float inRadius; > + float inLength; > + > + if ( > + (in.GetSize() != 2) || > + (! in.GetValue(in[0], inRadius)) || > + (! in.GetValue(in[1], inLength)) > + ) > + { > + return false; > + } > + > + obj->SetParams(inRadius,inLength); > + return true; > +} > + > +FUNCTION(Capsule,getRadius) > +{ > + return obj->GetRadius(); > +} > + > +FUNCTION(Capsule,getLength) > +{ > + return obj->GetLength(); > +} > + > +void CLASS(Capsule)::DefineClass() > +{ > + DEFINE_BASECLASS(kerosin/SingleMatNode); > + DEFINE_FUNCTION(setParams); > + DEFINE_FUNCTION(getRadius); > + DEFINE_FUNCTION(getLength); > +} > > Deleted: branches/multiphys/spark/lib/kerosin/sceneserver/ccylinder.cpp > =================================================================== > --- branches/multiphys/spark/lib/kerosin/sceneserver/ccylinder.cpp 2009-12-09 08:42:42 UTC (rev 117) > +++ branches/multiphys/spark/lib/kerosin/sceneserver/ccylinder.cpp 2009-12-10 08:34:56 UTC (rev 118) > @@ -1,65 +0,0 @@ > -/* -*- mode: c++; c-basic-offset: 4; indent-tabs-mode: nil -*- > - > - this file is part of rcssserver3D > - Fri May 9 2003 > - Copyright (C) 2002,2003 Koblenz University > - Copyright (C) 2003 RoboCup Soccer Server 3D Maintenance Group > - $Id$ > - > - This program is free software; you can redistribute it and/or modify > - it under the terms of the GNU General Public License as published by > - the Free Software Foundation; version 2 of the License. > - > - This program is distributed in the hope that it will be useful, > - but WITHOUT ANY WARRANTY; without even the implied warranty of > - MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > - GNU General Public License for more details. > - > - You should have received a copy of the GNU General Public License > - along with this program; if not, write to the Free Software > - Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. > -*/ > -#include "ccylinder.h" > -#include<kerosin/openglserver/openglserver.h> > -#include<kerosin/materialserver/material.h> > - > -using namespace boost; > -using namespace kerosin; > -using namespace zeitgeist; > -using namespace salt; > - > -CCylinder::CCylinder() : SingleMatNode() > -{ > -} > - > -CCylinder::~CCylinder() > -{ > -} > - > -void CCylinder::SetParams(float radius, float length) > -{ > - ParameterList parameter; > - parameter.AddValue(radius); > - parameter.AddValue(length); > - > - Load("StdCCylinder",parameter); > - > - mRadius = radius; > - mLength = length; > -} > - > -void CCylinder::GetParams(float& radius, float& length) const > -{ > - radius = mRadius; > - length = mLength; > -} > - > -float CCylinder::GetRadius() > -{ > - return mRadius; > -} > - > -float CCylinder::GetLength() > -{ > - return mLength; > -} > > Deleted: branches/multiphys/spark/lib/kerosin/sceneserver/ccylinder.h > =================================================================== > --- branches/multiphys/spark/lib/kerosin/sceneserver/ccylinder.h 2009-12-09 08:42:42 UTC (rev 117) > +++ branches/multiphys/spark/lib/kerosin/sceneserver/ccylinder.h 2009-12-10 08:34:56 UTC (rev 118) > @@ -1,78 +0,0 @@ > -/* -*- mode: c++; c-basic-offset: 4; indent-tabs-mode: nil -*- > - > - this file is part of rcssserver3D > - Fri May 9 2003 > - Copyright (C) 2002,2003 Koblenz University > - Copyright (C) 2003 RoboCup Soccer Server 3D Maintenance Group > - $Id$ > - > - This program is free software; you can redistribute it and/or modify > - it under the terms of the GNU General Public License as published by > - the Free Software Foundation; version 2 of the License. > - > - This program is distributed in the hope that it will be useful, > - but WITHOUT ANY WARRANTY; without even the implied warranty of > - MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > - GNU General Public License for more details. > - > - You should have received a copy of the GNU General Public License > - along with this program; if not, write to the Free Software > - Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. > -*/ > -#ifndef KEROSIN_CCYLINDER_H > -#define KEROSIN_CCYLINDER_H > - > -#include<kerosin/kerosin_defines.h> > -#include "singlematnode.h" > - > -namespace kerosin > -{ > -class Material; > - > -/** CCylinder is a SingleMatNode that creates and renders a capped > - cylinder mesh with the given length and radius > - */ > -class KEROSIN_API CCylinder : public SingleMatNode > -{ > - // > - // Function > - // > -public: > - CCylinder(); > - virtual ~CCylinder(); > - > - /** sets the parameters of the capped cylinder. > - > - \param radius is the radius of the caps, and of the cylinder > - itself > - > - \param length is the height of the cylinder, not counting the > - caps > - */ > - void SetParams(float radius, float length); > - > - /** returns the parameters of the capped cylinder */ > - void GetParams(float& radius, float& length) const; > - > - /** returns the radius of the capped cylinder */ > - float GetRadius(); > - > - /** returns the length of the capped cylinder */ > - float GetLength(); > - > - // > - // Members > - // > -protected: > - /** the radius of the caps and the cylinder */ > - float mRadius; > - > - /** the height of the clinder, not counting the caps */ > - float mLength; > -}; > - > -DECLARE_CLASS(CCylinder); > - > -} //namespace kerosin > - > -#endif //KEROSIN_CCYLINDER_H > > Deleted: branches/multiphys/spark/lib/kerosin/sceneserver/ccylinder_c.cpp > =================================================================== > --- branches/multiphys/spark/lib/kerosin/sceneserver/ccylinder_c.cpp 2009-12-09 08:42:42 UTC (rev 117) > +++ branches/multiphys/spark/lib/kerosin/sceneserver/ccylinder_c.cpp 2009-12-10 08:34:56 UTC (rev 118) > @@ -1,62 +0,0 @@ > -/* -*- mode: c++; c-basic-offset: 4; indent-tabs-mode: nil -*- > - > - this file is part of rcssserver3D > - Fri May 9 2003 > - Copyright (C) 2002,2003 Koblenz University > - Copyright (C) 2003 RoboCup Soccer Server 3D Maintenance Group > - $Id$ > - > - This program is free software; you can redistribute it and/or modify > - it under the terms of the GNU General Public License as published by > - the Free Software Foundation; version 2 of the License. > - > - This program is distributed in the hope that it will be useful, > - but WITHOUT ANY WARRANTY; without even the implied warranty of > - MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > - GNU General Public License for more details. > - > - You should have received a copy of the GNU General Public License > - along with this program; if not, write to the Free Software > - Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. > -*/ > -#include "ccylinder.h" > - > -using namespace boost; > -using namespace kerosin; > -using namespace salt; > - > -FUNCTION(CCylinder,setParams) > -{ > - float inRadius; > - float inLength; > - > - if ( > - (in.GetSize() != 2) || > - (! in.GetValue(in[0], inRadius)) || > - (! in.GetValue(in[1], inLength)) > - ) > - { > - return false; > - } > - > - obj->SetParams(inRadius,inLength); > - return true; > -} > - > -FUNCTION(CCylinder,getRadius) > -{ > - return obj->GetRadius(); > -} > - > -FUNCTION(CCylinder,getLength) > -{ > - return obj->GetLength(); > -} > - > -void CLASS(CCylinder)::DefineClass() > -{ > - DEFINE_BASECLASS(kerosin/SingleMatNode); > - DEFINE_FUNCTION(setParams); > - DEFINE_FUNCTION(getRadius); > - DEFINE_FUNCTION(getLength); > -} > > Modified: branches/multiphys/spark/lib/oxygen/CMakeLists.txt > =================================================================== > --- branches/multiphys/spark/lib/oxygen/CMakeLists.txt 2009-12-09 08:42:42 UTC (rev 117) > +++ branches/multiphys/spark/lib/oxygen/CMakeLists.txt 2009-12-10 08:34:56 UTC (rev 118) > @@ -14,6 +14,7 @@ > gamecontrolserver/behavior.h > oxygen.h > oxygen_defines.h > + physicsserver/genericphysicsobject.h > physicsserver/physicsobject.h > physicsserver/body.h > physicsserver/rigidbody.h > @@ -56,9 +57,11 @@ > #interfaces > physicsserver/int/bodyint.h > physicsserver/int/boxcolliderint.h > + physicsserver/int/capsulecolliderint.h > physicsserver/int/colliderint.h > physicsserver/int/compoundcolliderint.h > physicsserver/int/concavecolliderint.h > + physicsserver/int/conecolliderint.h > physicsserver/int/convexcolliderint.h > physicsserver/int/cylindercolliderint.h > physicsserver/int/dynamicbodyint.h > @@ -76,9 +79,11 @@ > physicsserver/ode/odebody.h > physicsserver/ode/odeboxcollider.h > physicsserver/ode/odedynamicbody.h > + physicsserver/ode/odecapsulecollider.h > physicsserver/ode/odecollider.h > physicsserver/ode/odecompoundcollider.h > physicsserver/ode/odeconcavecollider.h > + physicsserver/ode/odeconecollider.h > physicsserver/ode/odeconvexcollider.h > physicsserver/ode/odecylindercollider.h > physicsserver/ode/odeemptycollider.h > @@ -177,6 +182,7 @@ > physicsserver/compoundcollider_c.cpp > physicsserver/concavecollider.cpp > physicsserver/concavecollider_c.cpp > + physicsserver/conecollider.cpp > physicsserver/conecollider_c.cpp > physicsserver/convexcollider.cpp > physicsserver/convexcollider_c.cpp > @@ -228,9 +234,11 @@ > #ODE-specific files > physicsserver/ode/odebody.cpp > physicsserver/ode/odeboxcollider.cpp > + physicsserver/ode/odecapsulecollider.cpp > physicsserver/ode/odecollider.cpp > physicsserver/ode/odecompoundcollider.cpp > physicsserver/ode/odeconcavecollider.cpp > + physicsserver/ode/odeconecollider.cpp > physicsserver/ode/odeconvexcollider.cpp > physicsserver/ode/odecylindercollider.cpp > physicsserver/ode/odedynamicbody.cpp > > Modified: branches/multiphys/spark/lib/oxygen/geometryserver/stdmeshimporter.cpp > =================================================================== > --- branches/multiphys/spark/lib/oxygen/geometryserver/stdmeshimporter.cpp 2009-12-09 08:42:42 UTC (rev 117) > +++ branches/multiphys/spark/lib/oxygen/geometryserver/stdmeshimporter.cpp 2009-12-10 08:34:56 UTC (rev 118) > @@ -40,7 +40,7 @@ > > static const string gSphereStr = "StdUnitSphere"; > static const string gBoxStr = "StdUnitBox"; > -static const string gCCylinderStr = "StdCCylinder"; > +static const string gCapsuleStr = "StdCapsule"; > static const string gCylinderStr = "StdUnitCylinder"; > > shared_ptr<TriMesh> > @@ -56,9 +56,9 @@ > return UnitBoxMesh(); > } > > - if (name == gCCylinderStr) > + if (name == gCapsuleStr) > { > - return UnitCCylinder(parameter); > + return UnitCapsule(parameter); > } > > if (name == gCylinderStr) > @@ -253,7 +253,7 @@ > } > > // > -// unit capped cylinder > +// unit capsule > // > static void AddVertex(float** at, float x, float y, float z) > { > @@ -265,7 +265,7 @@ > std::string StdMeshImporter::MangleName (const string& name, const ParameterList& parameter) > { > if ( > - (name != gCCylinderStr) || > + (name != gCapsuleStr) || > (parameter.GetSize()< 2) > ) > { > @@ -273,7 +273,7 @@ > } > > stringstream ss; > - ss<< gCCylinderStr; > + ss<< gCapsuleStr; > > float radius; > if (parameter.GetValue(parameter[0],radius)) > @@ -290,18 +290,18 @@ > return ss.str(); > } > > -shared_ptr<TriMesh> StdMeshImporter::UnitCCylinder(const ParameterList& parameter) > +shared_ptr<TriMesh> StdMeshImporter::UnitCapsule(const ParameterList& parameter) > { > // > // code adapted from ODE's drawstuff lib > // > > - // generated capped clinder with r=1 and l=1 > + // generated capsule with r=1 and l=1 > float ccRadius = 1; > float ccLength = 1; > > GetLog()->Debug() > -<< "(StdMeshImporter::UnitCCylinder) paramSize=" > +<< "(StdMeshImporter::UnitCapsule) paramSize=" > << parameter.GetSize()<< "\n"; > if (parameter.GetSize()>= 2) > { > @@ -310,8 +310,8 @@ > } > > // number of sides to the cylinder (divisible by 4): > - const int capped_cylinder_quality = 3; > - const int n = capped_cylinder_quality*4; > + const int capsule_quality = 3; > + const int n = capsule_quality*4; > > int innerLoop = (n+1); > int numVertices = innerLoop * 2; > @@ -447,7 +447,7 @@ > mesh->SetPos(pos,numVertices); > mesh->SetNormals(normals); > mesh->AddFace(idx); > - mesh->SetName(MangleName(gCCylinderStr,parameter)); > + mesh->SetName(MangleName(gCapsuleStr,parameter)); > > return mesh; > } > > Modified: branches/multiphys/spark/lib/oxygen/geometryserver/stdmeshimporter.h > =================================================================== > --- branches/multiphys/spark/lib/oxygen/geometryserver/stdmeshimporter.h 2009-12-09 08:42:42 UTC (rev 117) > +++ branches/multiphys/spark/lib/oxygen/geometryserver/stdmeshimporter.h 2009-12-10 08:34:56 UTC (rev 118) > @@ -28,7 +28,7 @@ > namespace oxygen > { > /** \class StdMeshImporter is a MeshImporter that generates a standard > - set of meshes. These are spheres, boxes and capped cylinders. > + set of meshes. These are spheres, boxes and capsule. > */ > class OXYGEN_API StdMeshImporter : public MeshImporter > { > @@ -41,7 +41,7 @@ > virtual boost::shared_ptr<TriMesh> ImportMesh > (const std::string& name,const zeitgeist::ParameterList& parameter); > > - /** returns a unique name for each parameterized capped cylinder > + /** returns a unique name for each parameterized capsule > mesh, and \param name otherwise > */ > virtual std::string MangleName > @@ -54,8 +54,8 @@ > /** constructs a unit box */ > boost::shared_ptr<TriMesh> UnitBoxMesh(); > > - /** constructs a unit capped cylinder */ > - boost::shared_ptr<TriMesh> UnitCCylinder > + /** constructs a unit capsule */ > + boost::shared_ptr<TriMesh> UnitCapsule > (const zeitgeist::ParameterList& parameter); > > /** constructs a flat unit cylinder */ > > Modified: branches/multiphys/spark/lib/oxygen/physicsserver/capsulecollider.cpp > =================================================================== > --- branches/multiphys/spark/lib/oxygen/physicsserver/capsulecollider.cpp 2009-12-09 08:42:42 UTC (rev 117) > +++ branches/multiphys/spark/lib/oxygen/physicsserver/capsulecollider.cpp 2009-12-10 08:34:56 UTC (rev 118) > @@ -3,7 +3,7 @@ > this file is part of rcssserver3D > Fri May 9 2003 > Copyright (C) 2003 Koblenz University > - $Id: ccylindercollider.cpp 108 2009-11-25 10:20:10Z a-held $ > + $Id: capsulecollider.cpp 108 2009-11-25 10:20:10Z a-held $ > > This program is free software; you can redistribute it and/or modify > it under the terms of the GNU General Public License as published by > @@ -20,51 +20,44 @@ > */ > > #include<oxygen/physicsserver/capsulecollider.h> > +#include<oxygen... [truncated message content] |
|
From: Hedayat V. <hed...@ai...> - 2009-12-07 19:23:23
|
Hi, On ۰۹/۱۲/۰۳ 12:25, ah...@un... wrote: > Hi, > > > As you can see onhttp://sourceforge.net/projects/simspark/ I'm diligently > working on the APL right now. Yes, great! Thanks. > The bridge pattern seems to be the final > solution to all the problems I had before. It's still an incredibly big > task and very challenging at times, but I keep learning more and more > about both simspark and C++ as I keep working, and I think I've reached > the point where I finally enjoy working on the project and overcoming the > challenges it proposes. > Nice to hear that :) > However, I can't promise that I will actually get to implementing Bullet > before the deadline. Since the design of the APL has taken so long and the > project has proven to be far more complex than anybody expected, I changed > my goal to at least get the APL done (i.e. unless avoiding this is > completely impossible, no class that is not prefixed with "ODE..." > includes the odewrapper anymore). That should already be a great help for > anyone who wants to include Bullet, or PhysX, though. > Yes, certainly. > One thing that I stumbled across are the return types and method > parameters. Since the abstract classes need to be engine-independent, I > need to do something about methods like "dBodyID GetODEBody()" since > dBodyID is defined inside of ODE. This is pretty easy, as I can just > change it to something like "long GetBodyID()". A dBodyID _is_ a long, > just with a different name, so the implementation can internally cast the > dBodyID to a long before passing it on to the abstract layer. The class > that called the method can then internally cast it back to a dBodyID and > then work as usual. I think this is pretty clean, and it works flawlessly. > Yes, as long as the types used by different engines are compatible it is fine. > This gets a little more tricky when you have pointers to ODE-specific > types (which I think is only the case once, anyway). Since a pointer is > just a memory address, the callee can cast to a void*, pass it on to the > abstract layer, and the caller then casts it back to whatever type it > expects and work with it. It still points to the same adress, so no harm > is done. > Yes. I suggest to define an appropriate typedefs for different engine specific types so that you use something more meaningful than void* (e.g. typedef void *GenericColliderPtr). > However, I have not found a clean solution for references yet, and > references are used quite often. The solution would be to change it to a > neutral type, use that neutral type in the abstract layer and then change > it back to what is needed, and I can say that this works. I tested it with > a method that got a dMatrix3& as a parameter (i.e. I changed it to a > neutral type and internally changed it back to a dMatrix3&), and I know > exactly what would have happened if this method had malfunctioned. > However, C++ forbids a void&. So I cast to an int&. > Let me emphasize. The Collider class, at one points, needs to call > PhysicsObject::ConvertRotationMatrix. CRM expects a dMatrix3& as a > parameter. This has to be avoided because PhysicsObject needs to be > engine-independent and a dMatrix3 is an ODE type. So, I let Collider cast > to an the dMatrix3& to an int&, call CRM with that reference, > PhysicsObject delegates it to ODEPhysicsObject, and ODEPO casts the int& > back to a dMatrix3&. This works. > I realise, however, that this is nothing more than a dirty workaround. Do > you know a better way to encapsulate a reference in an independent type > and then retrieve the encapsulated reference? If not, is this workaround > acceptable at all, or does it discredit all of my other work? :D > There are different solutions for this problem. One of them is like this: define a PhysicsMatrix class. Then for each engine, derive a class from PhysicsMatrix class. For example, we could have a ODEMatrix class derived from PhysicsMatrix class. Now, this class could either have a member of type dMatrix3 inside it, or being derived from dMatrix3 too (it is even possible to put a dMatrix3& member inside the class which is initialized in the constructor). Boost library also provides many classes which might be helpful in these situations, but I'm not sure if they are really convenient here. Keep up the good work, Thanks Hedayat > > thanks, > > Andreas > > |
|
From: <ah...@un...> - 2009-12-03 08:55:59
|
Hi, As you can see on http://sourceforge.net/projects/simspark/ I'm diligently working on the APL right now. The bridge pattern seems to be the final solution to all the problems I had before. It's still an incredibly big task and very challenging at times, but I keep learning more and more about both simspark and C++ as I keep working, and I think I've reached the point where I finally enjoy working on the project and overcoming the challenges it proposes. However, I can't promise that I will actually get to implementing Bullet before the deadline. Since the design of the APL has taken so long and the project has proven to be far more complex than anybody expected, I changed my goal to at least get the APL done (i.e. unless avoiding this is completely impossible, no class that is not prefixed with "ODE..." includes the odewrapper anymore). That should already be a great help for anyone who wants to include Bullet, or PhysX, though. One thing that I stumbled across are the return types and method parameters. Since the abstract classes need to be engine-independent, I need to do something about methods like "dBodyID GetODEBody()" since dBodyID is defined inside of ODE. This is pretty easy, as I can just change it to something like "long GetBodyID()". A dBodyID _is_ a long, just with a different name, so the implementation can internally cast the dBodyID to a long before passing it on to the abstract layer. The class that called the method can then internally cast it back to a dBodyID and then work as usual. I think this is pretty clean, and it works flawlessly. This gets a little more tricky when you have pointers to ODE-specific types (which I think is only the case once, anyway). Since a pointer is just a memory address, the callee can cast to a void*, pass it on to the abstract layer, and the caller then casts it back to whatever type it expects and work with it. It still points to the same adress, so no harm is done. However, I have not found a clean solution for references yet, and references are used quite often. The solution would be to change it to a neutral type, use that neutral type in the abstract layer and then change it back to what is needed, and I can say that this works. I tested it with a method that got a dMatrix3& as a parameter (i.e. I changed it to a neutral type and internally changed it back to a dMatrix3&), and I know exactly what would have happened if this method had malfunctioned. However, C++ forbids a void&. So I cast to an int&. Let me emphasize. The Collider class, at one points, needs to call PhysicsObject::ConvertRotationMatrix. CRM expects a dMatrix3& as a parameter. This has to be avoided because PhysicsObject needs to be engine-independent and a dMatrix3 is an ODE type. So, I let Collider cast to an the dMatrix3& to an int&, call CRM with that reference, PhysicsObject delegates it to ODEPhysicsObject, and ODEPO casts the int& back to a dMatrix3&. This works. I realise, however, that this is nothing more than a dirty workaround. Do you know a better way to encapsulate a reference in an independent type and then retrieve the encapsulated reference? If not, is this workaround acceptable at all, or does it discredit all of my other work? :D thanks, Andreas |
|
From: Yuan Xu <xuy...@gm...> - 2009-11-28 21:39:11
|
Hey guys! It's great that you guys discuss about timer (and you great work!) In my opinion, it is 'fair' in any case, since all the teams use the same server ;-P But, the annoying thing is that hardware affects the simulation results a lot. ( currently, our simulation is just slow, maybe one day it is faster than real time ;) ) So, the solution may be not a complex timer to control the computation time of agent. I agree with that giving up real time simulation, then the agent may get more computation time, but I think it is ok. And also the proxy idea is also cool, it will make team development much easier: teams ( especially new teams) will not spend a lot of work on a complex communication mechanism, which is not belongs to AI. PS: the accelerometer is missing in our simulation, I think it will be nice to have it, and I already do something about this. What is your opinion? 2009/11/27 Sander van Dijk <sgv...@gm...>: > Hi, > > I think Hedayat's proposal is a step in the right direction to make things > more fair. By placing the timing on the client computer it overcomes > problems that may be caused by networking (an important feature that Spades > had) and it indeed shouldn't be too much work to implement. > > However, even though this solves networking issues and makes thinks about as > fair as possible in a single game with homogeneous client computer setups, > it does not solve the problems of reproducibility and being able to prepare > well on different systems when we use fixed real time time steps. I have > thought about it more since my first email and think now that what is > desirable is to (roughly) define the think time in cpu > cycles/instructions/floating-point operations. Only that way agents get > similar restrictions/possibilities when run on different machines. The point > I made earlier about disadvantaging for instance Java implementations is > invalid, since on real robots such implementations will have a disadvantage > too. Also, when limiting based on real time they will still have this > disadvantage. > > There are two ways to limit by processing time (that I can think of): > - Make the server keep an eye on this. This is what Spades did, however some > people (and my unreliable memory) say that this had problems, either because > it wasn't accurate enough, or just plain buggy. And, like mentioned earlier, > this may not work well in multi core setups (more on this later). Does > anybody know more details of this, or knows of an accurate way to check and > limit cpu usage? > - Determine a formula that gives a value for the real time step size given > details of the setup, which can be implemented in the server, or given as a > guideline. > > I think for now the second option is the easiest and my suggestion would be: > > t = N * Cs * A / (Cr * I) > > Where N is the number of instructions we want to give an agent, Cs the > number of simulated cores, A the number of agents run simultaniously on a > single machine, Cr the number of real available cores and I the the number > of instructions per second each real core can do. This still isn't perfect, > if the amount of simulated cores is lower than the real number, agents using > more threads than simulated cores still have an advantage, but this could > maybe be overcome by restricting each agent to be able to use no more than > the simulated amount of cores (it's CPU affinity. On Linux this can be set > with schedtool). > > Regards, > Sander > > On Fri, Nov 27, 2009 at 6:44 PM, Hedayat Vatankhah <hed...@ai...> > wrote: >> >> Hi, >> >> On ۰۹/۱۱/۲۷ 08:19, Mahdi wrote: >> >> Hi Hedayat >> >> � In my opinion, this may be good way of implementing a timer. But can you >> provide more detail on your proposal? Since there are some points which >> shall be calrified before implementing any timer solutions. There are things >> which shall be considered in mind, like: >> >> � * How and When agents are informed of a new cycles and data associated >> with each cycle? >> � * How and When agents shall send their commands to the proxy? >> >> Why this should be different from the current situation? I was thinking >> about the same way as now. Agents can receive data from sensors in each >> cycle, and they should their commands before the end of the cycle (about >> 0.02 seconds from the time they receive senses). (BTW, this model fits well >> with the Player integration goal; and when done agents will communicate with >> sensors/actuators in the Player way). >> >> � * How will the proxy behave if a team responds after specified time for >> a cycle? >> >> The received commands will be sent to the server in the next cycle. >> >> ��� - Will proxy announce a player dead after several cycles >> ��� - Or will it just send the actions of agent in the next cycle? >> >> � I think any proposal shall answer these question besides describing it's >> scheme of communication between agents and simulator. >> >> What is in my mind is that with the current protocol, players should >> communicate with the proxy in the same way as they communicate with the >> simulator now. So there is no need to modify agents' code. When integrated >> with Player, agents will communicate with the server using that method. >> >> Good luck, >> Hedayat >> >> >> Best Regards >> Mahdi >> >> >> ------------------------------------------------------------------------------ >> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 >> 30-Day >> trial. Simplify your report design, integration and deployment - and focus >> on >> what you do best, core application coding. Discover what's new with >> Crystal Reports now. http://p.sf.net/sfu/bobj-july >> >> >> _______________________________________________ >> Simspark Generic Physical MAS Simulator >> simspark-devel mailing list >> sim...@li... >> https://lists.sourceforge.net/lists/listinfo/simspark-devel >> >> >> >> ------------------------------------------------------------------------------ >> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 >> 30-Day >> trial. Simplify your report design, integration and deployment - and focus >> on >> what you do best, core application coding. Discover what's new with >> Crystal Reports now. http://p.sf.net/sfu/bobj-july >> _______________________________________________ >> 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 > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus > on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Simspark Generic Physical MAS Simulator > simspark-devel mailing list > sim...@li... > https://lists.sourceforge.net/lists/listinfo/simspark-devel > > -- King Regards, Xu, Yuan |
|
From: Hedayat V. <hed...@ai...> - 2009-11-28 21:33:01
|
Hi, On ۰۹/۱۱/۲۷ 11:41, Sander van Dijk wrote: > Hi, > > I think Hedayat's proposal is a step in the right direction to make > things more fair. By placing the timing on the client computer it > overcomes problems that may be caused by networking (an important > feature that Spades had) and it indeed shouldn't be too much work to > implement. > > However, even though this solves networking issues and makes thinks > about as fair as possible in a single game with homogeneous client > computer setups, it does not solve the problems of reproducibility and > being able to prepare well on different systems when we use fixed real > time time steps. I have thought about it more since my first email and > think now that what is desirable is to (roughly) define the think time > in cpu cycles/instructions/floating-point operations. Only that way > agents get similar restrictions/possibilities when run on different > machines. The point I made earlier about disadvantaging for instance > Java implementations is invalid, since on real robots such > implementations will have a disadvantage too. Also, when limiting > based on real time they will still have this disadvantage. Using that approach, teams can prepare well if their systems is not more powerful than the competition's systems. Whatever works on slower clients should work the same on faster clients since they will have more thinking time on faster clients per cycle. So, anything achieved in slow clients can be reproduced on faster clients. The only remaining problems is that of teams which use clients faster than the competitions clients, and also that teams with slower clients will have less time for thinking on their systems, and so they won't use the full power of competition clients. And personally, I think what an agent MUST do in one cycle is low level control of its joints and some reactive behavior in this area, which should not need much time (such control should usually happen as fast as possible). All other higher level thinking could span several cycles since applying most of such decisions takes several cycles (consider when an agent decides to stop walking). BTW, I have a suggestion which is given below. > > There are two ways to limit by processing time (that I can think of): > - Make the server keep an eye on this. This is what Spades did, > however some people (and my unreliable memory) say that this had > problems, either because it wasn't accurate enough, or just plain > buggy. And, like mentioned earlier, this may not work well in multi > core setups (more on this later). Does anybody know more details of > this, or knows of an accurate way to check and limit cpu usage? > - Determine a formula that gives a value for the real time step size > given details of the setup, which can be implemented in the server, or > given as a guideline. > > I think for now the second option is the easiest and my suggestion > would be: > > t = N * Cs * A / (Cr * I) > > Where N is the number of instructions we want to give an agent, Cs the > number of simulated cores, A the number of agents run simultaniously > on a single machine, Cr the number of real available cores and I the > the number of instructions per second each real core can do. This > still isn't perfect, if the amount of simulated cores is lower than > the real number, agents using more threads than simulated cores still > have an advantage, but this could maybe be overcome by restricting > each agent to be able to use no more than the simulated amount of > cores (it's CPU affinity. On Linux this can be set with schedtool). What do you think about this: we can define a simple benchmark which can be used on client systems to determine how much a cycle should last on the client machine. The client proxy will use this value as the time of one cycle. For example: cycle time = (time of running f *= 1.1 for N times)/10 Where N is a parameter defined based on the performance of a reference platform. We can have a small tool to measure and set the appropriate cycle time on clients. How is this? Thanks, Hedayat > > Regards, > Sander > > On Fri, Nov 27, 2009 at 6:44 PM, Hedayat Vatankhah <hed...@ai... > <mailto:hed...@ai...>> wrote: > > Hi, > > > On ۰۹/۱۱/۲۷ 08:19, Mahdi wrote: >> Hi Hedayat >> >> � In my opinion, this may be good way of implementing a timer. >> But can you provide more detail on your proposal? Since there are >> some points which shall be calrified before implementing any >> timer solutions. There are things which shall be considered in >> mind, like: >> >> � * How and When agents are informed of a new cycles and data >> associated with each cycle? >> � * How and When agents shall send their commands to the proxy? > Why this should be different from the current situation? I was > thinking about the same way as now. Agents can receive data from > sensors in each cycle, and they should their commands before the > end of the cycle (about 0.02 seconds from the time they receive > senses). (BTW, this model fits well with the Player integration > goal; and when done agents will communicate with sensors/actuators > in the Player way). > >> � * How will the proxy behave if a team responds after specified >> time for a cycle? > The received commands will be sent to the server in the next cycle. > > >> ��� - Will proxy announce a player dead after several cycles >> ��� - Or will it just send the actions of agent in the next cycle? >> >> � I think any proposal shall answer these question besides >> describing it's scheme of communication between agents and simulator. > What is in my mind is that with the current protocol, players > should communicate with the proxy in the same way as they > communicate with the simulator now. So there is no need to modify > agents' code. When integrated with Player, agents will communicate > with the server using that method. > > Good luck, > Hedayat > >> >> Best Regards >> Mahdi >> >> >> ------------------------------------------------------------------------------ >> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day >> trial. Simplify your report design, integration and deployment - and focus on >> what you do best, core application coding. Discover what's new with >> Crystal Reports now.http://p.sf.net/sfu/bobj-july >> >> >> _______________________________________________ Simspark Generic >> Physical MAS Simulator simspark-devel mailing list >> sim...@li... >> <mailto:sim...@li...> >> https://lists.sourceforge.net/lists/listinfo/simspark-devel > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports > 2008 30-Day > trial. Simplify your report design, integration and deployment - > and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Simspark Generic Physical MAS Simulator > simspark-devel mailing list > sim...@li... > <mailto:sim...@li...> > https://lists.sourceforge.net/lists/listinfo/simspark-devel > > > > > -- > Adaptive Systems Research Group > Department of Computer Science > University of Hertfordshire > United Kingdom |
|
From: Sander v. D. <sgv...@gm...> - 2009-11-27 20:12:09
|
Hi, I think Hedayat's proposal is a step in the right direction to make things more fair. By placing the timing on the client computer it overcomes problems that may be caused by networking (an important feature that Spades had) and it indeed shouldn't be too much work to implement. However, even though this solves networking issues and makes thinks about as fair as possible in a single game with homogeneous client computer setups, it does not solve the problems of reproducibility and being able to prepare well on different systems when we use fixed real time time steps. I have thought about it more since my first email and think now that what is desirable is to (roughly) define the think time in cpu cycles/instructions/floating-point operations. Only that way agents get similar restrictions/possibilities when run on different machines. The point I made earlier about disadvantaging for instance Java implementations is invalid, since on real robots such implementations will have a disadvantage too. Also, when limiting based on real time they will still have this disadvantage. There are two ways to limit by processing time (that I can think of): - Make the server keep an eye on this. This is what Spades did, however some people (and my unreliable memory) say that this had problems, either because it wasn't accurate enough, or just plain buggy. And, like mentioned earlier, this may not work well in multi core setups (more on this later). Does anybody know more details of this, or knows of an accurate way to check and limit cpu usage? - Determine a formula that gives a value for the real time step size given details of the setup, which can be implemented in the server, or given as a guideline. I think for now the second option is the easiest and my suggestion would be: t = N * Cs * A / (Cr * I) Where N is the number of instructions we want to give an agent, Cs the number of simulated cores, A the number of agents run simultaniously on a single machine, Cr the number of real available cores and I the the number of instructions per second each real core can do. This still isn't perfect, if the amount of simulated cores is lower than the real number, agents using more threads than simulated cores still have an advantage, but this could maybe be overcome by restricting each agent to be able to use no more than the simulated amount of cores (it's CPU affinity. On Linux this can be set with schedtool). Regards, Sander On Fri, Nov 27, 2009 at 6:44 PM, Hedayat Vatankhah <hed...@ai...>wrote: > Hi, > > > On ۰۹/۱۱/۲۷ 08:19, Mahdi wrote: > > Hi Hedayat > > � In my opinion, this may be good way of implementing a timer. But can you > provide more detail on your proposal? Since there are some points which > shall be calrified before implementing any timer solutions. There are things > which shall be considered in mind, like: > > � * How and When agents are informed of a new cycles and data associated > with each cycle? > � * How and When agents shall send their commands to the proxy? > > Why this should be different from the current situation? I was thinking > about the same way as now. Agents can receive data from sensors in each > cycle, and they should their commands before the end of the cycle (about > 0.02 seconds from the time they receive senses). (BTW, this model fits well > with the Player integration goal; and when done agents will communicate with > sensors/actuators in the Player way). > > � * How will the proxy behave if a team responds after specified time for a > cycle? > > The received commands will be sent to the server in the next cycle. > > > ��� - Will proxy announce a player dead after several cycles > ��� - Or will it just send the actions of agent in the next cycle? > > � I think any proposal shall answer these question besides describing it's > scheme of communication between agents and simulator. > > What is in my mind is that with the current protocol, players should > communicate with the proxy in the same way as they communicate with the > simulator now. So there is no need to modify agents' code. When integrated > with Player, agents will communicate with the server using that method. > > Good luck, > Hedayat > > > Best Regards > Mahdi > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > > > _______________________________________________ > Simspark Generic Physical MAS Simulator > simspark-devel mailing list > sim...@li... > https://lists.sourceforge.net/lists/listinfo/simspark-devel > > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus > on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > 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: Hedayat V. <hed...@ai...> - 2009-11-27 18:56:37
|
<!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,<br> <br> On ۰۹/۱۱/۲۷ 08:19, Mahdi wrote: <blockquote cite="mid:fca...@ma..." type="cite">Hi Hedayat<br> <br> � In my opinion, this may be good way of implementing a timer. But can you provide more detail on your proposal? Since there are some points which shall be calrified before implementing any timer solutions. There are things which shall be considered in mind, like:<br> <br> � * How and When agents are informed of a new cycles and data associated with each cycle?<br> � * How and When agents shall send their commands to the proxy?<br> </blockquote> Why this should be different from the current situation? I was thinking about the same way as now. Agents can receive data from sensors in each cycle, and they should their commands before the end of the cycle (about 0.02 seconds from the time they receive senses). (BTW, this model fits well with the Player integration goal; and when done agents will communicate with sensors/actuators in the Player way).<br> <br> <blockquote cite="mid:fca...@ma..." type="cite">� * How will the proxy behave if a team responds after specified time for a cycle?<br> </blockquote> The received commands will be sent to the server in the next cycle.<br> <br> <blockquote cite="mid:fca...@ma..." type="cite">��� - Will proxy announce a player dead after several cycles<br> ��� - Or will it just send the actions of agent in the next cycle?<br> <br> � I think any proposal shall answer these question besides describing it's scheme of communication between agents and simulator.<br> </blockquote> What is in my mind is that with the current protocol, players should communicate with the proxy in the same way as they communicate with the simulator now. So there is no need to modify agents' code. When integrated with Player, agents will communicate with the server using that method. <br> <br> Good luck,<br> Hedayat<br> <br> <blockquote cite="mid:fca...@ma..." type="cite"><br> Best Regards<br> Mahdi<br> <pre wrap=""> <fieldset class="mimeAttachmentHeader"></fieldset> ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. <a class="moz-txt-link-freetext" href="http://p.sf.net/sfu/bobj-july">http://p.sf.net/sfu/bobj-july</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: Mahdi <zig...@gm...> - 2009-11-27 16:49:40
|
Hi Hedayat
In my opinion, this may be good way of implementing a timer. But can you
provide more detail on your proposal? Since there are some points which
shall be calrified before implementing any timer solutions. There are things
which shall be considered in mind, like:
* How and When agents are informed of a new cycles and data associated
with each cycle?
* How and When agents shall send their commands to the proxy?
* How will the proxy behave if a team responds after specified time for a
cycle?
- Will proxy announce a player dead after several cycles
- Or will it just send the actions of agent in the next cycle?
I think any proposal shall answer these question besides describing it's
scheme of communication between agents and simulator.
Best Regards
Mahdi
|
|
From: Hedayat V. <hed...@ai...> - 2009-11-27 15:44:34
|
Hi all,
On ۰۹/۱۱/۲۷ 01:45, Feng Xue wrote:
> Hi Sander, Khashayar and Hedayat,
> First of all, I am sorry that I have been acting silence since last
> year and didn't have a team for Graz. But I read every email that sent
> to these two mail lists, especially devel ML. So, I know what things
> are going on here, at least most of them.
:) Happy to hear that.
> With regard to the timer, it's an old topic, but important.
> At the first three years(2004, 2005, 2006), simulation 3D
> league was mainly focusing on strategy making, multi-agent systems,
> collaboration, etc. At the year of 2007, we made a big step to
> humanoid robot which is exciting and longsighted in my opinion.
> However, because of the hardware limitation "or" timing issues, we
> could only run a 2vs2 game. The consequence of this big step is that
> the topic of motion planning and path planning are mainly
> concerned. In another word, the research topics are somewhat
> restricted. However, the first thing to do for RoboCup2008 was solving
> the issues like unstable physics module, unrealistic robot model, etc.
> Well, what is the exact improvement of RoboCup2009 that is benefit
> for our research? Comparied to RoboCup2008, they have the same robot
> model, the same player numbers. Even in ChinaOpen2008(Dec. 2008), it's
> a 4 vs 4 game and had showed the importance of strategy making.
> Back to the timer issue, the current so-called sync solution
> will work, but in a short period. As Sander mentioned in the previous
> email, infinite available thinking time, uncontrollable noise casued
> by the differences of hardware and network delay, etc.
> The gentleman rule has appeared in the 3d rules for these three
> years. It is ridiculous especially when there is no effective
> supervise mechanism. Very long messages, debug tcp or even fast joints
> speed will cost the server much more computation which will bring
> different behaviours comparied to that on our home machines. And now,
> we have one more attack way: the sync. I believe we are all gentlemen,
> but what if it is a bug? It's hard to say. Well, if a person that have
> built a team for competition, he will understand this more easily.
Well, as I said the sync mode is only for development and debugging
purposes. It is certainly not suitable for the competitions.
While a better timer could make things more desirable (I have a proposal
for a timer at the end of this email), things are not that bad now.
There is a trade off between trying to be real time, and being more
deterministic. We've moved from the former towards the latter slightly.
For example, anything which cause the simulator to do more computation
should not affect agents' behaviors. The only effect is to make the
whole simulation slower.
BTW, there are certainly cases that would affect teams (the difference
between remote vs local runs, which should be much more consistent in
the latest code but note completely vanished). Also let me note that my
own team (UI-AI) in 2007 was hardly hit by these timing issues. Our
agents could walk just fine on our systems, but in the competitions they
were almost unable to properly walk. So I can understand what problems
you are talking about.
> Handling the noise is really a good topic. However we are on a
> simulator, not a real robot. We should simulate the noise, not let it
> happen out of our control. And, in my opinion, in order to bring our
> old research topics(strategy making, MAS, etc), the noise should be
> negotiated to avoid letting the motion control be the main topic.
Yes if we want to make things simpler, we should go for a strict and
(almost?) completely deterministic timer.
> Things are really bad now. TCs of 2D have been discussing the idea of
> 2.5D which involving the z axis. We should stop talking about
> the issues that for developers' concern(for example: whether using TCP
> or UDP), but pay more attention to how to bring back more research
> topics. Orelse, we are losing more and more teams.
> Well, as it is said, "don't complain if you don't contribute". But
> someone does contribute or will contribue but is not allowed complain.
> Well, I'd never expected to convince somebody since last year. But I
> am writing this email to support Sander's opinion because it is really
> important.
I think the sentence ("don't complain if you don't contribute") is going
to have a slightly different meaning than the original intent. At least
in my opinion, this sentence is about people who just complain.
Contribution is not necessary by providing code or documentation. If you
are constructive, you are contributing. Personally I do consider
providing constructive comments/suggestions/objections as contributions.
Putting forward discussions like this is far from those who just
complain! Any comments which can affect our decisions is highly
appreciated in MC. :) So, everybody have the right to participate in
such discussions; let alone people like you who are MC members.
Well, unfortunately me first email is going to become problematic. I
tried to avoid that - I said that it is not directly related to the main
subject - but it happened. I stated that we can solve some of the
problems with some simpler solutions than a new timer, like the sync
mode; but I said that "it is a temporary solution while we don't have a
new timer". I didn't want to say that it can fill the need for a new
timer. Also I mentioned that the latest code is less sensitive to small
network delays. To be more precise, except for teams who have some time
consuming computations in decision making and/or doing basic behaviors
(so need almost all of the time of a single cycle); it is not sensitive
to relatively "small" system/network delays. And another problem which
was problematic for many teams was that they were thinking "too fast",
and this could create a huge difference between running the simulator
locally vs running over network. IMHO, many of the teams was suffering
from this problem rather than thinking too much.
But I agree with Sander's point 3, which mostly affects teams which need
long thinking times and as we are going to have more players it'll
become more important. So yes, as far as the hardware used by teams is
not theirs, we need a better timer to mitigate hardware issues and if we
want to make our simulator a bit simpler than the real world in this
regard.
Finally my last comment was about how the new timer should be: in my
opinion, it should not be too strict like SPADES which considers CPU
cycles used by agents. That is too much (an example was what Sander
mentioned about using programming languages) and also considering the
popularity of multi-core CPUs; it should let the teams to use CPU power
completely in the desired cycle time. I'm not completely sure but I
think it would need some (maybe complex) changes in SPADES (considering
a dual core cpu, agents should be able to use both cores for 0.02
seconds, but not using 1 core for 0.04s). As I said before, there is a
trade off here and I think going towards a system which can run the
games equally on ANY system setup is not appropriate.
OK, let me try to bring the discussion back to its main line. I have a
proposal for a new timer, and I want to know your opinions about. It is
simple, and is (hopefully) simple to setup and I think it would satisfy
most of the concerns. But it does not guarantee that the agents'
performance is independent from the machine it runs on.
This is as follows:
For each agent we run a proxy application in the agent's machine (or
maybe it'll be a single proxy for all agents in the machine). Agents
connect to this proxy instead of the main simulator, and communicate
with it. It is the proxy's job to control the thinking time of the
agents. The proxy waits at much as a single cycle before reading more
commands from an agent. After each cycle, proxies must signal the server
to proceed to the next cycle (something like the sync mode, but
controlled by the proxies rather than the agents). There are some
details to prevent agents of interfering with the proxies activity, but
I think we can have an acceptable implementation using appropriate
design and priority settings.
Thanks,
Hedayat
> 20:04:47 2009-11-26 Sander van Dijk:
>
> Hi Hedayat and Khashayar,
>
> Thanks for your replies, but I can't say I agree with Hedayat. To
> stick to your points:
>
> 1. This is indeed a fast and easy to have 6 vs 6 games on any
> system. However, this means agents practically will have infinite
> available thinking time, which isn't realistic. Moreover, this
> makes the length of a game variable depending on the agents, which
> is a pain for organisation. For these reasons such a 'Sync' timer
> model is not feasible and definitely not desirable during actual
> competitions, coming back to my argument that teams won't be able
> to prepare well, because games they play at home are not
> representable of games played at the competitions.
>
> 2. There has been improvement in the latest version. However, as
> you said it is only 'less sensitive' and 'more fair', but still
> sensitive and unfair.
>
> 3. I do agree with you that it is interesting to research
> adaptation to changes in processing power, network delays, et
> cetera, but as I said in my previous E-Mail and as discussed
> during the road map discussion, this has to be controllable. At
> the moment this is totally random. Regarding the unbalanced
> unfairness for different teams, this can be caused by factors
> outside of the server like hardware, which can be mediated with a
> better timer. But even without any bug in the server and with
> perfectly fair hardware it could be that the agents of one team
> require more thinking time than the current setup supplies. Now
> you can say that's their problem, they should have been programmed
> more efficient or shouldn't use those infeasibly complex
> algorithms, but to come back to reproducibility again (and
> Khashayar's experience): there is no way they can know beforehand
> that it will be a problem, because they don't have access to the
> exact same system.
>
> So concluding, I still think a good timer is of high importance.
>
> Cheers,
> Sander
>
> On Thu, Nov 26, 2009 at 5:14 PM, Khashayar <kh....@gm...
> <mailto:kh....@gm...>> wrote:
>
> Dear Sander and Hedayat
> First of all I would like to mention the point that only 'fair
> games' as Hedayat said is not enough, and we need to do sth to
> reduce the disadvantages of our platform sensitivity to timing
> difficulties like network delays. I deeply believe that we do
> need a timer that gives each agent the same, predetermined
> amount of processing time for each time step in /any/ (network
> / system) conditions. I remember this problem affected our
> team (Scorpius) greatly in Graz competitions, Although as
> Hedayat mentioned this small effect will take place for both
> teams during competition but because we hadn't handled it
> before (and it's really hard to handle!), that caused our
> agents to fall down in their Max speed of walking during the
> matches on server which had never happened on our systems
> before. Overall, i think that we should consider this (timer)
> problem even if it may seems fair or ignorable!
>
> On Thu, Nov 26, 2009 at 3:39 AM, Hedayat Vatankhah
> <hed...@ai... <mailto:hed...@ai...>> wrote:
>
> Hi Sander,
> Just some notes (maybe not directly related to the main
> discussion; sorry for that):
> 1. It is possible to make running full 6 vs 6 (or more)
> games possible for everyone without a new timer: the
> proposed Sync mode (in which the simulator will proceed to
> the next cycle when all of the connected agents tell it to
> do so) could enable teams to run games on any system
> successfully. This could be at least a temporary
> workaround while we do not have a new timer.
> 2. The latest code is less sensitive to small network
> delays than before, and it is more fair.
> 3. IMHO we should not desire strictly equal conditions for
> all teams during the whole game; since it doesn't happen
> in real world too. Small hardware/network delays and other
> such things might happen in real robots too. However,
> these should happen really "random" with the same
> probability for both teams. It should not affect one team
> more. I'm not sure if it needs a new timer; if the
> simulator could provide some advantage for one team during
> a game, it is probably a bug somewhere in the current
> code, or in the game cluster setup.
> So I think the timer should be fair, but it does not
> necessarily mean that all agents should always receive
> exactly the same thinking time. The thinking time could
> vary during the game, but it should happen for both teams
> almost equally.
>
>
> Thanks,
> Hedayat
>
>
>
> On ۰۹/۱۱/۲۵ 05:43, Sander van Dijk wrote:
>> Hello fellow 3D-ists,
>>
>> During the competitions in Graz this year we discussed
>> the future of our league in the roadmap discussion (see
>> Sahar's mail on the 3D list from 24th of July for a full
>> summary). The most important point was that next year we
>> want to double the amount of players and play 6 vs 6
>> games. There is already good work under way to make this
>> possible (e.g. multi threading (Hedayat) and possibility
>> for different (maybe faster) physics engines (Andreas,
>> great stuff!)). However I think the most important thing
>> (I even think crucial thing) is missing: a good timer.
>>
>> There are 2 reasons I think this needs high priority:
>>
>> 1. To have fair games. The last few years there was
>> already some discussion about fair timing. Especially in
>> China things seemed to go wrong, where in the same game
>> one team seemed to be more affected than the other team.
>> With more agents this will only get worse, especially I
>> expect when we throw more computers into the mix
>> (multiple computers per team for instance). There is an
>> argument that can be made for limiting the think time by
>> real time and hardware constraints, but at the moment it
>> is too uncontrolled. With network traffic, thread
>> scheduling, et cetera, the amount of processing time an
>> agent gets is basically random and some agents/teams may
>> be disadvantaged.
>>
>> 2. To have reproducible games. Hereby I don't mean that
>> games should be deterministic, some noise is needed
>> (though again, in a controllable way), but games run on
>> one system should be representable of games played on
>> another system (and especially on the same system at a
>> different time). Herein also lies the reason I think a
>> better timer is crucial and even more important than the
>> other improvements being made:
>>
>> � Without a good timer teams may not be able to prepare
>> for the competitions, especially if they don't have
>> access to a cluster of high end machines like we will
>> hopefully have, simply because they cannot play full 6 vs
>> 6 games that reflect games at the competitions.
>>
>> So what I think we need is a timer that gives each agent
>> the same, predetermined amount of processing time for
>> each time step. This possibly reduces simulation speed to
>> less than real time, but at least anybody then can run a
>> full match on any system and all other improvements
>> become less pressing if you only consider ability to play
>> a game (but of course in the end we do want real time).
>> In Austria we said 'don't complain if you don't
>> contribute' and I would like to go ahead and implement
>> something like this, however I am missing the time. But
>> hopefully I convinced you that this is one of the (if not
>> *the*) most important issue for next year and I can put
>> down some points to perhaps guide to a solution:
>>
>> - We used to have a system which did mostly what I said
>> above: the Spades middleware system [1], however it
>> didn't make the transition from spheres to humanoids in
>> 2007. What was the exact reason, does it have unwanted
>> properties or is it a lack of knowledge about it? I think
>> Joschka can shed some more light on this probably?
>> - What properties do we want the timer to have? Do we
>> want to limit CPU cycles which might give teams using
>> e.g. Java a disadvantage compared to assembly hackers, or
>> computation time which might make the timer still too
>> machine-specific..
>> - How does timing in the 2D simulation work, can we learn
>> something from that, or even just copy it?
>> - And most important: who will work on this?
>>
>>
>> Cheers,
>> Sander
>>
>>
>> [1] http://spades-sim.sourceforge.net/
>
>
|
|
From: Hedayat V. <hed...@ai...> - 2009-11-26 20:11:38
|
Hi, On ۰۹/۱۱/۲۶ 10:34, Sander van Dijk wrote: > Hi Hedayat and Khashayar, > > Thanks for your replies, but I can't say I agree with Hedayat. To > stick to your points: > > 1. This is indeed a fast and easy to have 6 vs 6 games on any system. > However, this means agents practically will have infinite available > thinking time, which isn't realistic. Moreover, this makes the length > of a game variable depending on the agents, which is a pain for > organisation. For these reasons such a 'Sync' timer model is not > feasible and definitely not desirable during actual competitions, > coming back to my argument that teams won't be able to prepare well, > because games they play at home are not representable of games played > at the competitions. Yes, the proposed sync mode is just for debugging purposes. > > 2. There has been improvement in the latest version. However, as you > said it is only 'less sensitive' and 'more fair', but still sensitive > and unfair. > > 3. I do agree with you that it is interesting to research adaptation > to changes in processing power, network delays, et cetera, but as I > said in my previous E-Mail and as discussed during the road map > discussion, this has to be controllable. At the moment this is totally > random. Regarding the unbalanced unfairness for different teams, this > can be caused by factors outside of the server like hardware, which > can be mediated with a better timer. But even without any bug in the > server and with perfectly fair hardware it could be that the agents of > one team require more thinking time than the current setup supplies. > Now you can say that's their problem, they should have been programmed > more efficient or shouldn't use those infeasibly complex algorithms, > but to come back to reproducibility again (and Khashayar's > experience): there is no way they can know beforehand that it will be > a problem, because they don't have access to the exact same system. Well, I noted that I'm not against a better timer, but to say that: 1. things are not that bad, 2. the timer does not need to provide strictly the same processing time to the agents (as measured in CPU cycles!) I'm not sure but I think there is no such strict timing in 2D too. There is not any special software on client machines to control agents' thinking time. Maybe the main difference is (I'm not sure about it) that they use UDP instead of TCP. Good luck, Hedayat > > So concluding, I still think a good timer is of high importance. > > Cheers, > Sander > > On Thu, Nov 26, 2009 at 5:14 PM, Khashayar <kh....@gm... > <mailto:kh....@gm...>> wrote: > > Dear Sander and Hedayat > First of all I would like to mention the point that only 'fair > games' as Hedayat said is not enough, and we need to do sth to > reduce the disadvantages of our platform sensitivity to timing > difficulties like network delays. I deeply believe that we do need > a timer that gives each agent the same, predetermined amount of > processing time for each time step in /any/ (network / system) > conditions. I remember this problem affected our team > (Scorpius) greatly in Graz competitions, Although as Hedayat > mentioned this small effect will take place for both teams during > competition but because we hadn't handled it before (and it's > really hard to handle!), that caused our agents to fall down in > their Max speed of walking during the matches on server which had > never happened on our systems before. Overall, i think that we > should consider this (timer) problem even if it may seems fair or > ignorable! > > On Thu, Nov 26, 2009 at 3:39 AM, Hedayat Vatankhah > <hed...@ai... <mailto:hed...@ai...>> wrote: > > Hi Sander, > Just some notes (maybe not directly related to the main > discussion; sorry for that): > 1. It is possible to make running full 6 vs 6 (or more) games > possible for everyone without a new timer: the proposed Sync > mode (in which the simulator will proceed to the next cycle > when all of the connected agents tell it to do so) could > enable teams to run games on any system successfully. This > could be at least a temporary workaround while we do not have > a new timer. > 2. The latest code is less sensitive to small network delays > than before, and it is more fair. > 3. IMHO we should not desire strictly equal conditions for all > teams during the whole game; since it doesn't happen in real > world too. Small hardware/network delays and other such things > might happen in real robots too. However, these should happen > really "random" with the same probability for both teams. It > should not affect one team more. I'm not sure if it needs a > new timer; if the simulator could provide some advantage for > one team during a game, it is probably a bug somewhere in the > current code, or in the game cluster setup. > So I think the timer should be fair, but it does not > necessarily mean that all agents should always receive exactly > the same thinking time. The thinking time could vary during > the game, but it should happen for both teams almost equally. > > > Thanks, > Hedayat > > > > On ۰۹/۱۱/۲۵ 05:43, Sander van Dijk wrote: >> Hello fellow 3D-ists, >> >> During the competitions in Graz this year we discussed the >> future of our league in the roadmap discussion (see Sahar's >> mail on the 3D list from 24th of July for a full summary). >> The most important point was that next year we want to double >> the amount of players and play 6 vs 6 games. There is already >> good work under way to make this possible (e.g. multi >> threading (Hedayat) and possibility for different (maybe >> faster) physics engines (Andreas, great stuff!)). However I >> think the most important thing (I even think crucial thing) >> is missing: a good timer. >> >> There are 2 reasons I think this needs high priority: >> >> 1. To have fair games. The last few years there was already >> some discussion about fair timing. Especially in China things >> seemed to go wrong, where in the same game one team seemed to >> be more affected than the other team. With more agents this >> will only get worse, especially I expect when we throw more >> computers into the mix (multiple computers per team for >> instance). There is an argument that can be made for limiting >> the think time by real time and hardware constraints, but at >> the moment it is too uncontrolled. With network traffic, >> thread scheduling, et cetera, the amount of processing time >> an agent gets is basically random and some agents/teams may >> be disadvantaged. >> >> 2. To have reproducible games. Hereby I don't mean that games >> should be deterministic, some noise is needed (though again, >> in a controllable way), but games run on one system should be >> representable of games played on another system (and >> especially on the same system at a different time). Herein >> also lies the reason I think a better timer is crucial and >> even more important than the other improvements being made: >> >> � Without a good timer teams may not be able to prepare for >> the competitions, especially if they don't have access to a >> cluster of high end machines like we will hopefully have, >> simply because they cannot play full 6 vs 6 games that >> reflect games at the competitions. >> >> So what I think we need is a timer that gives each agent the >> same, predetermined amount of processing time for each time >> step. This possibly reduces simulation speed to less than >> real time, but at least anybody then can run a full match on >> any system and all other improvements become less pressing if >> you only consider ability to play a game (but of course in >> the end we do want real time). In Austria we said 'don't >> complain if you don't contribute' and I would like to go >> ahead and implement something like this, however I am missing >> the time. But hopefully I convinced you that this is one of >> the (if not *the*) most important issue for next year and I >> can put down some points to perhaps guide to a solution: >> >> - We used to have a system which did mostly what I said >> above: the Spades middleware system [1], however it didn't >> make the transition from spheres to humanoids in 2007. What >> was the exact reason, does it have unwanted properties or is >> it a lack of knowledge about it? I think Joschka can shed >> some more light on this probably? >> - What properties do we want the timer to have? Do we want to >> limit CPU cycles which might give teams using e.g. Java a >> disadvantage compared to assembly hackers, or computation >> time which might make the timer still too machine-specific.. >> - How does timing in the 2D simulation work, can we learn >> something from that, or even just copy it? >> - And most important: who will work on this? >> >> >> Cheers, >> Sander >> >> >> [1] http://spades-sim.sourceforge.net/ >> >> >> >> -- >> Adaptive Systems Research Group >> Department of Computer Science >> University of Hertfordshire >> United Kingdom >> >> >> ------------------------------------------------------------------------------ >> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day >> trial. Simplify your report design, integration and deployment - and focus on >> what you do best, core application coding. Discover what's new with >> Crystal Reports now.http://p.sf.net/sfu/bobj-july >> >> >> >> _______________________________________________ >> Simspark Generic Physical MAS Simulator >> simspark-devel mailing list >> sim...@li... <mailto:sim...@li...> >> https://lists.sourceforge.net/lists/listinfo/simspark-devel >> > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal > Reports 2008 30-Day > trial. Simplify your report design, integration and deployment > - and focus on > what you do best, core application coding. Discover what's new > with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Simspark Generic Physical MAS Simulator > simspark-devel mailing list > sim...@li... > <mailto:sim...@li...> > https://lists.sourceforge.net/lists/listinfo/simspark-devel > > > > > -- > Best Regards > Khashayar > > > > > -- > Adaptive Systems Research Group > Department of Computer Science > University of Hertfordshire > United Kingdom |
|
From: Sander v. D. <sgv...@gm...> - 2009-11-26 19:04:16
|
Hi Hedayat and Khashayar, Thanks for your replies, but I can't say I agree with Hedayat. To stick to your points: 1. This is indeed a fast and easy to have 6 vs 6 games on any system. However, this means agents practically will have infinite available thinking time, which isn't realistic. Moreover, this makes the length of a game variable depending on the agents, which is a pain for organisation. For these reasons such a 'Sync' timer model is not feasible and definitely not desirable during actual competitions, coming back to my argument that teams won't be able to prepare well, because games they play at home are not representable of games played at the competitions. 2. There has been improvement in the latest version. However, as you said it is only 'less sensitive' and 'more fair', but still sensitive and unfair. 3. I do agree with you that it is interesting to research adaptation to changes in processing power, network delays, et cetera, but as I said in my previous E-Mail and as discussed during the road map discussion, this has to be controllable. At the moment this is totally random. Regarding the unbalanced unfairness for different teams, this can be caused by factors outside of the server like hardware, which can be mediated with a better timer. But even without any bug in the server and with perfectly fair hardware it could be that the agents of one team require more thinking time than the current setup supplies. Now you can say that's their problem, they should have been programmed more efficient or shouldn't use those infeasibly complex algorithms, but to come back to reproducibility again (and Khashayar's experience): there is no way they can know beforehand that it will be a problem, because they don't have access to the exact same system. So concluding, I still think a good timer is of high importance. Cheers, Sander On Thu, Nov 26, 2009 at 5:14 PM, Khashayar <kh....@gm...> wrote: > Dear Sander and Hedayat > > First of all I would like to mention the point that only 'fair games' as > Hedayat said is not enough, and we need to do sth to reduce the > disadvantages of our platform sensitivity to timing difficulties like > network delays. I deeply believe that we do need a timer that gives each > agent the same, predetermined amount of processing time for each time > step in *any* (network / system) conditions. I remember this problem > affected our team (Scorpius) greatly in Graz competitions, Although as > Hedayat mentioned this small effect will take place for both teams during > competition but because we hadn't handled it before (and it's really hard to > handle!), that caused our agents to fall down in their Max speed of walking > during the matches on server which had never happened on our systems before. > Overall, i think that we should consider this (timer) problem even if it may > seems fair or ignorable! > > On Thu, Nov 26, 2009 at 3:39 AM, Hedayat Vatankhah <hed...@ai...>wrote: > >> Hi Sander, >> Just some notes (maybe not directly related to the main discussion; sorry >> for that): >> 1. It is possible to make running full 6 vs 6 (or more) games possible for >> everyone without a new timer: the proposed Sync mode (in which the simulator >> will proceed to the next cycle when all of the connected agents tell it to >> do so) could enable teams to run games on any system successfully. This >> could be at least a temporary workaround while we do not have a new timer. >> 2. The latest code is less sensitive to small network delays than before, >> and it is more fair. >> 3. IMHO we should not desire strictly equal conditions for all teams >> during the whole game; since it doesn't happen in real world too. Small >> hardware/network delays and other such things might happen in real robots >> too. However, these should happen really "random" with the same probability >> for both teams. It should not affect one team more. I'm not sure if it needs >> a new timer; if the simulator could provide some advantage for one team >> during a game, it is probably a bug somewhere in the current code, or in the >> game cluster setup. >> So I think the timer should be fair, but it does not necessarily mean that >> all agents should always receive exactly the same thinking time. The >> thinking time could vary during the game, but it should happen for both >> teams almost equally. >> >> >> Thanks, >> Hedayat >> >> >> >> On ۰۹/۱۱/۲۵ 05:43, Sander van Dijk wrote: >> >> Hello fellow 3D-ists, >> >> During the competitions in Graz this year we discussed the future of our >> league in the roadmap discussion (see Sahar's mail on the 3D list from 24th >> of July for a full summary). The most important point was that next year we >> want to double the amount of players and play 6 vs 6 games. There is already >> good work under way to make this possible (e.g. multi threading (Hedayat) >> and possibility for different (maybe faster) physics engines (Andreas, great >> stuff!)). However I think the most important thing (I even think crucial >> thing) is missing: a good timer. >> >> There are 2 reasons I think this needs high priority: >> >> 1. To have fair games. The last few years there was already some >> discussion about fair timing. Especially in China things seemed to go wrong, >> where in the same game one team seemed to be more affected than the other >> team. With more agents this will only get worse, especially I expect when we >> throw more computers into the mix (multiple computers per team for >> instance). There is an argument that can be made for limiting the think time >> by real time and hardware constraints, but at the moment it is too >> uncontrolled. With network traffic, thread scheduling, et cetera, the amount >> of processing time an agent gets is basically random and some agents/teams >> may be disadvantaged. >> >> 2. To have reproducible games. Hereby I don't mean that games should be >> deterministic, some noise is needed (though again, in a controllable way), >> but games run on one system should be representable of games played on >> another system (and especially on the same system at a different time). >> Herein also lies the reason I think a better timer is crucial and even more >> important than the other improvements being made: >> >> � Without a good timer teams may not be able to prepare for the >> competitions, especially if they don't have access to a cluster of high end >> machines like we will hopefully have, simply because they cannot play full 6 >> vs 6 games that reflect games at the competitions. >> >> So what I think we need is a timer that gives each agent the same, >> predetermined amount of processing time for each time step. This possibly >> reduces simulation speed to less than real time, but at least anybody then >> can run a full match on any system and all other improvements become less >> pressing if you only consider ability to play a game (but of course in the >> end we do want real time). In Austria we said 'don't complain if you don't >> contribute' and I would like to go ahead and implement something like this, >> however I am missing the time. But hopefully I convinced you that this is >> one of the (if not *the*) most important issue for next year and I can put >> down some points to perhaps guide to a solution: >> >> - We used to have a system which did mostly what I said above: the Spades >> middleware system [1], however it didn't make the transition from spheres to >> humanoids in 2007. What was the exact reason, does it have unwanted >> properties or is it a lack of knowledge about it? I think Joschka can shed >> some more light on this probably? >> - What properties do we want the timer to have? Do we want to limit CPU >> cycles which might give teams using e.g. Java a disadvantage compared to >> assembly hackers, or computation time which might make the timer still too >> machine-specific.. >> - How does timing in the 2D simulation work, can we learn something from >> that, or even just copy it? >> - And most important: who will work on this? >> >> >> Cheers, >> Sander >> >> >> [1] http://spades-sim.sourceforge.net/ >> >> >> >> -- >> Adaptive Systems Research Group >> Department of Computer Science >> University of Hertfordshire >> United Kingdom >> >> >> ------------------------------------------------------------------------------ >> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day >> trial. Simplify your report design, integration and deployment - and focus on >> what you do best, core application coding. Discover what's new with >> Crystal Reports now. http://p.sf.net/sfu/bobj-july >> >> >> _______________________________________________ >> Simspark Generic Physical MAS Simulator >> simspark-devel mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/simspark-devel >> >> >> >> ------------------------------------------------------------------------------ >> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 >> 30-Day >> trial. Simplify your report design, integration and deployment - and focus >> on >> what you do best, core application coding. Discover what's new with >> Crystal Reports now. http://p.sf.net/sfu/bobj-july >> _______________________________________________ >> Simspark Generic Physical MAS Simulator >> simspark-devel mailing list >> sim...@li... >> https://lists.sourceforge.net/lists/listinfo/simspark-devel >> >> > > > -- > Best Regards > Khashayar > -- Adaptive Systems Research Group Department of Computer Science University of Hertfordshire United Kingdom |
|
From: Khashayar <kh....@gm...> - 2009-11-26 17:14:45
|
Dear Sander and Hedayat First of all I would like to mention the point that only 'fair games' as Hedayat said is not enough, and we need to do sth to reduce the disadvantages of our platform sensitivity to timing difficulties like network delays. I deeply believe that we do need a timer that gives each agent the same, predetermined amount of processing time for each time step in *any* (network / system) conditions. I remember this problem affected our team (Scorpius) greatly in Graz competitions, Although as Hedayat mentioned this small effect will take place for both teams during competition but because we hadn't handled it before (and it's really hard to handle!), that caused our agents to fall down in their Max speed of walking during the matches on server which had never happened on our systems before. Overall, i think that we should consider this (timer) problem even if it may seems fair or ignorable! On Thu, Nov 26, 2009 at 3:39 AM, Hedayat Vatankhah <hed...@ai...>wrote: > Hi Sander, > Just some notes (maybe not directly related to the main discussion; sorry > for that): > 1. It is possible to make running full 6 vs 6 (or more) games possible for > everyone without a new timer: the proposed Sync mode (in which the simulator > will proceed to the next cycle when all of the connected agents tell it to > do so) could enable teams to run games on any system successfully. This > could be at least a temporary workaround while we do not have a new timer. > 2. The latest code is less sensitive to small network delays than before, > and it is more fair. > 3. IMHO we should not desire strictly equal conditions for all teams during > the whole game; since it doesn't happen in real world too. Small > hardware/network delays and other such things might happen in real robots > too. However, these should happen really "random" with the same probability > for both teams. It should not affect one team more. I'm not sure if it needs > a new timer; if the simulator could provide some advantage for one team > during a game, it is probably a bug somewhere in the current code, or in the > game cluster setup. > So I think the timer should be fair, but it does not necessarily mean that > all agents should always receive exactly the same thinking time. The > thinking time could vary during the game, but it should happen for both > teams almost equally. > > > Thanks, > Hedayat > > > > On ۰۹/۱۱/۲۵ 05:43, Sander van Dijk wrote: > > Hello fellow 3D-ists, > > During the competitions in Graz this year we discussed the future of our > league in the roadmap discussion (see Sahar's mail on the 3D list from 24th > of July for a full summary). The most important point was that next year we > want to double the amount of players and play 6 vs 6 games. There is already > good work under way to make this possible (e.g. multi threading (Hedayat) > and possibility for different (maybe faster) physics engines (Andreas, great > stuff!)). However I think the most important thing (I even think crucial > thing) is missing: a good timer. > > There are 2 reasons I think this needs high priority: > > 1. To have fair games. The last few years there was already some discussion > about fair timing. Especially in China things seemed to go wrong, where in > the same game one team seemed to be more affected than the other team. With > more agents this will only get worse, especially I expect when we throw more > computers into the mix (multiple computers per team for instance). There is > an argument that can be made for limiting the think time by real time and > hardware constraints, but at the moment it is too uncontrolled. With network > traffic, thread scheduling, et cetera, the amount of processing time an > agent gets is basically random and some agents/teams may be disadvantaged. > > 2. To have reproducible games. Hereby I don't mean that games should be > deterministic, some noise is needed (though again, in a controllable way), > but games run on one system should be representable of games played on > another system (and especially on the same system at a different time). > Herein also lies the reason I think a better timer is crucial and even more > important than the other improvements being made: > > � Without a good timer teams may not be able to prepare for the > competitions, especially if they don't have access to a cluster of high end > machines like we will hopefully have, simply because they cannot play full 6 > vs 6 games that reflect games at the competitions. > > So what I think we need is a timer that gives each agent the same, > predetermined amount of processing time for each time step. This possibly > reduces simulation speed to less than real time, but at least anybody then > can run a full match on any system and all other improvements become less > pressing if you only consider ability to play a game (but of course in the > end we do want real time). In Austria we said 'don't complain if you don't > contribute' and I would like to go ahead and implement something like this, > however I am missing the time. But hopefully I convinced you that this is > one of the (if not *the*) most important issue for next year and I can put > down some points to perhaps guide to a solution: > > - We used to have a system which did mostly what I said above: the Spades > middleware system [1], however it didn't make the transition from spheres to > humanoids in 2007. What was the exact reason, does it have unwanted > properties or is it a lack of knowledge about it? I think Joschka can shed > some more light on this probably? > - What properties do we want the timer to have? Do we want to limit CPU > cycles which might give teams using e.g. Java a disadvantage compared to > assembly hackers, or computation time which might make the timer still too > machine-specific.. > - How does timing in the 2D simulation work, can we learn something from > that, or even just copy it? > - And most important: who will work on this? > > > Cheers, > Sander > > > [1] http://spades-sim.sourceforge.net/ > > > > -- > Adaptive Systems Research Group > Department of Computer Science > University of Hertfordshire > United Kingdom > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > > > _______________________________________________ > Simspark Generic Physical MAS Simulator > simspark-devel mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/simspark-devel > > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus > on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Simspark Generic Physical MAS Simulator > simspark-devel mailing list > sim...@li... > https://lists.sourceforge.net/lists/listinfo/simspark-devel > > -- Best Regards Khashayar |
|
From: Hedayat V. <hed...@ai...> - 2009-11-26 00:11:20
|
Hi Sander, Just some notes (maybe not directly related to the main discussion; sorry for that): 1. It is possible to make running full 6 vs 6 (or more) games possible for everyone without a new timer: the proposed Sync mode (in which the simulator will proceed to the next cycle when all of the connected agents tell it to do so) could enable teams to run games on any system successfully. This could be at least a temporary workaround while we do not have a new timer. 2. The latest code is less sensitive to small network delays than before, and it is more fair. 3. IMHO we should not desire strictly equal conditions for all teams during the whole game; since it doesn't happen in real world too. Small hardware/network delays and other such things might happen in real robots too. However, these should happen really "random" with the same probability for both teams. It should not affect one team more. I'm not sure if it needs a new timer; if the simulator could provide some advantage for one team during a game, it is probably a bug somewhere in the current code, or in the game cluster setup. So I think the timer should be fair, but it does not necessarily mean that all agents should always receive exactly the same thinking time. The thinking time could vary during the game, but it should happen for both teams almost equally. Thanks, Hedayat On ۰۹/۱۱/۲۵ 05:43, Sander van Dijk wrote: > Hello fellow 3D-ists, > > During the competitions in Graz this year we discussed the future of > our league in the roadmap discussion (see Sahar's mail on the 3D list > from 24th of July for a full summary). The most important point was > that next year we want to double the amount of players and play 6 vs 6 > games. There is already good work under way to make this possible > (e.g. multi threading (Hedayat) and possibility for different (maybe > faster) physics engines (Andreas, great stuff!)). However I think the > most important thing (I even think crucial thing) is missing: a good > timer. > > There are 2 reasons I think this needs high priority: > > 1. To have fair games. The last few years there was already some > discussion about fair timing. Especially in China things seemed to go > wrong, where in the same game one team seemed to be more affected than > the other team. With more agents this will only get worse, especially > I expect when we throw more computers into the mix (multiple computers > per team for instance). There is an argument that can be made for > limiting the think time by real time and hardware constraints, but at > the moment it is too uncontrolled. With network traffic, thread > scheduling, et cetera, the amount of processing time an agent gets is > basically random and some agents/teams may be disadvantaged. > > 2. To have reproducible games. Hereby I don't mean that games should > be deterministic, some noise is needed (though again, in a > controllable way), but games run on one system should be representable > of games played on another system (and especially on the same system > at a different time). Herein also lies the reason I think a better > timer is crucial and even more important than the other improvements > being made: > > � Without a good timer teams may not be able to prepare for the > competitions, especially if they don't have access to a cluster of > high end machines like we will hopefully have, simply because they > cannot play full 6 vs 6 games that reflect games at the competitions. > > So what I think we need is a timer that gives each agent the same, > predetermined amount of processing time for each time step. This > possibly reduces simulation speed to less than real time, but at least > anybody then can run a full match on any system and all other > improvements become less pressing if you only consider ability to play > a game (but of course in the end we do want real time). In Austria we > said 'don't complain if you don't contribute' and I would like to go > ahead and implement something like this, however I am missing the > time. But hopefully I convinced you that this is one of the (if not > *the*) most important issue for next year and I can put down some > points to perhaps guide to a solution: > > - We used to have a system which did mostly what I said above: the > Spades middleware system [1], however it didn't make the transition > from spheres to humanoids in 2007. What was the exact reason, does it > have unwanted properties or is it a lack of knowledge about it? I > think Joschka can shed some more light on this probably? > - What properties do we want the timer to have? Do we want to limit > CPU cycles which might give teams using e.g. Java a disadvantage > compared to assembly hackers, or computation time which might make the > timer still too machine-specific.. > - How does timing in the 2D simulation work, can we learn something > from that, or even just copy it? > - And most important: who will work on this? > > > Cheers, > Sander > > > [1] http://spades-sim.sourceforge.net/ > > > > -- > Adaptive Systems Research Group > Department of Computer Science > University of Hertfordshire > United Kingdom > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > > > > _______________________________________________ > Simspark Generic Physical MAS Simulator > simspark-devel mailing list > sim...@li... > https://lists.sourceforge.net/lists/listinfo/simspark-devel > |
|
From: Sander v. D. <sgv...@gm...> - 2009-11-25 14:13:36
|
Hello fellow 3D-ists, During the competitions in Graz this year we discussed the future of our league in the roadmap discussion (see Sahar's mail on the 3D list from 24th of July for a full summary). The most important point was that next year we want to double the amount of players and play 6 vs 6 games. There is already good work under way to make this possible (e.g. multi threading (Hedayat) and possibility for different (maybe faster) physics engines (Andreas, great stuff!)). However I think the most important thing (I even think crucial thing) is missing: a good timer. There are 2 reasons I think this needs high priority: 1. To have fair games. The last few years there was already some discussion about fair timing. Especially in China things seemed to go wrong, where in the same game one team seemed to be more affected than the other team. With more agents this will only get worse, especially I expect when we throw more computers into the mix (multiple computers per team for instance). There is an argument that can be made for limiting the think time by real time and hardware constraints, but at the moment it is too uncontrolled. With network traffic, thread scheduling, et cetera, the amount of processing time an agent gets is basically random and some agents/teams may be disadvantaged. 2. To have reproducible games. Hereby I don't mean that games should be deterministic, some noise is needed (though again, in a controllable way), but games run on one system should be representable of games played on another system (and especially on the same system at a different time). Herein also lies the reason I think a better timer is crucial and even more important than the other improvements being made: Without a good timer teams may not be able to prepare for the competitions, especially if they don't have access to a cluster of high end machines like we will hopefully have, simply because they cannot play full 6 vs 6 games that reflect games at the competitions. So what I think we need is a timer that gives each agent the same, predetermined amount of processing time for each time step. This possibly reduces simulation speed to less than real time, but at least anybody then can run a full match on any system and all other improvements become less pressing if you only consider ability to play a game (but of course in the end we do want real time). In Austria we said 'don't complain if you don't contribute' and I would like to go ahead and implement something like this, however I am missing the time. But hopefully I convinced you that this is one of the (if not *the*) most important issue for next year and I can put down some points to perhaps guide to a solution: - We used to have a system which did mostly what I said above: the Spades middleware system [1], however it didn't make the transition from spheres to humanoids in 2007. What was the exact reason, does it have unwanted properties or is it a lack of knowledge about it? I think Joschka can shed some more light on this probably? - What properties do we want the timer to have? Do we want to limit CPU cycles which might give teams using e.g. Java a disadvantage compared to assembly hackers, or computation time which might make the timer still too machine-specific.. - How does timing in the 2D simulation work, can we learn something from that, or even just copy it? - And most important: who will work on this? Cheers, Sander [1] http://spades-sim.sourceforge.net/ -- Adaptive Systems Research Group Department of Computer Science University of Hertfordshire United Kingdom |
|
From: <ah...@un...> - 2009-11-18 07:47:47
|
Hello, I just repaired the branch and rolled the trunk back to revision 97. Everything is now as it should be. :) Took me almost an entire working day, but I'll look at it as an intense SVN practical. I certainly learned a lot. :D @Hedayat Joschka and I will definitely look at the proposal you made for the design once I'm done implementing the bridge pattern for everything. sorry again, Andreas |
|
From: <ah...@un...> - 2009-11-17 11:40:13
|
Hello, I just commited today's work from my local branch folder. Here's the output from my command line: andreas@andreas-desktop:~/simspark/branches/multiphys/spark$ svn commit Sending lib/oxygen/CMakeLists.txt Sending lib/oxygen/oxygen.cpp Sending lib/oxygen/oxygen.h Sending lib/oxygen/physicsserver/body.cpp Sending lib/oxygen/physicsserver/body.h Sending lib/oxygen/physicsserver/boxcollider.h Sending lib/oxygen/physicsserver/collider.h Sending lib/oxygen/physicsserver/collisionhandler.h Adding lib/oxygen/physicsserver/imp Adding lib/oxygen/physicsserver/imp/worldimp.h Adding lib/oxygen/physicsserver/imp/worldimp_c.cpp Sending lib/oxygen/physicsserver/joint.h Adding lib/oxygen/physicsserver/ode Adding lib/oxygen/physicsserver/ode/odeobject.cpp Adding lib/oxygen/physicsserver/ode/odeobject.h Adding lib/oxygen/physicsserver/ode/odeobject_c.cpp Adding lib/oxygen/physicsserver/ode/odeworld.cpp Adding lib/oxygen/physicsserver/ode/odeworld.h Adding lib/oxygen/physicsserver/ode/odeworld_c.cpp Adding lib/oxygen/physicsserver/ode/odewrapper.h Deleting lib/oxygen/physicsserver/odeobject.cpp Deleting lib/oxygen/physicsserver/odeobject.h Deleting lib/oxygen/physicsserver/odeobject_c.cpp Deleting lib/oxygen/physicsserver/odewrapper.h Sending lib/oxygen/physicsserver/physicsserver.h Sending lib/oxygen/physicsserver/space.h Sending lib/oxygen/physicsserver/world.cpp Sending lib/oxygen/physicsserver/world.h Sending lib/oxygen/physicsserver/world_c.cpp Sending plugin/collisionperceptor/forceresistanceperceptor.cpp Sending plugin/collisionperceptor/forceresistanceperceptor.h Transmitting file data ......................... Committed revision 99. However, looking at sourceforge, I found out that my commit changed (and probably broke, since yesterday's changes aren't included) the trunk. I don't understand why, but it happened. I am truly sorry for this and hope that someone with experience in SVN can restore the trunk. Oh, and please tell me how to only change my branch (that I'm allowed to mess around in) in the future ;-) Sorry for the inconvenience, Andreas |
|
From: <ah...@un...> - 2009-11-17 11:22:43
|
Hello, I modified my design to something that uses the Bridge Pattern defined by the Gang of Four. It's initially a lot of work to implement it, and I had to start over because of it, but once it's done, little to no meddling has to be done with external classes and plugins. Incidentally, it also resolves the problem Hedayat had with my other design, as I should be able to not derive engine-specific abstract classes from BaseNode. Here's what i'm aiming for: http://www.uni-koblenz.de/~aheld/APL%20with%20Bridge%20Pattern.png The problem is that it shatters the physicsserver's internal tree quite a bit, so I tested it with the World class that (together with space) had the least dependencies. World got a pointer to a WorldImp object that is initialised to either an ODEWorld or a BulletWorld. All calls to the class World are then delegated via this pointer. It's a lot of work to implement, but when I was done, it immediately worked without me changing a single class. I think that it's by far the best design I came up with so far. Andreas |
|
From: <ah...@un...> - 2009-11-16 06:37:33
|
Hello, > Anyway, my design proposal is available here: > http://hedayat.fedorapeople.org/my_pal_proposal.png > This design should work, but you are free to choose whatever you prefer. I just looked at your design and I get it now. I actually thought of this myself at some point, but quickly ditched the idea for having too many classes. If somebody who has never touched simspark before looks at that design, it will take him a while to understand it. ;) Your design is also a little error-prone. Since BodyInterface is just an interface, I would declare all methods in it as pure virtual. Now, ODEBody inherits from Body and implements them, so ODERigidBody would inherit the implemented methods, but it would also inherit the pure virtual methods through the abstract Body and RigidBody classes. This causes a compiler error that I already ran across several times. Of course, I could work around this by declaring all interface methods as non-pure virtual with empty bodies, but then ODERigids inherits empty methods through the abstract classes, causing ambiguity. Maybe changing every call to ODEBody::MethodName(...) would work, but I don't know. The main problem is, however, that a few methods in the interface could be overlooked in other engine-specific classes, which would cause no errors, but unexpected behaviour at runtime since empty methods are called. You don't want teams to start complaining at robocup and then discover that a very specialized method is not implemented for one of the engines. ;-) The design is also a little inconsistent because there is no Interface for all abstract classes just above base level (like RigidBody and BoxCollider). Of course they don't need one, but someone with no knowledge of simspark probably couldn't understand why. > As you are the one who is going to implement the abstraction layer, you > can choose the design which you prefer. I've already heard that line a few times in the lab I work in, as well. ;-) But I always feel bad for rejecting other person's proposals, especially if they've sacrificed some of their own time making them. For the reasons I explained above, I still prefer the design I made on Friday, so I will work on that for now. However, I will keep your design in mind, and if some problems arise or other people favor your design, I can still change to yours (as both designs are pretty similar). I hope that this is ok for now. ;) thanks, Andreas > BTW, personally I prefer a > design which enables us to change the engine at runtime rather than the > compile time. > While there are some diamond inheritance in it, they are all with > xxxInterface classes which are never used, and so there won't be any > "ambiguous base" problems. You can successfully create objects like: > Body *body = new ODERigidBody(); > > Thanks, > Hedayat > > On Û°Û¹/Û±Û±/Û±Û´ 05:35, ah...@un... wrote: >> Hi, >> >> >>> If I remember correctly, all physic engine specific >>> classes which we will create objects of are leaf classes; right? If >>> that's the case, then we don't need to derive any engine specific >>> classes from BaseNode directly, as those leaf classes will inherit it >>> through abstract classes. Doesn't it work? >>> >> It should work, and I wouldn't claim that my final design is the only >> one >> that works. In the end, I think we came up with three or four slightly >> different designs that should work and picked the one that made the most >> sense to us, and best avoided ugly stuff like preprocessor commands, >> multiple inhertances or even defining the same class twice. >> >> >>> 2. If for some reason it is preferred to derive some of such engine >>> specific classes from a common abstract class (e.g. to derive ODEBody >>> and BulletBody from a common Body class), we can try this: have an >>> abstract BodyBase class which is not derived from BaseNode and derive >>> ODEBody and BulletBody classes from it. Then, create an abstract Body >>> class which is derived from both BodyBase and BaseNode classes! >>> >> Yes, there is a reason why we want to do this. The Common Body class >> defines an interface that both ODEBody and BulletBody must implement. I >> could, of course, ensure this myself, and I was leaning towards a design >> that didn't have ODEBody derived from anything for quite a while. >> However, >> we decided that we want such a common interface, if only to let another >> person who might work on a third physics engine in the future know what >> functionality he has to implement. >> >> The design you came up with might work, but I really don't know how to >> integrate the RigidBody classes into that. I tried to visualize it for >> 30 >> minutes now and it quickly becomes a mess. I can see why you don't want >> engine-specific non-leaf-classes to be derived from BaseNode, but it >> shouldn't actually hamper the functionalty. Unless there is a fatal >> problem, I really don't want to mess with the design anymore, as I >> already >> spent lots of time on it and could probably write an entire thesis on >> all >> the requirements, possibilities, and problems that arise from them. ;) >> >> thanks, >> >> Andreas >> > |
|
From: Ing. M. B. <mar...@gm...> - 2009-11-13 17:36:48
|
Hi Andreas.
I'm not guru in Simspark like you or Hedayat :) . But if you have a problem
with multiple inheritance, try this >>>
class Top {};
class Fork : public Top {};
class LeftBranch : virtual public Fork {}; //word virtual
class RightBranch : virtual public Fork {}; //word virtual
class Bottom : public LeftBranch, public RightBranch {};
Now, if you create instance of class Bottom >>>
Top* instance = new Bottom;
compiler get no error.
Best Regards
Marian
-----Original Message-----
From: ah...@un... [mailto:ah...@un...]
Sent: Friday, November 13, 2009 4:20 AM
To: sim...@li...
Subject: Re: [simspark-devel] APL Design
Hi,
> Sorry, would you please present an example of required diamond
> inheritance?
class Top {};
class Fork : public Top {};
class LeftBranch : public Fork {};
class RightBranch : public Fork {};
class Bottom : public LeftBranch, public RightBranch {};
In this case, Bottom is derived from Fork twice, once via LeftBranch and
once via RightBranch. This works in C++. However, when you write:
Top* instance = new Bottom();
You get a compiler error because Top is an ambigious base class of Bottom.
Simspark wants to do something like
zeitgeist::Object* = new Body();
and you get the same error at this point. You should be able to reproduce
it by deriving BoxCollider from both Collider and ODEObject in the current
version. It's nonsense, but it leads to ODEObject and everything above it
being ambigious base classes of BoxCollider.
> I wonder why abstract physics classes should be derived
> from BaseNode.
In order to add an instance of a class to the scenegraph, it has to be
derived from BaseNode. That's written in the documentation at some point.
This doesn't mean that the abstract classes have to be derived from there,
though. I tried an approach that derives the non-abstract classes from
BaseNode in a seperate tree and keeps the abstract classes as interfaces
and pointer-providers that aren't derived from anything. This, however,
gets very ugly because patterns like
boost::shared_ptr<Body> body = [...];
[...] body->GetSelf() [...]
can be found in many places outside of oxygen. GetSelf is specified in
zeitgeist, so if the inheritance from Body to BaseNode is cut, GetSelf
isn't known to Body anymore. Figuring out a design that derives Body from
BaseNode is by far the easiest solution to that problem.
I hope this answers your questions.
----------------------------------------------------------------------------
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus
on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Simspark Generic Physical MAS Simulator
simspark-devel mailing list
sim...@li...
https://lists.sourceforge.net/lists/listinfo/simspark-devel
__________ Information from ESET NOD32 Antivirus, version of virus signature
database 4593 (20091110) __________
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
__________ Information from ESET NOD32 Antivirus, version of virus signature
database 4593 (20091110) __________
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
|
|
From: <ah...@un...> - 2009-11-13 11:08:09
|
Hello, This is probably the final design for the APL. If no major objections are raised, I will start working with this on Monday. http://www.uni-koblenz.de/~aheld/APL%20final%20design.png As last time, non-continouus arrows denote that exactly one out of the possible inheritances is picked. If you have trouble understanding the lower right portion, try to imagine what the diagram would look like without either BoxCollider or SphereCollider. Note that this design completely avoids multiple inheritances. :) It will probably need a few more preprocessor commands, though. I apologize for sending so many mails, design proposals and questions to the mailing list. I had a very tough time during the last two weeks that consisted of making mistakes, learning from them, figuring out how to avoid them and then making new mistakes. I knew nothing about simspark and am still a very unexperienced programmer. One last thing to Hedayat: I think I misread your question. There are no required diamond inheritances, it was a requirement to NOT have them, as they caused problems that I couldn't solve. thanks for all the help I got so far, Andreas |
|
From: <ah...@un...> - 2009-11-13 03:20:28
|
Hi,
> Sorry, would you please present an example of required diamond
> inheritance?
class Top {};
class Fork : public Top {};
class LeftBranch : public Fork {};
class RightBranch : public Fork {};
class Bottom : public LeftBranch, public RightBranch {};
In this case, Bottom is derived from Fork twice, once via LeftBranch and
once via RightBranch. This works in C++. However, when you write:
Top* instance = new Bottom();
You get a compiler error because Top is an ambigious base class of Bottom.
Simspark wants to do something like
zeitgeist::Object* = new Body();
and you get the same error at this point. You should be able to reproduce
it by deriving BoxCollider from both Collider and ODEObject in the current
version. It's nonsense, but it leads to ODEObject and everything above it
being ambigious base classes of BoxCollider.
> I wonder why abstract physics classes should be derived
> from BaseNode.
In order to add an instance of a class to the scenegraph, it has to be
derived from BaseNode. That's written in the documentation at some point.
This doesn't mean that the abstract classes have to be derived from there,
though. I tried an approach that derives the non-abstract classes from
BaseNode in a seperate tree and keeps the abstract classes as interfaces
and pointer-providers that aren't derived from anything. This, however,
gets very ugly because patterns like
boost::shared_ptr<Body> body = [...];
[...] body->GetSelf() [...]
can be found in many places outside of oxygen. GetSelf is specified in
zeitgeist, so if the inheritance from Body to BaseNode is cut, GetSelf
isn't known to Body anymore. Figuring out a design that derives Body from
BaseNode is by far the easiest solution to that problem.
I hope this answers your questions.
|
|
From: <ym...@ho...> - 2009-11-12 15:32:11
|
您好!<br> <br> 您的邮件已收到!<br> <br> 感谢您的来信!<br> <br> 祝您工作愉快!<br> <br> 杨茂超!<br> <br> <br> <br> <br> <br> |
|
From: Hedayat V. <hed...@ai...> - 2009-11-12 15:31:46
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html style="direction: ltr;"> <head> <meta content="text/html; charset=UTF-8" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> Hi again :)<br> <br> On ۰۹/۱۱/۱۲ 04:05, <a class="moz-txt-link-abbreviated" href="mailto:ah...@un...">ah...@un...</a> wrote: <blockquote cite="mid:c35...@ma..." type="cite"> <pre wrap="">Hello, After working with multiple inheritances for a day and a half, I ran into new problems. Diamond Inheritances cause ambiguity problems due to Zeitgeist's design, and after cutting some inheritances, it led to the problem that some classes weren't derived from BaseNode anymore, and thus lost the functionality of a SceneGraph Node that they need to have in order to work. The ambiguity can be resolved with virtual inheritances, but then you get trouble with boost's static casts if they find virtual base classes down the line. Anyway, we had to come up with a new design that fulfilled three requirements: </pre> </blockquote> Sorry, would you please present an example of required diamond inheritance? I wonder why abstract physics classes should be derived from BaseNode.<br> <br> <br> Thanks,<br> Hedayat<br> <br> <blockquote cite="mid:c35...@ma..." type="cite"> <pre wrap=""> 1) All classes that I want to create objects of must be derived from a common base class, e.g. ODESphereCollider and BulletSphereCollider from SphereCollider. Necessary because calls like SphereCollider* soccerball = new ODESphereCollider() must work. 2) All classes that I want to create objects of, and the classes that these classes are derived from, must be derived from BaseNode. Necessary because the above mentioned ODESphereCollider must be added to the SceneGraph, and many, many external classes expect classes like Body, Collider or BallJoint to be derived from BaseNode. 3) When inheriting from multiple classes, the parent classes must not have a common Base Class. Necessary because of the ambiguity problems described above. Some people were against sticking to the old design. Even if I use the new design, I can still limit myself to the old functionality for the time being and add all the new stuff (like SoftBodies) as empty placeholder classes for the time being. When they're there, somebody can implement them later. We also looked at PAL. PAL uses virtual inheritances a lot to solve the ambiguity problems. (Actually, PAL was what made us know that virtual inheritances exist). All this led to the rather unorthodox design you can see here: <a class="moz-txt-link-freetext" href="http://www.uni-koblenz.de/~aheld/APL%20Design%20Sample.png">http://www.uni-koblenz.de/~aheld/APL%20Design%20Sample.png</a> Note that this omits a great number of classes for the sake of readability. The uncontinuous arrows denote that the child class will only inherit from one of these. E.g. when ODE is used, Body gets derived from ODEBody, else from BulletBody. The preprocessor will decide on that. The tasks of the non-engine-specific classes, like Body and BoxCollider, is to pick the correct base class, make sure that the leaf classes can inherit the proper engine-specific code, and provide the SceneGraph-related functionality that many external classes expect. I hope that I finally found a design that will work, since I'm feeling rather burned out. There are six DIN A4-sheets on my desk that all have UML diagrams on them, as well a few xmi files on my computer :P Like always, any objections/remarks are welcome. thanks, Andreas </pre> </blockquote> </body> </html> |
|
From: <ah...@un...> - 2009-11-12 12:36:08
|
Hello, After working with multiple inheritances for a day and a half, I ran into new problems. Diamond Inheritances cause ambiguity problems due to Zeitgeist's design, and after cutting some inheritances, it led to the problem that some classes weren't derived from BaseNode anymore, and thus lost the functionality of a SceneGraph Node that they need to have in order to work. The ambiguity can be resolved with virtual inheritances, but then you get trouble with boost's static casts if they find virtual base classes down the line. Anyway, we had to come up with a new design that fulfilled three requirements: 1) All classes that I want to create objects of must be derived from a common base class, e.g. ODESphereCollider and BulletSphereCollider from SphereCollider. Necessary because calls like SphereCollider* soccerball = new ODESphereCollider() must work. 2) All classes that I want to create objects of, and the classes that these classes are derived from, must be derived from BaseNode. Necessary because the above mentioned ODESphereCollider must be added to the SceneGraph, and many, many external classes expect classes like Body, Collider or BallJoint to be derived from BaseNode. 3) When inheriting from multiple classes, the parent classes must not have a common Base Class. Necessary because of the ambiguity problems described above. Some people were against sticking to the old design. Even if I use the new design, I can still limit myself to the old functionality for the time being and add all the new stuff (like SoftBodies) as empty placeholder classes for the time being. When they're there, somebody can implement them later. We also looked at PAL. PAL uses virtual inheritances a lot to solve the ambiguity problems. (Actually, PAL was what made us know that virtual inheritances exist). All this led to the rather unorthodox design you can see here: http://www.uni-koblenz.de/~aheld/APL%20Design%20Sample.png Note that this omits a great number of classes for the sake of readability. The uncontinuous arrows denote that the child class will only inherit from one of these. E.g. when ODE is used, Body gets derived from ODEBody, else from BulletBody. The preprocessor will decide on that. The tasks of the non-engine-specific classes, like Body and BoxCollider, is to pick the correct base class, make sure that the leaf classes can inherit the proper engine-specific code, and provide the SceneGraph-related functionality that many external classes expect. I hope that I finally found a design that will work, since I'm feeling rather burned out. There are six DIN A4-sheets on my desk that all have UML diagrams on them, as well a few xmi files on my computer :P Like always, any objections/remarks are welcome. thanks, Andreas |
|
From: <ah...@un...> - 2009-11-10 09:04:24
|
Hello, After taking a long and careful look at the source code and thinking about the greater picture, here are my conclusions. I'd like to (1) keep the current dependency tree for the abstract physics layer and (2) go crazy on the multiple inheritances. (1) - The current design is very well thought out and, more importantly, many other parts of simspark expect it. Any major changes in the dependency tree require adjustments in many other parts of the system, mainly the parsers and other plugins that work with oxygen. Also, with an abstract physics layer that stays true to the current design, it should be easy to integrate the current ODE-specific code into it. Any changes to the design require large parts of the current code to be rewritten - I can tell this from first-hand experience because I've been trying to apply the new design for about one and a half weeks before I decided to rethink it, and I still had many unsolved problems despite only focusing on basic functionality. (2) - I think it's pretty easy to argue that multiple inheritances are needed. As far as I know, there are only two ways for an object to call a non-static method: To implement it itself, or inherit from a class that implemented it. So, let's look only at PhysicsObject for now. It's a simple class providing some functionality that is the same for every physics object: finding out which space or world an object is in, or converting its rotation Matrix to something that Salt can work with. All these methods use ODE-specific code, so either every ODE-specific subclass implements it itself, or an ODE-specific superclass is implement that only ODE-objects, but not Bullet-Objects inherit from. The first possibility would generate more than three thousand lines of redundant code - and that's only talking about the ODE-specific part of the code equal for all physics objects. Also, multiple inheritances wouldn't be that convulted. The simple rule would be that every engine-specific class would have to inherit from its parent class, and all engine-specific subclasses of superclasses of its parent class. Sounds confusing, but it's quite easy: E.g. ODEBoxCollider would inherit from BoxCollider (parent class), and since Collider and PhysicsObject are superclasses of BoxCollider, it would also inherit from ODECollider and ODEObject. I will discuss this design with Joschka tomorrow, but you're welcome to tell us what you think, as well. thanks, Andreas |
45 messages has been excluded from this view by a project administrator.
![http://www.uni-koblenz.de/~aheld/APL%20Design%20Sample.png">http://www.uni-koblenz.de/~aheld/APL%20Design%20Sample.png</a>](http://www.uni-koblenz.de/~aheld/APL%20Design%20Sample.png">http://www.uni-koblenz.de/~aheld/APL%20Design%20Sample.png</a>){kind=link}
