Hi again Alex, Well, unless you are willing to share your test methods, I can only assume that they were wrongfully conducted, given the extreme results that they have given. I have never seen parsing of a 1000 triangle mesh in any format take more than a second under any normal circumstances.
I'm not sure you understand how parsing/creation and subsequent rendering of meshes work in Away3D or any other Flash 3D engine. Regardless of whether objects are originally encoded in some external format, or built vertex by vertex in an unrolled fashion inside an AS3 file (like the ones that AS3 exporters create) that gets compiled and hence embedded into the SWF file, the exact same classes are being instantiated. This usually take a fraction of a second, and only happens once. So whereas unrolled AS3 files are faster during this initial fraction of a second, the differences end here. Once the model has been parsed/instantiated, it is (usually) inserted into the scenegraph in which it will be rendered on each call to the View3D.render() method. At this point there is absolutely no difference between an object that originated as an AWD file and one that was hard-coded in AS3. So the performance gains from using meshes encoded into AS3 files are mostly neglectable, whereas the disadvantages of using AS3 models when the models get large are not (compile-time, huge files et c.) What I meant about forwards/backwards compatibility has nothing to do with Adobe. If you open an AS3 file that contains an unrolled mesh you'll see that it interfaces with engine methods and properties, like the Mesh.vertices property and Mesh.addFace() method to create geometry as it runs. But as an example, the Mesh class in Away4 will not have the same interface as the one in 3.6, so your exported AS3 files won't work anymore. The same thing will happen whenever the interface of these internal classes in the engine changes, which could happen now and then. Files that are encoded as for example 3DS, OBJ, DAE and AWD however continue to work across engine versions, because their formats are standardized in a bigger scope, and the parsers in the engine are updated to work with the latest version of the rest of the engine for you (by us.) I'm not trying to get you to stop using AS3 to encode 3D data. Even if I had wanted to do that there is nothing I can do to stop anyone, because if _you_ can write code to use the engine, an exporter plug-in can too. I've used this approach a lot myself and am even giving presentations about doing it in Blender (next up is FITC Amsterdam two weeks from now). I'm just trying to give you some perspective on why AS3 for data storage is not a silver bullet solution, and why carefully designed 3D formats like AWD are a more flexible solution. With regards to materials and shaders, the material framework in Away4 will be very flexible, so I'm sure you'll be satisfied. Cheers /R On Feb 21, 7:03 pm, Arkadianen <[email protected]> wrote: > My tests could be old especially in context of Away 4. I made them > some time ago its true. > > == and while there will indeed still be a place for > == exporting content as AS3 even in the Away4 era, there will be a > lot of > == situations where it simple does not work. > > It seems to me that native ActionScript language is faster and more > flexible than any other external format, excepts some external engines > compatibility issues. But native ActionScript should be made by Adobe > backward compatible with Flash Players. Besides, AS doesnt need to be > parsed and can be compiled from the beginning for the optimal use. > Lets say AS is the core of the representation and any other format > needs to be parsed to AS or Internal Format which is compiled from AS. > Thats why people could need AS exporters IMHO. > > And I have big doubts that people will use AWD models designed for > Away 3 (with less than 1000 polys), for showing them at Away 4, and > inverse, models with 1000000 polys for the Away 3. Anyway, I consider > AWD useful format but still needing the core - ActionScript format > models. > > Also we need a handy representation of materials and shaders. > > Thanks for the great engine you made. Together we will make it the > best. I do believe in this. > > Cheers > Alex > > On Feb 21, 3:34 pm, richardolsson <[email protected]> wrote: > > > > > > > > > This sounds extremely odd. No mesh with 1000 triangles should take 20 > > seconds to parse on any normal machine, regardless of the format. Are > > you counting in the actual compile-time? If you run the SWF file > > simply by double-clicking it, does it take 20 seconds from the point > > where the window appears until the mesh has finished parsing? If so, > > please send me the files I can have a look at what's causing this. > > > Thanks for your input about file formats. We have researched this > > pretty extensively and while there will indeed still be a place for > > exporting content as AS3 even in the Away4 era, there will be a lot of > > situations where it simple does not work. In those cases (and most > > other cases as well, like if you do not use Prefab) AWD will be a > > great replacement. One of the strengths of AWD is also it's backwards > > and forwards compatibility, meaning that even if the engine changes > > substantially (or you replace the engine entirely), the file will > > still load. This is not the case for AS3. > > > All parts of the AWD tool-chain, including all official exporter plug- > > ins, will be open-source and licensed under the same Apache 2.0 > > License as Away3D. > > > Cheers > > /R > > > On Feb 21, 1:40 pm, Arkadianen <[email protected]> wrote: > > > > == How can you be parsing a collada model at compile-time? > > > > Yeah, it is parsing at initialisation of the SWF, not at the compile > > > time, but the effect is the same because it is going on right after > > > compiling. Sorry for misleading info. > > > > The model is small, less than 1000 polygons. > > > > And if I use ActionScript generated by 3Ds Max plug-in or by PREFAB, > > > it is going in a normal speed. And when I use embed Collada file, it > > > is taking tens of seconds on SWF initialisation. > > > > Thats why I am asking about the formats and the ActionScript native > > > language models. > > > > It is obviously to me, that in native language it is going much > > > faster. > > > > It looks to me that when you use embed AS code, it is being compiled > > > from start, and thats why it is being parsed so much faster than an > > > External Format model ((== this is for embed models, I didnt test it > > > with loading models==)). > > > > Thanks for making the 3Ds Max plugin, it is vital for me and some > > > thousands of 3Ds Max designers. Is it open-source? > > > Hope to see it soon in action. > > > > On Feb 21, 2:09 am, richardolsson <[email protected]> wrote: > > > > > Hi, > > > > > See my responses below. > > > > > > My personal test shows that parsing Collada to Whatever Internal > > > > > Format in Flash is around 20 seconds, and accessing ActionScript code > > > > > model is around 0.05 seconds which is much faster. > > > > > 20 seconds!? How huge is that model? Or are you actually including the > > > > load (e.g. via HTTP) time as well? What exactly are you measuring? > > > > > > ==> I made this test with embed Collada file in Flex. It was parsing > > > > > at compiling time. I dint make same test with loaded and parsed at > > > > > runtime models, but I suppose at runtime it would be slowly also, and > > > > > even at compiling time 10-20 seconds is a very big time. > > > > > How can you be parsing a collada model at compile-time? > > > > > > Did you test the parsing speed? Please keep in mind that in Away 4 > > > > > the parsing work will be done by CPU. We must clearly separate CPU and > > > > > GPU work in runtime. > > > > > I'm assuming you're asking about AWD. Of course I am benchmarking the > > > > parsing speed, which is great. Obviously parsing can't be done on the > > > > GPU. Parsing happens in the AVM just as it has always done. > > > > > > My tests shows that in Away 3 the ActionScript code models rules > > > > > against Collada but it has some UVW mapping issues while parsing. > > > > > You get UV issues when using models encoded in AS3? There is no reason > > > > for that to happen, since there is no loss in precision, so if you're > > > > having issues with UV coordinates in Collada meshes or those encoded > > > > in AS3 that's probably something that you or the exporter are doing > > > > wrong, rather than something that is inherent to one method or the > > > > other. > > > > > > I want to ask - can I participate in testing AWD plug-in for 3Ds Max? > > > > > This is one of major elements for many designers and developers and I > > > > > would be glad to help in this project. > > > > > > Also I could participate on improving PyAWD as I know Python. > > > > > I'll let you know when there is an exporter for 3dsmax that you can > > > > test. PyAWD is not written in Python, it's written as C++ extension > > > > using the Python C API. I'm not in need of help right now, but I'll > > > > keep you in mind. > > > > > Thanks! > > > > > /R > > > > > On Feb 21, 12:29 am, Arkadianen <[email protected]> wrote: > > > > > > Hi Richard > > > > > > Thank you for the password. I started adding some documentation and I > > > > > will expose all the difficulties I will face during cool 3D games > > > > > development. > > > > > > My personal test shows that parsing Collada to Whatever Internal > > > > > Format in Flash is around 20 seconds, and accessing ActionScript code > > > > > model is around 0.05 seconds which is much faster. > > > > > ==> I made this test with embed Collada file in Flex. It was parsing > > > > > at compiling time. I dint make same test with loaded and parsed at > > > > > runtime models, but I suppose at runtime it would be slowly also, and > > > > > even at compiling time 10-20 seconds is a very big time. > > > > > > Did you test the parsing speed? Please keep in mind that in Away 4 > > > > > the parsing work will be done by CPU. We must clearly separate CPU and > > > > > GPU work in runtime. > > > > > > My tests shows that in Away 3 the ActionScript code models rules > > > > > against Collada but it has some UVW mapping issues while parsing. > > > > > > I want to ask - can I participate in testing AWD plug-in for 3Ds Max? > > > > > This is one of major elements for many designers and developers and I > > > > > would be glad to help in this project. > > > > > > Also I could participate on improving PyAWD as I know Python. > > > > > > On Feb 20, 7:39 pm, richardolsson <[email protected]> wrote: > > > > > > > Hi Arkadianen, > > > > > > > Please excuse me in advance if I seem to be jumping to conclusions, > > > > > > but I'm having a hard time understanding what you mean, so I have to > > > > > > make some assumptions. > > > > > > > First of all, if you browse to the wiki > > > > > > atthttp://www.away3d.com/wiki > > > > > > there are instructions on the main page in large letters saying the > > > > > > following: > > > > > > "To edit pages (but not the front pages), please use the password > > > > > > 'editwiki' (without the quotes)." > > > > > > > If you go to any page on the wiki except the front page (which is > > > > > > locked) and click edit, you can edit the page after having entered > > > > > > the > > > > > > password mentioned above. > > > > > > > With regards to AWD, correct me if I'm wrong but you seem to think > > > > > > that a file that is loaded into a Flash app running Away3D gets > > > > > > converted to AS3 at runtime, and that because of this using AS3 > > > > > > directly is faster than using another format. This is incorrect. > > > > > > First > > > > > > of all, at runtime there exists no notion of "AS3" anymore, since > > > > > > everything has been compiled into byte code inside the SWF. But even > > > > > > disregarding this, the internal representations of meshes, > > > > > > animations > > > > > > and any other data inside Away3D are still just data chunks in > > > > > > memory > > > > > > like in any other programming language. To generate a representation > > > > > > of for example a mesh in memory, whatever code is responsible for > > > > > > creating it has to instantiate classes and pass them the correct > > > > > > data. > > > > > > > Regardless of whether you are generating an AS3 file that you then > > > > > > compile into byte code that does this instantiation, or use a parser > > > > > > like the AWD parser to read a file and do the instantiation from > > > > > > what > > > > > > is in that file, you are still doing the same thing. Granted, the > > > > > > AS3 > > > > > > approach leaves out the reading/parsing so it's most probably > > > > > > faster, > > > > > > but the gain in performance is not of relevant magnitude (a matter > > > > > > of > > > > > > milliseconds per 10 000 triangles in a mesh, or something like > > > > > > that.) > > > > > > > Thanks for offering your help! We already have team members looking > > > > > > at > > > > > > creating an exporter for 3dsmax, but in case you want to do your > > > > > > own... > > read more »
