[WIP] Flash quake/descent style renderer.

[realMakc]

imho 10th version looks far worse, it's like totally blurred, with only things that benefit from high resolution being edges. 9th version looks sharp and more pleasing to my eye... imho.

[mr_malee]

imho 10th version looks far worse, it's like totally blurred, with only things that benefit from high resolution being edges. 9th version looks sharp and more pleasing to my eye... imho.

thats because the textures are stretched right? if the textures were sized to the face it sits on then it would look really nice and crisp.

by the way, I'm in awe, this project rocks the pants down.

[rachil0]

thats because the textures are stretched right? if the textures were sized to the face it sits on then it would look really nice and crisp.

I think this is exactly right. All the textures I have laying around are 64x64 and meant to be tiled, but tiling isn't supported by drawTriangles so they had to be stretched out to fill the polygons. With appropriately sized textures (256? 512? who knows) I think the F10 version will look much better.

All these updates have been tech related with ugly content, once the editor is in better shape I will try to do a nice content piece that has some interesting geometry and pretty texturing.

Thanks for the feedback guys.

[rachil0]

It's update time!

The map editor is finished (more or less) to the original specs. Here's the newest round of features:
* Quicksave / Quickload / Peek at a Quicksave
* Support for texture alignment, with 5 different ways to define UV coordinates: {orthogonal, skew axes, arbitrary 3-point match, match to a coplanar polygon, unfold texture across a shared edge}
* It was too hard to tell what you were doing while you defined textures, so now you can preview the texture mapping directly inside the editor. This is basically required a port of the Flash9 rasterizer into the editor. It's still not a true WYSIWYG because the editor doesn't implement occlusion/polygon ordering, and there's no lighting effects. It's pretty close though.
* Support for more geometry transforms (mirror/rotate/scale/translate). Some of these have new dialog boxes to help get you moving in the right direction.
* New dialog boxes for constructing vertices, regular polygons and rectangles. I feel these are useful for shaping up a level more quickly, which is typically lots of axis aligned shapes. The freehand vertex sketching, and creating polygons from vertex sets are still supported.
* You have more control over polyhedra - you can add/remove faces individually to build your own shapes from a collection of polygons, and change the orientation of all a polyhedrons faces simultaneously.
* In addition to creating polyhedra by extruding them, you can also create pyramids (whoopee). To help you make more interesting shapes, you can clip polyhedra against planes. You can no longer clip individual polygons.

Here's an example map with some (reasonably) complicated geometry that I made completely inside the editor:



There's also some big technical changes that were influenced by the migration to Flash10. Back in post #33, I described how the Flash9 texture mapper plays an important role in visibility/occlusion. That is, it was written to texture map a convex polygon which is hidden/occluded by a set of convex holes. The Flash10 texturer (graphics.drawTriangles) has no concept of holes/occluders. To take advantage of its great pixel fill rate, a lot of crap had to be redone. At this point, the code is both a portal renderer and a bsp-traverser. Cells are still traversed recursively like a portal renderer, but the draw order of brushes inside each cell is determined using a BSP (so now there's overdraw for brushes, they're drawn back to front). It's not an entire-map bsp the way quake works - it's a BSP that is only responsible for carving up the space inside a single cell (a much smaller region, with much fewer polygons). With so few polygons, it's possible to implement the BSP creator in flash, with just a brute force "try to use every polygon as a splitting plane" approach. The editor does this for you during the export process, but it's still up to the (intelligent) user to provide polyhedra that can be BSP'ed without needing any splits. If it's detected that a polyhedra needs to be split in order to proceed, the export halts and tells you what polyhedral subset needs to be resolved. The user can then split these polyhedra manually (the Polyhedra>Clip command is used for this). It takes some brains to get a map successfully out the door, but the extra performance of Flash10 is soooo worth it. Here's the above example, running in both codes (still ugly textures, but now you COULD make them pretty if you took the time to do so).

This a pretty complicated scene for this engine, Flash 9 chokes on it.



Flash 10 delivers the goods (as much as 3D in flash can be qualified as "goods").



Some features were added to the Flash10 renderer, so it now has all the capabilities of Flash9:
* Support for brushes (the last F10 screenshot didn't include them, because they flat out didn't work). This was described earlier, it's all that bsp stuff.
* Sector based lighting.
* Depth cueing / fogging. This is the one place where there is a noticeable difference in the output between the two engines. The Flash10 version is a lot darker at long distances (z), right? In F10, depth cueing/fogging is done by overlaying partially transparent black polygons on top of the texture layer. The alpha value is modulated across the polygon so that far portions are darker than near portions. Unfortunately, to do this quickly in one shot (with graphics.beginGradientFill), your alpha CAN ONLY vary as a function of Z according to alpha:=C1+C2/z, for some constants C1 and C2. The original F9 version had alpha:= C1+C2/(z+C3). In short, the shading in the F10 version can't represent the F9 shading exactly. It's not that big of a deal IMO, but C1 and C2 definitely need some tweaking because it's too dark. Actually, a bigger problem is the singularity at Z=0, because at some point the alpha just saturates to zero and you get full brightness right through the fogging polygon. The C3 constant in the F9 version was introduced to push this saturation point behind the camera so it wasn't visible.
[Don't get me started on how messed up graphics.beginGradientFill is, how its matrix argument works is completely indecipherable. IMO the method is unusable without its helper function, Matrix.createGradientBox.]
*Completely redone collision detection, it's much less "jittery". You can now properly "slide" along walls, intersections between walls, and even nestle stably at the point where 3 walls intersect.

Some new planned features for the editor that are yet to be implemented:
* Special "tagging" options where you can define attributes on any geometrical construct (vertex, polygon, polyhedron). A tag is just a piece of XML data that will be carried along throughout loading/saving/exporting. This will be an extensible way to define things like sector-based lighting, start positions for players, whatever. Tags will be meaningless to the editor, they're just satellite data that hangs around. It will be up to the consumer of the exported xml data to interpret tags as they will (this is intentionally vague).
* Support for defining flat-color values on a per-polygon basis. Flat color will be used when no texture is defined, or when the polygon is too far away to be worth texturing. Right now, flat color is initialized to hot-pink and there is no way to edit in the editor. This will be an option on the same page as UVmapping/texture definition.

And on the renderer side:
* Support for monsters (finally!), with correct or at least decent occlusion behavior. Self occlusion is no problem - monsters will be implemented with BSP's so they'll self sort correctly. Sorting them against the map is expensive to do at runtime, because you've got to split them across portal boundaries AND split them against brush BSP planes. This is a fearsome amount of code and runtime expense. ... But I've been tinkering into it already, and I think pixelbender/hydra might come to the rescue here, and enable the implementation of a zbuffer in software. Using gradientFill I've figured out a way to write an 11-bit z-buffer already, if I can get it to 16 bits I'll be more than happy. The pixelbender stuff will be used on the compositing side, where z-buffers and image buffers of both the monsters and the map have been created individually, and a final image needs to be constructed by z-sorting them together on a pixel-by-pixel basis. The code is already F10 only, so why not explore the options.

I do not plan to update the Flash9 renderer anymore, but exporting to its file format will still be supported by the editor in case anyone wants to play around with it. [As the Flash10 work progresses, I expect its featureset will get further out of sync with the Flash9 version and its too much work to keep them both current]. However, I think the editor will remain a Flash9 project for now - it throws a million errors when compiled with mxmlc10, because its Vector3D class collides flash.geom.Vector3D. Oddly, this collision doesn't happen when you compile the renderer, just the editor. It must be because the flex UI components import flash.geom.* (boooo).

PS: The good feature fairy has promised me texture tiling will be added to flash 10's drawTriangles method (even though I already coded up the workaround). The workaround will enabled some new features like splatting bulletholes and other "damage" features onto textures. (broken screens like in descent), so I'm not cutting it out yet.

Like anyone, I started asking for more features. I always say, competency is only rewarded with additional work.
http://www.adobe.com/cfusion/webforu...&enterthread=y

EDIT: I'll post up the codes and whatnot later, I'd like to hear more performance quotes on F9 vs. F10. Unfortunately, my free time is running out (new job starting soon) so this project is yawning and preparing to hibernate for another month or two (at least).

[MikeMD]

Flash 10 delivers the goods

So did flash 9 until the final release when performace wasn't any better than any other version before that.

[Incrue]

So did flash 9 until the final release when performace wasn't any better than any other version before that.

You mean as3 is not fast?Speed the only good thing on that
And besides...some things only shows his true potential with time, one could make a copyPixels engine with f8, it would be amazingly faster tham what mx could do but only now people found about that
And there is also the use of the video card...well, at least the first step on it,so is a matter of time too...

[realMakc]

It's not an entire-map bsp the way quake works - it's a BSP that is only responsible for carving up the space inside a single cell (a much smaller region, with much fewer polygons). With so few polygons, it's possible to implement the BSP creator in flash, with just a brute force "try to use every polygon as a splitting plane" approach.

some quake bsp models (levels) are under 2k faces, so it is possible to create bsp for those in reasonable time using enterFrame event or timer.

Don't get me started on how messed up graphics.beginGradientFill is, how its matrix argument works is completely indecipherable. IMO the method is unusable without its helper function, Matrix.createGradientBox

it is not so much of mystery if you remember that flash internal units are twips (1/20 of pixel). ask yourself what box do you need for createGradientBox to return identity matrix, and you will see it

Using gradientFill I've figured out a way to write an 11-bit z-buffer already, if I can get it to 16 bits I'll be more than happy.

here is 24-bit zbuffer discussion, but it's in russian.