Hi,

I’m working on creating an add-on for Blender that imports/exports AWD files. (The official blender exporter seems to be on hold so I figured I’d have a go of writing the tool myself). I’ve read the file format specification for AWD and wondered if the format is based on any of the more common formats like Autocad (DXF), Wavefront (OBJ) etc.

I ask because Blender already has support for some of these formats. If the AWD format is similar to one of those I’ll be able to use the scripts for that format as a starting point.

Can any one provide some guidance?

All 3d formats, at least explicit ones, are holding tesselated information.

Regarding mechanics, obj isn’t anywhere near awd, as it represents only geometry and eventually material(s) if an mtl is provided. No scenegraph and all data transforms are prebaked. This means that all the data is considered at scene level. In practice, you can extrapolate per object its position based on its object bounds, but you would not be able to extract its original rotation or object data pivot point. Obj format is nice for single object as an exchange format.

DXF, at least not using the facedata tags, is way more intelligent and uses relationships as awd does. In DXF the objects relationship may be async or using arbitrary keys while awd uses a simple zero based system where the exporter code is the one working harder, so that runtime parser has the least work to perform. Meaning here that it is expected to encode the data in the inverse order of their construction.

Both are ascii based, awd2.x is binary (awd1.0 is ascii)
A dxf file is more or less, 6 to 7 times bigger than an awd file. Not just because of the logic, but because companies like AutoDesk do store some of the original exporter application data (and more proprietary, undocumented data shared across their tools chain) in there.

for instance a simple awd of a single mesh with a TextureMaterial will look like this
header (magic, byteslength, version)
block id 0, type Texture
block id 1, type Material
block id 2, type MeshData
block id 3, type Mesh
EOF

each block may hold a simple ref to the data it needs, for instance
mesh will hold id 2 for its geom block pointer and 1 for its material, material id 0 for its texture…

Unlike DXF, If there are 7 blocks, there will always be 0/6 id’s.
Each block has a consistent header, the type defines it’s own encoding.

Hope it helps…

I have been tinkering with Blender’s DXF import/export scripts; re-factoring them for AWD import/export. Wasn’t sure if I was on the right track but I feel more confident moving in this direction thanks to your post.

So thanks for responding Fabrice. I’ve followed your work with Away3D over the years. What happened to your BSP tree experiments? Away3D 4.0 doesn’t seem to have that stuff integrated.

May be one day…   Most credits for hard and smart work goes to David here.

Btw, you know there is a blender awd exporter somewhere, its no longer compatible with latest version, but surely a nice base to work on…

https://code.google.com/p/awd/source/browse/sdks/python-pyawd?r=c68a33b3e1ac15d8e45e8707fd21b1f90cf98a0f