Hi, I have researched different ways of getting data into Away3D (being responsible for the AWD file format that is currently under development.) The AMF solution is not actually the best solution at all, because it adds a couple of restrictions on the parsing engine. The only way to make it work in a long-term way is to have an intermediate structure of value objects, and seeing as how AMF is not actually as compact as you might think, the benefits do not outweigh these issues.
I'm gonna go out on a limb and guess that you might have heard about the AMF approach at Mike Jones' session at FITC Amsterdam today? If you're around, look me up. I'm one of the guys in an Away3D shirt. :) Like you say, Away3D 4.0 is currently alpha, and as such does not yet support all the formats that we plan to eventually support. We will have full(ish) support for COLLADA, 3DS, MD5, OBJ, et c eventually, but the real thing to keep your eyes on is the AWD2 format. AWD2 is actually more compact, and faster to parse than most mainstream formats, including if you compile your model from AS3 into a SWF file. It's also very comparable to AMF, but more compact and without any of the drawbacks in terms of requiring intermediate objects, spreading parsing responsibility across the entire framework et c. AWD2 is currently work in progress, but there will definitely be an exporter for Blender before too long. Also, if you want to stick to Blender, you should be able to create (or hire someone to create ;)) an exporter to a tailored format, or AWD2, in just a couple of days. Cheers /R On Mar 9, 2:40 am, Dave <[email protected]> wrote: > I'm new to Away3D. I'm attempting to adapt an existing application & > assets to Away3D from (a modified version of) Papervision. > > Our old codebase was loading Collada files, and more specifically > "triangles" for geom. Our existing pipeline (from blender) can > instead output Collada files with "polygons" (rather than > "triangles"), but *not* "polylists". The performance of loading > Collada is obviously non-optimal. And Away 3D 4.0 Alpha does not > currently support any other geometry format but polylists. Bummer for > us. (We know it's alpha - it's ok). Add on top of that that Blender > is a dead end for us. We're moving away from it. > > Rather than spending a bunch of time modifying a pipeline that we're > probably not going to move forward with, I am more interested in > coming up with the right loading format for the application. > > The most promising thing I've heard described so far is a runtime > solution that loads a binary blob, decompresses it, and hands the > result to an AMF deserializer, and finally receiving a strongly typed > AS3 object. The pipeline/tool side would simply export from your > Content application (e.g. blender), and process the exported result > via an Air application that could create the strongly typed AS3 object > (e.g. Away3D Mesh) from an intermediate format, and serialize to AMF > and compress the result. > > This > pagehttp://www.rozengain.com/blog/2008/01/02/export-your-blender-objects-... > indicates an older solution for Blender that may be undergoing an > upgrade to support the new Away3D, but since we are also probably > moving away from Blender, so more interested in a stand alone > approach. > > Are there specific plans for Away3D to support an AMF load style like > this? > > Thanks in advance for any answers the team can provide.
