I wanted to let everybody know that as of a couple of weeks ago, the final AWD2 format has been locked down. This meant some last minute changes that have been brewing for a while, and as it often is with binary files, these changes are not backwards compatible. Let me explain.
The process
The AWD2 file format has been a work in progress for about a year now. Almost since day one, backwards and forwards compatibility have been major goals for the format. Because of this, we needed to be really happy with the format before locking down the 2.0 version, because we can’t make any breaking changes to it after that.
Over the past two months I’ve been working on a 3ds Max exporter, and in the process, have been finalizing the structure of the file format. Part of this work was making a couple of changes to the format that needed to be done before it was locked down. These were changes that will aid in keeping the format backwards compatible, but the changes themselves were not backwards compatible with the work-in-progress state that the format has been in for a couple of months before these changes.
What were the changes?
The changes involved a number of things, some of which are listed below:
- The entire file format is now little-endian instead of big-endian. Big-endian is traditionally recommended for streaming, and this is the reason it was originally chosen for AWD. However, having thought this through again, I concluded that the effect that endianness has on application-level streaming is very small, and since most devices nowadays use little-endian the performance benefits of making the format little-endian outweighs the tiny restrictions imposed on streaming. This will allow for future optimizations of encoding and decoding, especially in languages like Javascript (i.e. for a future WebGL implementation.)
- The “optimize for accuracy” flag for geometry and matrices have been removed in favor of per-block and per-stream (see below) equivalents.
- Data streams (basically the geometry data like vertices, indices, UV coordinates et c) are now data-type agnostic. This means for example that vertex positions can be stored as integers if the encoder wants to. This improves our ability to change the way data is encoded in the future, and it allows encoders to optimize for size or accuracy on a per-stream basis.
- Most blocks that define 3D transformation now use 3x4 matrices instead of 4x4 matrices. For skeletal animation this can reduce the file size with 25%!
What does this mean?
This means that if you pull from GitHub today, you will get an AWD2Parser that will no longer be able to parse your existing AWD files. You will be getting weird runtime errors whenever you try to load an “old” AWD2 file.
Existing content
For your current short-term projects I recommend that you stick with the old AWD2Parser. If you want to stay up to date with the rest of Away3D, pull as usual but check out an older version of just the AWD2Parser.as file and keep that around.
For long-term projects, schedule a conversion (re-export) of your AWD2 files as soon as the necessary changes have been made to your exporter of choice. Right now, the only exporter that is guaranteed to work with the new format is the Max exporter that will be released in the next couple of days. Other exporters (blender, Maya) have not yet been tested with the new AWD SDK after the changes. I will post in this thread once they are stable.
Going forward
This is intended to be the last breaking AWD2 change ever. From now on, the plan is for the format to be backwards and forwards compatible throughout it’s lifetime.
Because the SDK is now “stable” (in terms of the format of the files that it generates) focus will now be on further developing the tools that use the SDK (i.e. exporters and utilities) as well as documentation.
Sorry if this causes any inconvenience in your projects. Thanks for your understanding!
we also use blender, so please give it’s exporter all you’ve got, hehe.
