Just wanted to share a few of my frustrations with as3, in particular the apis added to aid 3d development.
My reason for voicing these is really to find out if its me miss understanding things or if other people share my opinions.
My main issue is the restrictions of the drawtriangles/projectVectors/transformVectors methods.
These methods work well and are pretty fast but the parameter format drives me nuts!
everything has to be in vectors of numbers i.e.
var verts:Vector.<Number> = new Vector.<Number>();
verts.push(0, 0, 0, 10, 0, 0, 0, 0, 10);
the vector verts now contains a representation of three 3d vertices (that make up a triangle) in the format the flash wants them in.
is this format easy to manage/maintain…no.
is it easy to debug…no.
is it faster for non-native methods…no.
is it the format flash demands…yes.
is it a pain in the arse…yes.
directly referencing a vertex like this is impossible and accessing it will require a minimum of 6 vector index operations, 3 to get the numbers out and 3 to put them back (slow slow slow).
🙁
I find things so inflexible that I run two systems in parallel, just to take advantage of the new methods resulting in wasted time and memory.
You often end up just having to repopulate these lists every frame, which although works its just plain craziness.
I am sure there are good reasons for this but what are they?
Why couldn’t they have given us a few interfaces instead i.e. IVector2D and IVector3D. Would it really be much slower?
Let us manage things our own way, give us freedom to implement things how we like!
Another thing that has been bugging me is drawTriangles, it isn’t currently flexible enough to be fully taken advantage of. Say for example you had a cube, and you decide to use 8 vertices to define it, one for each corner, drawTriangles is great because it lets you define which of the vertices makes up each individual triangle but it wont let you specify individual uv-coordinates per triangle-vertex. booo. Ideally a vertex shouldn’t need to be tied to one uv and one uv only because if that vertex is also part of another face it make have a different uv-coord.
Given that adobe are supposedly working on new 3d shiznit that are gonna blow our minds, I really really hope they consult the community and ask the people who are going to be using it most for input, ideas and suggestions!
4 replies on “booo adobe”
I’m pretty sure they made these decisions for the sake of speed. A Vector. is just an array of 64-bit floating-point values in C/C++: a double[]. This means that they can write a really fast loop to iterate over these points without the pain of using AS3’s Vector indexing operator, which does slow operations like bounds checks. Also, since they’re not using an interface (IVector2D, IVector3D), they don’t have to do an AS3 function call (presumably a “get x”, “get y”, “get z”) for each component of each vertex; this would be vastly slower than simple C/C++ array access. So I would just change one answer:
is this format easy to manage/maintain…no.
is it easy to debug…no.
is it faster for non-native methods…yes.
is it the format flash demands…yes.
is it a pain in the arse…yes.
I guess so but I’m not convinced about your cheeky boldified ‘yes’.
It might have been me not explaining what I meant by “non-native methods”.
Here goes:
Suppose you wanted to cull your triangles based on winding and maybe reject triangles who’s projected vertices lie outside the viewport… (2 fairly common practices)
Loop through each triangle…
get the vertexId for each vertex in the triangle.
extract the 6 values that represent the 3 projected vertices (6 reads*)
*and not simple reads at that i.e. vertices[int(id1*2)+1]
all that just to get 6 values that represent the 3 vertexes, I ran some tests and this is ooober slow, about 15-16ms for my test mesh, and that is WITHOUT even doing any of the operations on these values.
my original method took about 4-6 ms on the same mesh (about 12k faces) and that’s INCLUDING the logic..
It just gets worse too when you wanna z-sort!!!
var z1:Number = uvt[int(id1*3)+2];
var z2:Number = uvt[int(id2*3)+2];
var z3:Number = uvt[int(id3*3)+2];
triangle.z = (z1+z2+z3)/3;
the above again is much much slower than:
var z1:Number = point1.tz;
var z2:Number = point2.tz;
var z3:Number = point3.tz;
triangle.z = (z1+z2+z3)/3;
this is just scratching the surface as well.
I didn’t expect it to be as slow as it was myself, but numbers don’t lie 🙁
Any ideas why this is the case, is it just that object reference is so much faster than array/vector lookup or is there something I am missing?
In AS3 it is much slower to access an Array or Vector than to access a field of an non-dynamic object. This is not the case in Flash Player’s native code as they have direct memory access to your Number/float array. Really, array access in native code is so much faster than in AS3. Consider this AS3:
And this C:
On my 3.0 Ghz Intel Core 2 Duo with Windows XP I get 16 ms for C and 596 ms for AS3. That’s about 37x faster in C than in AS3 for just a single write.
So I guess my point boils down to a case of comparing apples to oranges. AS3’s array/vector access makes arrays look bad… until you use C.
I see where your coming from but my frustrations is that I think adobe hasn’t thought outside the box with its draw triangles methods.
YES they may have come up with the fastest way to draw them to screen, and yes they may have really fast matrix projection BUT people might want to more than just DRAW these triangles! In trying to be fast they have killed flexibility, and for the average developer the sacrifice of a little speed for great flexibility will yield much more fruit… maybe oranges…maybe even apples!
“In many languages, oranges are, implicitly or explicitly, referred to as a type of apple, specifically a golden apple or a Chinese apple. For example, the Greek χρυσομηλιά (chrysomelia) and Latin pomum aurantium both literally describe oranges as golden apples. In other languages like German, Finnish, Polish, or Russian the terms for the bitter orange (a related species) are derived from Latin pomum aurantium. Additionally, the Hebrew word תפוז (tapuz) is a shortened form of תפוח זהב (tapuakh zahav), or golden apple.
In Dutch, sweet oranges are called sinaasappel, which is derived from China’s apple. The Latvian apelsīns, Icelandic appelsína, Swedish apelsin, Finnish appelsiini, Russian апельсин (apelsin) and North-German Apfelsine share similar etymology.”
go wikipedia 🙂