Just Launched: You can now import projects and releases from Google Code onto SourceForge
We are excited to release new functionality to enable a 1-click import from Google Code onto the Allura platform on SourceForge. You can import tickets, wikis, source, releases, and more with a few simple steps. Read More
From: Nathan Michael <nate.michael@gm...> - 2007-07-16 05:31:23
I spent a little while going through the SVN gazebo today had some
success on Mac OS X. I ran into a few problems too which I started
working on trying to fix and came up with some questions.
1. I'm having issues with the current GUI. Basically, the GUI is not
becoming interactive and is running in the background while the
gazebo is running in the terminal. I started working on a CEGUI/Ogre
GUI and have had some success. I ran into a problem that the Observer
cam wasn't working on my system so I hacked at it and seems to be
working OK. I'm compiling the GUI as a native OS X application but I
figured out how to compile through applescript such that I can check
via scons for the platform and compile the GUI for OSX or Linux
depending on the platform. Is this something that would be useful? My
major concern is that I need to change the frame listener and I'm
also incorporating CEGUI bits (a button to quit, etc.). This means I
would need to change a good bit of the rendering source code and add
a dependency. This train of thought prompted the next question.
2. The idle loop in the gazebo calls update which then calls the
world file and eventually the rendering code. This would need to be
changed a bit to make it so that the renderer could have its own
loop. My thought was that the world and physics engine updates could
be in a separate thread and the rendering loop would interface to
that thread in a very similar way to wxgazebo. This also seems like a
solution for permitting gazebo to run without a need for rendering.
It may also start to address the multi-threading you mention in the
3. I noticed in the TODO file you have a number of physics engine
packages listed. I thought it may make it easier to switch between
engines if it is only an xml flag so I went ahead and moved all of
the dependence from ODE to just in the physics directory and changed
how the physics engine interacted with the world, sensors, and the
underlying engine (ODE). Is that direction you were thinking of going
or did you have something else in mind to permit multiple engines?
I can take care of all of the things I mentioned but they will result
in some big changes to the source in select locations. I wanted to
get your thoughts on this before I start to dive in.
Also, I've updated scons to support OS X as another environment.
Please let me know how you prefer changes/patches to merged (via svn
check-in, patches, etc.). I can send them to you as well if you would
like to review them.