One more problem you might run into with Flash 10 3D is when you rotate a display object in 3D. Display objects are perfect planes, which means they don’t have any thickness. The old joke, “he’s so thin that if he turns sideways you can’t see him” can be taken literally when dealing with display objects, as you can see below:
Here, I’m just drawing a bunch of circles, while slowly rotating them on the y axis. As you see, the closer you get to 90 degrees, the less you see of the circle. Actually, I’ve arranged it so it never hits exactly 90 degrees, so you can still see a few pixels of the center circle. If you rotate something exactly 90 degrees AND view it head on, you won’t see it at all.
But worse than just not seeing it is the degradation it goes through as it approaches that invisibility threshold. You can see the two circles on either side of the center one almost seem to be drawn with dotted lines.
Again, I’m not out to totally bash Flash 10. I think it’s awesome that Adobe has finally put this into Flash, and for a first release, I’m thrilled. These are just things to keep an eye out for, and hopefully things that Adobe will take a look at improving in round 2.
The reality is that there very little 3D code inside the player, at least native code. Whenever you export a movie that uses the new “3D” features, you’ll notice that about 13KB of AS3 code is attached to it. This code is responsible for the pseudo 3D rendering using same old tricks used by earlier 3D renderers. You see degradation in rendering because those vector objects are transformed into cached bitmaps and handled as texture over triangles. Bitmap resampling algorithms inside the player are pretty good, but not good enough in several situations like this one. The Flash IDE, however, does a good job by making completely transparent to the user that this 3D manipulation is not native to the player itself but rather to silently attached code.
I’m having some trouble with the new flash 3D-stuff
The first simple thing I wanted to do in flash CS4 was to have some simple rotationY-fun. I immediately stumbled into a problem…
I’ve tried to do the rotationY on a perfect circle… it works perfectly when I kept the circle’s original scalefactor (1)… but when I changed the height and width through a scaleX, scaleY or a .widht, height the endresult is totaly weird since it ends up being wider than it is large (and not just a single pixel either… but a LOT wider). Maybe I’m doing something stupid here, but my guess is that it’s probably a bug in flash, and a pretty big one also. I guess I’ve gotta enter this somewhere in the adobe bugs database 🙁 didn’t do that for a long time.
[code]// original circle is 173×173
this.addEventListener(Event.ENTER_FRAME, doenter);
circle.scaleX = .6; // or circle.width = 40
circle.scaleY = .6; // or circle.height = 40
function doenter(e:Event):void {
if(circle.rotationY == 360) {
trace(circle.width,circle.height); // traces 143 105
}
circle.rotationY += 1;
}}[/code]
It seems that the content is transformed to an image and then re-rendered as such. With no mipmapping or anything of the sort, the interpolation creates that kind of quality loss when the view angle is too sharp.
I’m trying to understand what you expect Adobe to improve. Do you want planes to have a width? How is that possible without breaking the mathematical model (and Papervision)?
How should the thin circle be rendered, ideally? Should the renderer “just know” that the black pixels should be favored over the white pixels? Or do you expect bicubic interpolation at runtime? (good luck)
Sure, we could compare to a vector scaling of the circle. But until we can make a perspective-correct stroke, it’s not a real comparison.
@Emanuele: Have you seen that silently attached AS3 code?
What I mean is, have you decompiled the AS3 code and seen what it’s actually doing?
Robert, I’m not really sure what I expect Adobe to improve beyond, “make it look better”. I understand that giving display objects “thickness” could cause more problems than it solves. But from an intuitive sense, a hairline stroke remains the same width no matter how it is scaled or otherwise transformed in 2D, I guess I expected that same behavior in 3D transformations.
But this rotation factor is the least of the problems, in my estimation. The problems I show in my other post are much more serious:
http://www.bit-101.com/blog/?p=1674
Again though, I don’t know what I expect other than, “don’t make it look like crap”. I feel like it’s Adobe’s problem to figure that out, given valid examples that demonstrate that it does look like crap. I’m not entirely sure how they are doing what they are doing, so I don’t know exactly what to suggest they change.
My guess is that it works just like zeh said: it generates the Bitmap and only then they get transformed in the 3D space… Maybe if the transform was kept on the virtual space and then rendered as a 3D view we could get a nicer, cleaner result.
Besides that, I do think that the altialias method should be interchangeable via code, focusing on performance or final results. Anyway, the antialias really sucks on these examples!
see: http://www.bit-101.com/blog/?p=1686
I guess the problem is our eyes above everything cos when we look at real world stuff we have 2 eyes to give us sense of 3d environment. especially if we tilt our heads or pan to see things differently at different angles and stuff. like closing one eye at time when looking at your finger. if you then open both, you see our brain is rendering a 3d version of the world from 2 different 2d views.
to get this right you would have to output 2 images possibly that were angled for each eye and there relative position to screen or object whatever… probably tough on current screen technology. are 3d objects in flash being rendered through multiple viewports to imitate this? if thats even possible.
have you seen the forthcoming books list at friendsofed’s home site?!!!
See my comment on the previous post “flash 3d vs the old way”.
Regarding Ypmits question about the width/height: The same problem occurs in 2d. width/height have an unfortunate historical definition of being the width and height of the bounding box in parent relative coordinates, not local-to-the-displayObject coordinates. That means they change as you rotate. Try the same code in 2d with a rectangle. As you increment the .rotation, the width and height will change. In your case, you are getting the screen dimensions of the rect on stage where your circle is drawing. Silly, but the 3d definition has to work the same as the 2d definition has always worked. If you want the local space dimensions, use getRect()/getBounds() relative to yourself.
Emanuele Cipolloni said “The reality is that there very little 3D code inside the player, at least native code. Whenever you export a movie that uses the new “3D†features, you’ll notice that about 13KB of AS3 code is attached to it.”
Is that true? Surely there must be some sort of native execution of the division by z. I can’t see how one could do pixel-perfect-perspective-correct texture mapping, at the rates FP10 achieves, without such. I clocked drawTriangles() drawing 1600 texture mapped triangles, within a 400 x 400 window, being rendered at 20 fps. Can that be done in AS3 outside of the Flash10 3D API?
The perspective projection and the perspective correct fill (including the divide by z per pixel) is performed in highly optimized native code, not by AS3. The same is true for all Matrix3D and Utils3D operations.
When you author a movie using the 3D UI in Flash Authoring, actionscript is inserted into your movie to set the Matrix3D of each of your 3d MovieClips on each frame. That is the 13k mr Cipolloni is referring to. This code is only necessary for 3d animation created via the Flash Authoring UI.
Yes, Emanuele Cipollini’s implication is that the AS3 is responsible for the 3D – rather than the native code. He says: “This code (AS3) is responsible for the pseudo 3D rendering using same old tricks used by earlier 3D renderers”. Clearly this is not the case. Native code (not AS3) is performing the required operations. The AS3 acts only to supply parameters to the native code (whether auto-generated from Flash or handcoded in AS3).
A question: how do you get the perspective 3D width of a DisplayObject in AS3? The very property that’s greyed out in Flash IDE.