[simspark-devel] Simspark / Soccer3d differences

[Markus R. <rol...@un...>]

Hi all,

in order to set up a todo list I looked through the diff between our
two repositories (simspark and soccer3d)

There are a whole bunch of compile fixes (f), small additional helper
functions (h) and renames in the simspark repo. But there are also
some new concepts (c) and reorganizations.

[Salt library]

- (h) matrix.h InvertMatrix()

[Zeitgeist library]

- (f) class: {h,cpp}: removed some static shared_ptr instances, their
use count never gets zero resulting a memory leaks

- (h) core: catchsignal() implements a stack walker that dumps the
callstack if the server crashes (using the gnu addr2line tool)

- (c) core: keep track of already loaded bundles. The server happily
reloaded bundles multiple times

- (c) core, class: Registry of cached path name lookups. In the
soccer3d repo every node implements the lookup and caching of paths
itself (e.g. to well known server locations). This is now moved into
the core and allows a refresh of all cached paths with a simple
function call(). This change affects the whole tree, but is only a
small change to most classes.

- (h) node, leaf: GetnumberOfChildren()

- (c) leaf: assure that each child node has a unique name. Check for
name clashes and append a numeric postfix (i.e <name>1, <name>2)

- (f) various compile fixes for win32 build

[Oxygen library]

- (c) class TransformCollider. This class implements the Ode transform
collider concept for composite bodies. For this class to work various
other classes need to be adapted to be aware of a TransformCollider. I
think Sander already made a patch to port this to the soccer3d repo?

- (c) OdeObject and all derived classes: The destruction of managed
ODE objects is moved from the destructor into a separate virtual
function DestroyODEObject(). This is necessary to destroy all ODE
object in the scene in a defined order if the scene is rebuilt (e.g. a
robot that is contained in its own Space is dropped from the scene)

The major problem was that an ODE space must not be destroyed before
all contained ODE objects are destroyed (this resulted in crashs
within ODE). Currently this is not an issue for the socced3d
simulation as robots usually connect and are never destroyed again
during one server run. Unlinking a Space node and recursively
destroying all child nodes did not achieve this. See (space.cpp
Space::DestroySpaceObjects()) for the implementation.

- (h) body: Several additional wrapper methods for ODE mass
calculation Addphere, AddSphereTotal, AddBox, PrepareBoxTotal,
AddBoxTotal, AddMass...

- (h): SynchronizeParent() factored out from
PostPhysicsUpdateInternal()

- (h) camera: new LookAt() function that points the camera to a given
coordinate

- (c) FpsController: The FpsController gained a 'static update'
functionality. This enables the controller to be moved even if the
simulation is paused. In the soccer3d repo camera movement is
implemented using an ODE body. The updates of the controller therefore
only work if the simulation is running. If you pause the simulation
the camera position freezes.

- (c): The SceneServer maintains a 'scene dictionary'. The idea is to
keep track by which specific line of source code (e.g. rsg file) any
given object was created.

Each importer therefore enters the needed information into the scene
dictionary of the scene server. This is a weak mapping from 'leaf
pointer' to a file reference. A file reference is the name of a source
file and a line number.

This functionality allowed rsgedit (the spark gui tool) to show the
source code location for any object you double clicked. Maybe this
functionality is stil valuable for debug purposes? (e.g annotating
scene dumps)

[kerosin library]

- (c) OpenGLSystem: The setup of the opengl output windows was
factored out into a separate OpenGLSytem class. This was useful to
implement different opengl system (the classic SDL based, a wxWidget
win32 based and on Ogre [1] based for Mac OS X)

- (C) MaterialExternal: Oliver implemented a set of helper classes to
use material systems from the OpenGLSystem used. In his case he used
the Ogre materialsystem and translated our material definitions using
these classes.

The above list should serve as a rough overview and todo list to
cherry pick changes from the simspark repo into the soccer3d repo (if
we choose to stay with the current repo)

cheers,
Markus

[1] http://www.ogre3d.org/