AWD2 finalization: How I just broke your build

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!

AWD2 has been working in Maya for about 8 months. However, because the format has been work in progress, I have not created any installers or similar. My next steps will be to make get the existing exporters (blender, Maya) start working back to a work state with the new format/SDK, and then improve on them and create installers et c.

I’m expecting they will be up to speed with the SDK changes at the end of this month. At that point I can start preparing the Maya exporter for proper release. The blender one still needs some work and is far from feature complete.

Also, when you mention “i.e. for a future WebGL implementation”...it makes me curious… Do you mean a Javascript implementation of the AWD2 format. Or for a WebGL renderer for Away3D.. I.e. through something like the FalconJS compiler?

The plug-in is online at Google Code, but we’ve been getting reports of crashes on some users’ machines so expect updates soon.

By “WebGL implementation” I mean a way to load AWD2 files and display them in WebGL. There are no official plans at this time to create a full Away3D port or anything like that, but we see no reason why Javascript coders shouldn’t be able to benefit from the AWD format so expect some sort of move in that direction at some point.

Same thing here, I tested it yesterday(64), with a mesh character, it worked. Today, it crashes. I notice the plugin is marked deferred in the max plugin manager. Just install the mas 32bit version, it crashes too.

just want to say we also develop projects in webgl with three.js and would LOVE to have awd2 format for javascript. Would use it without any hesitation if it was available. please make it a priority if you can… we also use blender, so please give it’s exporter all you’ve got, hehe.

Thanks for this fix ! However I have some strange mapping issue in the exporter viewer. I’m not able to have something correct. I didn’t try to load my mesh in a ‘real project’. Perhaps it will solve this ?
Any Idea ?

I’m afraid I can’t know what the issue is unless you elaborate on what exactly is going wrong and how. Maybe you can upload a screenshot? If you believe it’s a bug in the exporter, please file a bug on the AWD google code page and link to the screenshot as well as any other related files that you deem important.

If you are talking about UV mapping, make sure you don’t rely on UV transformations (such as scaling the entire UV set, et c.) Please try to instead apply such transformations to the actual UV coordinates.