...right. so, what it was supposed to show is that even in close views with maximum precision you dont need that much triangles. maybe you could also look at original away3d demo (namely, the scene with some geometry). the most important bit is that these small triangles are generated "online", and projection matrix only needs to be adjusted rather than re-calculated, as it would be necessary in case of some LOD approach. any way, hopefully this will be no longer an issue with v10 player.

But I think you could use a similar idea with the flash beginBitmapDraw routine. You only need to subdivide triangles deeply along the gradient of z (the direction orthogonal to the line of constant-z). Along the other direction, I think your triangles could have extremely long edges before you started noticing perspective error.
Unfortunately, this will not work, AFAIK. Someone have put a tight cap on PreciseBitmapMaterial recursion limit once (about 5 iterations or so), and it resulted in very similar behavior to your idea; my overall impression was that texture zigzags became very visible in that case.

The first is that I have no idea how to integrate directional lighting into that approach. I think you could cajole the flash renderer into doing gouraud (sp?) shading over the screen triangles (by rendering black, partially transparent "mask" triangles over the texture layer, and filling them with beginGradientFill with a linearly varying alpha). The catch is that if you're drawing huge triangles, your lighting function is undersampled and then linearly interpolated. So any fine details in lighting, like a circular hotspot from a nearby directional light, are going to be ignored. Unless you subdivide based on lighting too...
Again, sandy has just ported Gouraud code from flash3d. Results are just like you describe it, but that's totally expected (check sphere graphics at wiki page). This is accuracy-versus-performance trade-off.

However, if you want to do CSG-style solids ("brushes" in the prior post), your drawing regions are now non-convex polygons, possibly with holes (yuck!). I think it would be really tricky to program subdivision for this case - the pvquake demo I gave does not even touch this problem. The easier to program alternative is to do just overdraw things, by drawing the cell and then painting the brushes back over top the cell walls. I think that would be slow. But when you're doing pixel by pixel rasterization, all this is a non-issue.
Yeah but in case 1 you do more math once, and in case 2 you do less math per every pixel. It is not that obvious what is faster.