| Q&A |
 OGREMAX,
Derek Nedelman,
July 2009 |
| |
 |
“
My number one goal with OgreMax has been to provide
a complete path for creating and moving assets from
3DS Max, Maya, and XSI to an Ogre3D-based application.
”
<
OGREMAX for Softimage in action |
|
| |
|
| Q1 |
Why
have you developed OgreMax, a suite of tools that exports to
the Ogre3D graphics engine? |
| A1 |
I
developed OgreMax after I began using Ogre3D and discovered
it didn't have a 3DS Max exporter that allowed me to export
a scene (meshes, cameras, lights, animations, among other things),
process it (by changing the up axis, rescaling units, merging
meshes, and so on), load it into an external viewer for inspection,
and then load it into my own application. Before creating OgreMax,
I tried to get this type of functionality by piecing together
an assortment of exporters, viewers, and scene loaders of varying
quality, and of course nothing worked very well, if at all.
|
| |
|
| Q2 |
Importing
assets is a key component of the 3D pipeline. What are your
principal goals? |
| A2 |
My
number one goal with OgreMax has been to provide a complete
path for creating and moving assets from 3DS Max, Maya, and
XSI to an Ogre3D-based application. |
| |
|
| Q3 |
OgreMax
is available for 3DS Max, but versions are also available for
Maya and XSI. Why support all these applications? |
| A3 |
The
first version OgreMax was released over two years ago as a simple
3DS Max-only exporter. Its feature set grew rapidly and after
nearly a year of development it became apparent that the original
program design needed to be overhauled in order to accomodate
more features (the real-time viewports, in particular). Before
moving on to this phase, I decided to try out the existing Maya
and XSI exporters for Ogre3D. None of them did what I wanted
so I decided that since I was going to rewrite the OgreMax exporter
for 3DS Max I would also create Maya and XSI versions. Having
used their software development kits in the past I knew that
it would be possible to implement most of the features OgreMax
already had. |
| |
|
| Q4 |
With
regards to porting OgreMax to the different applications, could
you please give us your feeling about the 3DS Max, Maya and
XSI SDKs? |
| A4 |
It's
easiest to summarize my feelings with a list of pros and cons
for each SDK:
3DS Max SDK
+The most comprehensive SDK. It works far better than the
others because it allows you access to nearly everything.
+Has a pure C++ interface which means all plugin code can
be written in the same language, resulting in easier debugging
and a faster run time.
+The simplest scene graph traversal.
+The simplest data storage methods.
+The simplest user interface handling. User interface elements
are created within Visual Studio's resource editor, which
means there's less guessing about how things will look.
+Contains lots of sample code.
+Everything is compiled into a single plugin file. This makes
manually installing OgreMax very easy.
-The programming interface is complex and messy.
-Lots of code needs to be written when creating new object
and material types.
-Compile times are very slow compared to the other SDKs.
Maya
SDK
+Has a well-defined and clean programming interface.
+New object types require very little code.
+Easy to add custom commands.
+Compile times are the fastest of the three SDKs.
-User interfaces need to be written in separate MEL script
files, which results in a slower run time.
-Creating and accessing some data types is difficult and/or
strange.
-Traversing the scene graph is tricky.
-Some functionality is not accessible through the C++ API
and must instead be accessed by dynamically executing script
code.
-Custom viewports are not supported. There's a somewhat similar
custom renderer feature that OgreMax makes use of, but it's
slow and not very useful.
XSI
SDK
+New object types require very little code.
+Easy to add custom commands.
+Fast compile times.
-Custom materials and shaders must be implemented in separate
script files, which is error prone since all the code that
accesses the material data is written in C++.
-User interfaces need to be written in separate script files,
which results in a slower run time.
-Parts of the user interface in the property page cannot be
destroyed and recreated dynamically.
-XSI's custom user interface styling causes problems with
many of the OgreMax dialogs. The SDK provides a way to toggle
the custom styling, but this results in the OgreMax dialogs
looking completely different than the XSI dialogs.
-Inconsistent notifications. Some internal notifications only
occur if at least one embedded OgreMax scene window is open.
This requires workarounds in the code for the case that no
such windows are open.
-No way to hook into material editor 'node' menus. This makes
creating OgreMax materials a little more time consuming for
the user than they need to be.
-Some functionality is not accessible through the C++ API
and must instead be accessed by dynamically executing script
code. |
| |
|
| Q5 |
OgreMax
exports most of the 3D scene details: objects, animation, bones,
lights, cameras. It also has a real-time preview (through the
use of custom scene viewports) that allows users to view the
scene before exporting. These are very advanced features for
a free tool. Which feature of OgreMax are you the most proud
of? |
| A5 |
I'm
proud of a number of things:
-I'm proud that there are now three OgreMax exporters that provide
what I originally wanted: a path for creating and moving assets
from a 3D content creation application to my own application.
-I'm proud that all three exporters offer such an extensive
feature set and uniform user interface. The Maya and XSI exporters
are identical, and they each have roughly 95% of the features
that the 3DS Max version has. This makes it very easy for artists
to move from one tool to another if necessary.
-I'm proud of the fact that so many people have adopted OgreMax
as their primary toolset. |
| |
|
| Q6 |
Ogre3D
.scene and .mesh formats specifications change frequently (OgreMax
supports Ogre 3D 1.6 & 1.7). Do you think that they are
the best formats for a 3D pipeline? What about intermediate
formats such as FBX or Collada? |
| A6 |
Any
successful format needs to evolve over time, so the fact that
.mesh and .scene are changing is a very good sign. It's shows
that the formats are being adapted to people's needs.
The FBX and Collada formats are perfectly acceptable as an interchange
format for 3D content creation applications, but they will typically
not be used as a final format. For example, if you were developing
a game you would most likely write tools to process FBX/Collada
files, removing excess data and eventually saving to a format
that your game can read. There are a couple of problems with
this approach, however:
1)You still need to write tools - Depending on your needs, you
may be able to get away with something simple such as reading
the FBX/Collada files and then writing out a few lists of data.
On the other hand, you may need more functionality, such as
being able to join together meshes, or rescale the scene. These
types of tools may require a graphical user interface, which
can take more time to create. Also, many types of operations
seem simple at first but become very complex. For example, rescaling
a scene seems simple until you realize that rescaling affects
mesh vertices and all their animations, skeletons, cameras,
lights, and all their related properties. Creating and maintaining
the tools can become a full-time task.
2)Designing file formats is difficult - Again, if your needs
are simple then this may not be an issue, but for all but the
simplest programs creating and maintaining file formats can
be even more difficult than creating the tools that use those
formats.
3)Do you really want to create tools? - Why do all that work
if you don't have to?
For most situations the Ogre3D formats are the best choice since
they have been in use for years, and there are already tools
such as OgreMax you can use to generate that type of data. |
| |
|
| Q7 |
What
is the license of OgreMax? Are you proposing commercial services
around OgreMax and Ogre? |
| A7 |
The
OgreMax exporters are free to use for any purpose, with the
exception that they not be redistributed or resold. The OgreMax
viewers and their source code are free to use for any purpose
with the condition that you give credit in your application
to OgreMax.
By the middle of August, the exporter source code will be available
for licensing. In addition, paid support will be offered. |
| Q8 |
Ogre3D
benefits of a large user community and has a lot of tools for
exporting assets. But more generally, do you think that the
creation of export tools is the job of the 3D application creator
(Autodesk, for example) or the 3D engine maker? |
| A8 |
The
best thing 3D application creators can do is create full featured
SDKs for their products that allow 3D engine makers or anyone
else to create the type of tools they need. |
| |
|
| |
|
 |
|
|
