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!

I’m using the latest version of bulletphysics (2.80) and have made the modifications as outlined in awayphysics’s bulletModification.txt. Next I tried compiling with cmake, but am getting errors.

- Has any work been done to port over the Extras in bulletphysics?

- What was the process for creating the .a and .l.bc library files? (i.e. did you use cmake?)

Thanks!
~MD

I’m trying to apply some bloom or dof filters on my view, but the app doesnt work anymore when i do that :

view = new View3D();
  view.scene = scene;
  view.camera = camera;
  view.antiAlias = 4;
  addChild(view);
view.filters3d = [new DepthOfFieldFilter3D(3,3)];

it seemed quite easy…
did i do something wrong?
thanks for your lights

I’m creating a game which uses a ball that’s being shot at a target.
After a shot the ball should go back to the startingposition and must be ready to shoot again.

I use this code to reset the ball:

This doesn’t work as I had hoped. it works most of the time, but sometimes the ball gets moved back to the startposition, but then the ball continues to bounce in exactly the same direction as it was going before the transfer to the startposition.
My guess is that the movementspeed and direction somehow isn’t removed and continue to apply to the ball when reset to the startposition.

I thought my code above was a way to deactivate all forces, but appearently not.
So is there a way to completely remove all forces that are being applied to the ball?

I have a rope, created with many AWPPoint2PointConstraint as in the ConstraintTest example, with a RigidBody attached to each side.
I would like the rope to hang from one of them (and then move the ‘hang’ with keyboard input).

I’m wondering what’s the best way to define that rigidbody position in space, without the gravity affecting it while still being part of the physics world?

TIA

Thank you in advance for your replies.

Thanks.