DISKTREE.NET // PANZERKUNST

i’ve started a new branch using the new flash player 10 3D api and will drop the ugly hacks to have a third dimension completely. So this is the last version for fp9.
Currently i am limited to do some experiments and learning the new api using as3 and the mxmlc compiler cause haxe does not fully support fp10.
( btw, if you have’nt noticed: flash player 10 RC is availbale at labs.adobe.com since 8.11.8 )

[ holo_0.1.2.zip ]
[ skybox_example.swf ]
[ material_example.swf ]

cause this branch is kinda dead, i dont want to get into details about the changes.
.. read the sources and check the demos.
if anyone is interested in doing further develoment. justdoit! and let me know!

Please mind that if you want to have solid 3D in flash but using haXe you are better creating external bindings to one of the existing as3 libs, which works nice for away3D at least.

holo is an open source 3D engine written in haXe ( 1.19 ) targeting flash9.

A lot of core stuff is ported from the away3D engine ( which i liked most in terms of design, while studying   ).
For now, the runtime target isn’t abstract ( the hx way ), means there is no support for other platforms than flash9 ( soon flash10 ). After studying actionscript3 3d libraries, i thought it would be a great drawback for not using the flash api in respect for designing the display system and the render pipeline and would end up in #if #else hell. Also the performance loss would be nonexcusable. A haXe quicksort of the drawable primitive objects takes about five time than flash.Array.sortOn().
A little performance profit compared to as3 versions should come through the inlining of the math methods and the usage of haxe.FastList ( sadly most collections need an index ).
I have not tested with engine itself right now but:!
Matrix4×3 multiply of two empty matrices:
AS3 ( away3d version ) : 1722 ms
HX : 47 ms
Should have an impact! ( i should doublecheck this, to prove its amzingly true .. later )
Sadly, in flash, rendering takes it all. I’ve only discovered “feelable” performance improvements with render related stuff like backface culling. Maybe this changes with the gain of complexity in the scene.

I do not have model importer rigth now, but have rewritten a AS3 export python script for blender which is included in the sources.

[ BlenderTorus.swf ]
[ BlenderMonkey.swf ]
[ Fluid.swf ]

Current code is written for haXe 1.19.

[ holo.0.1.zip ]
[ git clone git://83.64.208.21/home/tong/git/holo.git ]

[Edit]
The matrix multiplication performance comparison above isn’t valid, because the as3 version was tested in debug player.
After all, 10000000 matrix43 multiplications on release player:
as3 ( away3d ): ~550ms
haXe version: ~460ms
I knowed that the debug player is slower, but thought about a x0.5 rather than x35.

On my research on 3D space manipulation i’ve created UML maps of the big flash 3D engines scenegraph architectures. ( Away3D. Papervision3D, Sandy3D, Alternativa3D )

The green classes represent members of the scenegraph.
The green classes with red outline represent the class where transformation takes place.
( May contain minor errors. Just for overview. )

——-

——-

——-

All flash engines have in common that there is no encapsulation from the content objects (models, sound,..) from the scenegraph, which is often mentioned as “the must have thing” in current “on the top” 3D-APIs like ogre, horde3D.
Also the draw stuff is deeply embed in the scenegraph. Of course there is no need when coding in actionscript, since flash player is the only, lonely target.
Most GPU based engines abstract the draw stuff to provide access to the at least two rendering apis ( OpenGL, Direct3D ).
Maybe not so well designed / Annoying things ( not related to an specific engine ):

* No static nodes.
* No encapsulation of content and scenegraph ( concrete objects inherit from a scenegraph node ).
( * 3D Display views are not members of the pipeline iteself. )
* Render tree is scene tree itself ( geometry tree traverse same as rendering tree traverse ).
* Static target support ( as3 = flash9+ only )

Possible improvements / Things to implement or get hunted:

* Scene graph management encapsulation ( changeable traverse tree ).
* Encapsulation of api and core ( “my target is neko, lets use the fast c/cpp maths dll instead of (slow) haXe ones” ).
* 3D view should be a 3D display object iteself (scene projected as material ).