Hey makc,

The first demo is rippled because perspective correction is not done at every pixel, but at set intervals along the scanline (24 pixels). Quake had the same artifacts (it was corrected at 8 or 16 pixel intervals iirc) and descent was especially bad (32 pixel subspans). You can cut this interval down to a smaller value but that error will always be present to some extent. From the very 1st post:

... the easiest way to see how perspective is approximated [is to] roll the view 45 degrees and you'll see these artifacts where the texture sort of ripples on the surface.
Judging from the screen shot, this is exactly what you did. In quake, this error was managed by map and camera design. Despite its 3D nature, most of quakes surfaces are still perfectly vertical walls and perfectly flat floors. Any sloped surface is placed such that it's unlikely that a players sight can be right up next to the surface like that. Furthermore, the camera was not permitted to roll around the view axis. Even when you're killed and the camera rolls to +90 degrees like your ear is on the ground, it's not a smooth motion! It just jumps 90 degrees - essentially swapping floors and walls around and avoiding the ugly 45 degree case altogether). If you try to find perspective error without rolling the camera and I think you'll find it's pretty tough to spot (especially in the most recent demo, which prevents you from placing the camera directly onto a surface, the collision routine keeps a small ball of empty space around the camera at all times).

Unfortunately I can't get the first link to work - which I suspect was the thrust of your post. The second link I checked out (neat!). I also looked at another demo on PreciseBitmapMaterial ( http://away.kiev.ua/away3d/techdemos/persptex/ ). They are very neat demos I think the real problem with the pvquake demo is that its subdivision isn't very smart. Thinking about it again, the one case that you really have to avoid is a permitting triangle edge that points in the same direction as the z-gradient direction. Maybe a good subdivision strategy is to first cut the polygon into thinnish slices along constant-z lines and then tesselate each slice with a triangle strip. If I get time, maybe I'll give that a try sometime.

There's still a few other things that I think would be worth trying. The first is using the same scanline algorithm, use graphics.beginBitmapFill to do the 24 pixel spans instead of pushing them in pixel by pixel. That might let you scale back up to high resolutions nicely, and still let you keep all the neat spotlighting effects.

Another idea, which is tougher to implement, is to reuse scene coherency to avoid subdividing polygons at other frames. Once you draw a quad onto the screen, capture/grab it's screen area (by splitting into 2 triangles) and stuff both triangular shapes into bitmaps. Then reuse these already-distorted textures on the next frame, affinely warping them onto the new screen triangles. Every handful of frames, redo a highly detailed version to make a new source texture. I think this could work pretty well, and could even let you fake some of the directional lighting effects, by baking it into the intermediate/cached texture. Do either PV or Away3D already do this? It strikes me as pretty clever, do you think it would work?

Always have more ideas than time, it seems.