I have been following this discussion and just would like to add.I raised this question around a year ago here(loading models via AMF).You can check the group history for this.Katopz then suggested me to write serializable objects.And I can just tell you that it just soinds that easy but the actual implementation of the ISerializable in Away3D is pretty complex.Because you have to serialize not only the desired class let's say a Mesh but all the other classes it makes use of extends from . Eventually back then I just wrote an app which I showcased in the book I am working on . The app was to showcase the possibility to store the models in MYSQL in binary form (BLOB data type) then on demand using BLAZEDS AMF channel to send it into Away3D app where it was deserialized into 3ds format and parsed into the scene. There was no gain in the speed as the deserialization was not into actual final ActionScript but into the initial model's format which was 3ds. Also I was not able to test the real word scenario speed of the loading as I don't have a web server with BlazeDS deployed. At the end I removed this "experiment" from the book and from my mind also because it was both inefficient and essentially wrong by the approach. Generally I believe that the serialization of an object into binary which would be deserialzied straight into AS class is a good idea but in Away 3.6 it was a challenging task to accomplish (at least for me )
On Thu, Mar 10, 2011 at 8:31 PM, richardolsson <[email protected]> wrote: > Hi Dave, > > Yeah, I heard that they were using the AMF approach. I guess they only > did that because it was easy. It's not the way to go for the long run. > > Basically, AMF is just a storage format for a certain set of primitive > data types (e.g. int, float and string), arrays, and objects. So in a > way, it's a bit like a binary JSON. > > In the Flash Player, there are generally speaking two different ways > of parsing (deserializing) AMF. Either you rely on the built-in > deserialization in the Flash Player, which can take an AMF object and > create an AS3 object from it. Or you parse it yourself by interfacing > with the AMF stream through a ByteArray and reading the values out of > it (and implementing ISerializable in the classes that you want to > have instantiated from the AMF stream.) > > The problem with the first approach is that it requires the objects in > the AMF file to map 1:1 to classes in your application. If it doesn't, > the data comes out wrong. So in practice, that means that if for > example you encode something using version 1 of your software, you > will only be able to open it in version 2 if your classes remain the > same. > > This in turn means that either you can't change your framework classes > (because it would break parsing of old files) or you have to have an > intermediate structure of value objects that never change. So when you > parse a file, instead of having your framework classes being > instantiated, the value object classes are instantiated and you then > have to go through a second "back-end parsing" step where you transfer > the data from these value objects to your framework classes. > > As an example, if we would do that in Away3D, we would have to have > the regular Mesh class, and a MeshVO (value object) class which is > generated from the AMF stream. And once the MeshVO object has been > instantiated, we transfer the data by doing myMesh.x = myMeshVo.x; et > c. As you can imagine, this is far from ideal. > > The other way of doing it, using ISerializable and parsing the byte > stream ourselves, has some major disadvantages and very few > advantages. The biggest issue is that it means all your framework > classes have to implement ISerializable, so you basically end up > scattering your parsing code all over the place. Also, since you have > to do the parsing yourself, you don't really get better performance > than you would if you parsed a byte array containing other any type of > data (e.g. AWD2, and I'm getting to that.) > > So bottom line is (and I've tried it, benchmarked it and analyzed it) > that AMF is not a very good storage format. It also has some major > issues like duplication of data (no "references") and inability to > stream without splitting the data into chunks. And the thing is, it's > not even that compact or fast to parse. > > > AWD2 is vastly superior to AMF for storing 3D data. It parses just as > quick (or quicker) while being smaller and not having the issues > described above (for instance, we are able to make it completely > forwards and backwards compatible.) > > > For the AWD2 spec (WIP obviously) go to http://awd.googlecode.com and > look in the /trunk/docs/spec/ folder in SVN. > > There is already an AWD2 exporter for Maya in the works, so if you're > going for Maya I don't see any real reason for you to export COLLADA > files and translate them in some intermediate tool. > > > Cheers > /R > > On Mar 9, 7:42 pm, Dave <[email protected]> wrote: > > Hi Richard - thanks for the response! > > > > Actually, I saw a presentation given at the Flash Gaming Summit in San > > Francisco on Feb 27th. The technique was used by the Zombie Tycoon > > folks. Here's the presentation: > > > > http://partners.adobe.acrobat.com/p84609211/?launcher=false&fcsConten... > > (the relevant part of the presentation is 12:00-14:30 or so) > > > > I am interested in hearing more about the restrictions that AMF > > imposes on the parsing engine and additional intermediate objects > > required. Can you provide a little more detail? > > > > I definitely would like to know more about AWD2. Can you point me to > > any in-progress specs? Sounds like it doesn't make much sense to even > > look at AWD(1). > > > > From my perspective, Blender is great for indie work, but doesn't > > scale to larger team usage, and is (frankly) harder to hire for. We're > > aiming for Maya probably, and we'd like export to Collada (or some > > other agreeable format) and then post process with something else > > (like a Collada to AWD2 converter). > > > > -Dave > > > > On Mar 9, 5:34 am, richardolsson <[email protected]> wrote: > > > > > > > > > > > > > > > > > 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. -- Michael Ivanov ,Programmer Neurotech Solutions Ltd. Flex|Air |3D|Unity| www.neurotechresearch.com http://blog.alladvanced.net Tel:054-4962254 [email protected] [email protected]
