Nate has good points here. Gazebo should rely on Orge3d to do its basic geometry loading. Collada is an exchange format and it should be pretty straight forward to write converters for a Gazebo particular world format. The basics that Gazebo needs are:
1) scene specification: * location/geometry/textures of non-robot objects (ground, sky, walls, pickup items, etc.) * starting location of bots * physics specs for those things (non-movable, gravity, friction, elasticity, etc) much of this can be gleaned from other 'standards' pity there isnt a good generic one, yet. Borrow what you can. 2) Bot specification * geometry/textures, articulations (named sub parts), * kinematics (joints, etc) * sensors: type, location, ids, params (power, range, freq, etc) * dynamics: motor speeds, traction/flight dynamics Dynamics opens the pandora box for lots of other stuff, like scripted behaviors for non-bot entities. Put the hooks in but leave details for later - eg a Python interface. On 8/11/06, Nate Koenig <[EMAIL PROTECTED]> wrote: > Let's take a step back for a moment, and consider what gazebo really > needs in a XML format. We will have two types of files, one that > describes the world and one that describes a model. A model is > collection of bodies connected via joints and zero or more sensors. A > world is a collection of models along with some global parameters such > as gravity. > > We don't need collada or X3D to specify the world. Our current format > is pretty good. > > For the model file, we may not need Collada or X3D. Ogre3d allows us > to directly load meshes from file. So a body's geometry will now be > specified by a mesh file. This mesh can be created from almost any 3d > modeler, such as blender. So a model file will contain the following: > 1) 1...N bodies, where each body contains a mesh file, and some > simple properties such as scale, position, color, texture, mass, etc. > 2) 0...M joints, where each joint connects two bodies together via a > specific ODE joint type. > 3) 0...K sensors, where each sensor contains a position on the model > and a sensor type. > > I see collada working well with 3d modelers, but that is not what we > are creating. At the most we will load a collada file generated by a > 3d modeler through Ogre3d. Our application is specific to robotic > simulation, we probably don't even have to mess around with a standard > 3d Model data format - just let Ogre3d take care of loading meshes and > 3d modelers creating them. > > -nate > > > > On 8/10/06, Jordi <[EMAIL PROTECTED]> wrote: > > > > > > > If you're considering Collada, then I suggest also considering X3D (used > > > to > > > be called VRML... remember that? :) > > > > Yes, remember that. > > A standard is something that most people use to make things easier, it is > > not > > something done by a "standard creation group". I think that VRML and X3D has > > so far failed to become a standard. > > > > Anyway, we are not the first ones wondering about COLLADA - X3D : > > http://partners.epoch-net.org/common_infrastructure/wiki/index.php/File_format:_Collada_vs._X3D > > http://uvvy.com/index.php/3D_format_wars > > > > Both are similar but _it seems_ that COLLADA is being used by far more > > projects even when it is newer than X3D. > > My vote go for COLLADA. > > > > > > Looking for more info about X3D, I have found this: > > > > "Yes, both X3D and COLLADA are using XML, and both X3D and COLLADA can > > represent 3D. > > But concluding that COLLADA is just another name for X3D is wrong. There are > > many important diffecences in the design. > > The main difference being that if X3D is designed as the standard 3D format > > for the web, COLLADA is designed as a intermediate file format in the > > content > > pipeline. > > In other words, those are compimentary efforts, and it is even better if it > > is > > easy to convert COLLADA back and forth in X3D. In an ideal world, data will > > be available in the COLLADA format, and converted into X3D or other formats > > that are specifically designed for a given target. > > Of course, it is always possible to write exporters from any tool directly > > into X3D, without using COLLADA. But instead of writting one exporter for > > each tool, maybe it is better to write one tool to convert from COLLADA, and > > use the COLLADA exporters/importers provided and supported directly by the > > tool and middleware vendors." > > > > -- > > Jordi Polo > > > > ------------------------------------------------------------------------- > > Using Tomcat but need to do more? Need to support web services, security? > > Get stuff done quickly with pre-integrated technology to make your job > > easier > > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > > _______________________________________________ > > Playerstage-gazebo mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/playerstage-gazebo > > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Playerstage-gazebo mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/playerstage-gazebo > ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Playerstage-gazebo mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/playerstage-gazebo
