Home › Blender DTS Exporter 0.97 Documentation Index › Changes from earlier versions

Rationale for Changes

Sun, 01/11/2009 - 17:12 — Joseph Greenawalt

This page contains the reasoning behind the changes in version 0.97 of the exporter.

Defining Detail levels

Change: Empties are no longer used to define detail levels.  Detail levels are now defined through the exporter GUI using Blender's scene layers.

Reasoning: New users often want to just "hit export and have it work".  Requiring new users to understand scene hierarchies and object parenting in Blender right off-the-bat is an unnecessary bump in the learning curve.  People who are evaluating the Blender->DTS art pipeline often came away with a negative impression, thinking that the exporter didn't work. 

  Pros Cons
Old exporter behavior
  • Automatic scene setup routine would automatically set up the "marker" empties needed to define a dts shape (but only once, the first time the exporter was run for that file).
  • The shape hierarchy was easily viewable in the Blender outliner window.
  • Similar but not identical to the way 3ds-max scene setup works.
  • Required new users to understand object hierarchies and parenting in order to export their models to the DTS format.  This was somewhat mitigated by the introduction of automatic hierarchy setup in version 0.96 of the exporter, but new users were still left confused when newly added objects failed to show up in the export.  Getting the automatic scene setup routine to run again required deleting all "marker" empties, followed by saving and reloading the .blend file twice.
  • New users often want to just "hit export and have it work", similar to the way the other Blender exporters operate.  The old behavior did not allow for this, and required knowledge of both parenting and some internals of the DTS file format
  • Required workarounds for animating collision meshes
  • Required "linked copies" of armatures for each detail level
  • Required all dts objects (meshes) to have a version present in the highest LOD to serve as a template for other LODs.
New exporter behavior
  • Allows for easy export of arbitrary blender scenes.
  • Allows for more flexible object hierarchies, an often requested feature.
  • New users can just hit "export" and end up with a valid dts file without any fore-knowledge of the dts file format.
  • Allowed workarounds for animated collision meshes to be removed from the exporter source code.  Collision meshes can now be animated like any other mesh.
  • New objects that are added to a Blender scene are now picked up automatically by the default "detail1" detail level, which covers all scene layers.
  • There is no longer a need to create linked copies of armature objects for different detail levels, all LODs can now share a single armature (or multiple armatures if desired).
  • Objects can be excluded from export by moving them to a scene layer that is not in use by any detail levels.
  • Detail level setup is now (arguably) easier.
  • Shape hierarchy is no longer easily visible in the outliner window; users must remember which layer corresponds to which detail level, or look in the exporter GUI if they forget.  This drawback will (hopefully) be solved if/when Blender gets named scene layers
  • Loss of backwards compatibility with older shape files.  This is somewhat mitigated by the fact that most people who are working with multiple LODs are probably using separate scene layers for each LOD anyway.  It still requires some manual work to convert older files to the new system though.
  • The old naming convention for grouping Blender meshes into dts objects across detail levels still applies; I couldn't think of a better/easier way of doing it.

Geometry and Object Types

Change: In addition to meshes; Text Objects, "Meta Objects", and NURBS Surfaces can now be exported directly.  All modifiers are taken into account.

Rational: The more Blender object types that can be exported directly, the better.

Pros/Cons: NA

 

Change: "Triangle Lists" is now the default packing/rendering mode for all geometry.

Rational: Better performance by switching to a more efficient geometry packing mode as the default.

  Pros Cons
Old exporter behavior Backwards compatible with versions of TGE older than 1.5.1 by default Very slow rendering and performance issues
New exporter behavior Rendering meshes using triangle lists instead of "triangles" or triangle strips gives higher frame rates on most graphics hardware. Users of older versions of TGE need to apply these fixes to their source code, or change this setting manually for each new file.

 

Change: Mesh flags are now handled through the use of Blender's game properties instead of a special suffix on object names

Rational: Mainly done to simplify object name parsing in the exporter source code; also, having mesh object names with a "." suffix (for detail level dts object grouping) followed by an "_" (for mesh flags) may have been somewhat confusing.

  Pros Cons
Old exporter behavior
  • Easy to tell which meshes were "billboard" and "billboardz" meshes just by looking at their names.
  • having mesh object names with a "." suffix (for detail level dts object grouping) followed by an "_" (for mesh flags) may have been somewhat confusing; too many things dependent on special mesh names.
New exporter behavior
  • Allowed for the object name parsing in the exporter source code to be simplified.
  • No more "myMesh.LOD1_BBZ" style mesh names.
  • Not as easy to see which meshes have BB or BBZ flags set.

Nodes

Change: Nodes are now generated for every object by default.  Named Empties and other types of objects can now be used as nodes.

Rational:  The ability to create sequence by animating blender objects directly on the NLA timeline was an often requested feature.

Pros/Cons: NA

 

Change: It is no longer necessary to create a linked copy of an armature for each detail level.

Rational: Simplifies setup of skinned meshes across multiple LODs.

  Pros Cons
Old exporter behavior
  • None that I can think of.
  • Confusing; required reading docs
  • Active actions could not be easily synced for all linked copies of an armature
New exporter behavior
  • Easier; one armature can be used for all LODs
  • Old shape files must be updated by hand.

 

Animations

Changes:

  • The exporter can now export object level keyframe animations (loc, rot, and scale) for Blender objects in addition to bones.  This means that objects can now be animated directly without parenting to bones or skinning.

  • Export of "floating actions" that are not anchored on the blender global timeline is no longer supported.  I wanted to retain this animation mode, but due to some problems was forced to leave it out.  Action Animations should now be laid out on the global timeline as action strips.

  • Because objects don't have a "default position" the way that Blender's bones do, frame 1 on the NLA timeline is used to define the rest postions rotations and scales for all blender objects and bones.

  • Sequences are now defined by placing markers on the global NLA timeline to indicate the start frame and end frame of an animation.

Rational: This was an often requested feature.

 

  Pros Cons
Old exporter behavior
  • Easy to create new sequences by creating a new action (if you knew how)
  • Using the edit mode positions of bones as their default positions was sometimes problematic, especially when constraints immediately pulled those bones out of their edit mode positions when switching to pose mode.
  • Actions are limited to bone animations ("object actions" are nearly useless), meaning that objects couldn't be animated directly
  • Action poses had to be reset by the exporter in between each sequence export to avoid non-deterministic behavior when sequences were exported in a different order.  This meant that the user had to be aware of this, and manually clear user transforms on an armature when switching between actions in order to get an accurate idea of what actions would look like after export.
  • Blender's Python API provides no means to determine which actions are associated with which armatures.  This limitation meant that the exporter had to assign every action to every armature in the scene when exporting, resulting in animation "crosstalk" problems if multiple armatures shared the same bone names; plus, it's rude for the exporter to be altering the user's data, even if it's necessary.
  • The process for creating a new action is a bit confusing, since "add new" copies the current action under a new name.  I was confused by this myself when I first started using Blender a few years ago.
  • Easy to get a default position for bones using their edit mode positions.
New exporter behavior
  • Blender objects can now be keyframed (animated) directly.
  • Exporter is not nearly as "finicky" in regards to armature transforms and armature object keyframes; armatures can now have object level keyframes without messing up exported animations.
  • Allows for the more advanced Blender NLA animation tools and timeline to be used for creating DTS node animations.
  • Generating a node for each blender object by default is more similar to how other DTS exporters for other modeling packages work.
  • Allowed for removal of workarounds and simplification of animation code in the exporter.
  • Much, much closer to "wysiwyg" animation export.
  • Setup of animations for export is somewhat more labor intensive; this is mitigated a bit by the automatic setup tools provided in the "Sequence Properties" panel of the exporter
  • Old animations need to be updated by hand; new tools are provided on the "Sequence Properties" panel of the exporter GUI, but some manual work is still involved.
  • Timeline marker names tend to overlap each other, making them difficult to read sometimes.

Change: Animation Triggers are now created by placing named markers on the timeline.

Rational: The "triggers" controls in the exporter GUI were confusing and difficult to use; using timeline markers is (hopefully) more intuitive and allows for a simplified sequences GUI.

Pros/Cons: NA

 

Closing Thoughts

It is my sincere hope that all or almost all of the changes that I've made for this version of the exporter are seen as improvements over the way things were done in previous versions of the exporter.  I realize that the pros/cons of some of these changes are a bit dicey.  If you feel that I have mis-judged or made mistakes in my reasoning, feel free to email me with your questions, thoughts, or concerns at jsgreenawalt@gmail.com.

If you have a large number of models that are set up for the old exporter versions, I realize that it may be a ton of work to convert them to the new setup.  In such a situation, I would recommend staying with the 0.96x exporter version(s) until you are finished with your current project.