will you add "overlay" kind of BlendMode?

Creating a component after init does lead to some errors (issue with style not being defined?)

Currently it is an abstract which prevents adding members, which could be useful for leak tracking / ref counting...

Maybe we should consider a switch ?

When we add a new Interactive over one that has mouseover, we don't get EOut until we move the mouse. It would be necessary to check the status when we modify the interactive list.

This can also happen when toggling visibility, so it might be necessary to unregister invisible interactive as well (when?)

This is a nasty piece of stinging bits that should be symbolised.
A macro or enumFlags enhancement could do the trick easily.

Thanks !

SpriteBatch allocates a vram buffer on each draw... which can lead to video ram fragmentation and is very costy.

It should stick to :
over allocating its primitive
regrow if need be
give user control over max size so that psrite leak are detected early

fl 11.8 added support for RectangleTexture

http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/display3D/Context3D.html#createRectangleTexture()

@ncannasse
I could try a fix but you will go way faster :

var shape = new h2d.Graphics(scene); 
shape.lineStyle(2, 0, 0.5); 
for (h in 0...6) { 
 var angle = 2 * Math.PI / 6 * h; 
 var pointX = (30) * Math.cos(angle); 
 var pointY = (30) * Math.sin(angle); 
 if (h == 0) shape.addPoint(pointX + 60 / 2 + 1, pointY + 52 / 2 - 1); 
  else shape.addPoint(pointX + 60 / 2 + 1, pointY + 52 / 2 - 1); 
} 
shape.endFill(); 

shape.x = 300; 
shape.y = 300; 

var sh = new h2d.Graphics(scene); 
sh.lineStyle(2, 0, 0.5); 
sh.addPoint(0, 0); 
sh.addPoint(50, 0); 
sh.addPoint(50, 50); 
sh.addPoint(0, 50); 
sh.x = 100; 
sh.y = 300; 
sh.endFill();

Observe the line thickness is not homogeneous. We use hexagones in a next game, it would be cool if you can have a quick look, we'll get along anw.

Thanks a lot !

The button on the slider is no longer clickable (interactive ordering issue?)

The Memory manager class is complex, not commented and does to many things.

We should adopt lighter model, for example provide a vramPool and a vramDirect allocators that would allow user to have control over which policy he wants, because here it is sometime to know what you get, if your buffer is interleaved or what to call..for example why is readAtfHeader here ?
...

Since the last update I am getting this error, even with the Demo.hx application:

ReferenceError: Error #1065: Variable flash.display3D::Context3DWrapMode is not defined.
at boot_3fa8/init()[/usr/lib/haxe/lib/h3d/git/h3d/Engine.hx:550]
at flash::Boot/start()[/usr/lib/haxe/std/flash/Boot.hx:70]
at boot_3fa8()[/usr/lib/haxe/std/flash/Boot.hx:38]

If I set the constants directly in line 550 then things work. If I set them to access the static arrays then I get the error. I also tested passing hard values into the accessors like WRAP[0] and Engine.WRAP[0] with no success.

in h2d.css.Style we rely on Null excapt that on cpp it sometimes cause problems ex :

inline function extLeft() : Float {
//System.trace1("m:" + Std.string(style.marginLeft) );
return style.paddingLeft + style.marginLeft + style.borderSize;
}

If i comment the trace the calculus is ok otherwise it make a wrong results... so we should avoid relying on a+ null to return a valid value (or fix hcpp but I can't reproduce ona small scale...) .

Thanks for sharing this libray! looks fantastic!

I tried to load tools/xbx/boneTest3DS.fbx with the tools/fbx project but I get this error

combi has 3 Material childs
    at h3d.fbx::Library/getChild()
    at h3d.fbx::Library/makeScene()
    at Viewer/loadData()
    at MethodInfo-117()

Not sure if that's an expected behavior (2 different projects) or if I'm doing something wrong, but it's slighly confusing when getting started.

Mask dont display properly on captured Bitmap

Discussed with Nicolas : many changes for cached bitmaps and we can't stick to one solutions, here is a sum up of the discussion.

h2d should provide high level filters like blur/glow. The tool for this is Render to texture but there are architecture issues.

Namely :

• chaining CachedBitmap might fail because there is no currentFrameBufferPush/pop
• current cachedBitmap take top left 0 0 as rect coord but its often nearyly useless in real life cases
• current impl take a scene node hierarchy which is in fact lousy to work with

What was proposed :
1- Switch to a similar system as flash : a cacheAsBitmap field
2- Implicit cacheAsBitmap when a filter is applied.

I vote against this one because it wil basically make our sprite as implicitly performance harming as flash one especially on mobile because the hidden costs of framebuffers is high.

So I propose this:

• Deport Rtt at scene level
• h2d.scene could receive a texture target and handle target scaling
• we add a rendertargetpush/pop ( to glue scissior, depth and all attribute together
• We make scene nestable and ensure we can do recursive drawing of scenes
• For nesting scene we provide a DrawableScene which will handle the draw of a deferred scene and allow blur computation etc...

Then we will enforce pedagogy of Rtt is expensive and still have a powerful compositing tool.

A renderer would then have multiple scenes in aprallel and the implementer will have no implicit costs.

It is also transparent for new comers.

It will make compositing a slightly complexier issue but since this is a thing one want to control finely in accordance of artists I think is is a better solution than just letting implementers mess with high level and cost ineffective rendering method without pedagogy.

Nothing impeaches us to do a high level scene node that does all this transparently but at least the low level will be clean.

Thanks for reading.

h3d seems great, however I think new users could benefit from:

1. Add an Install section to README.md explaining how to get the latest version with dependencies from git: haxelib git format https://github.com/HaxeFoundation/format.git etc
2. Add a more complete sample. For example a simple "game" with some suggested project structure, a tilemap background, sound, and both an animated .fbx model and animated sprite (even if just a stretching cube or something) responding to some keyboard input.

In order to reduce issues with font rendering and have a good crossplatform way of handling it, it is necessary to create a tool which will build a PNG texture from a font, and embed into its data the glyphs positions.

We can also integrate some effects such as drop shadows, glows, etc.

In the future we can have a crossplatform font rendering / meshing library but that would require more work.

Out of the box , you cannot use h2d.scene to do deferred rendering due to event space not correct ( I don't understand all the code...).

My fix class :

class OffscreenScene extends h2d.Scene {
    var wantedWith : Int;
    var wantedHeight : Int;

    public function new(w,h) {
        super();
        wantedWith = w;
        wantedHeight = h;
    }

    override function screenXToLocal(mx:Float) {
        return (mx - x) * wantedWith / (stage.width * scaleX);
    }

    override function screenYToLocal(my:Float) {
        return (my - y) * wantedHeight / (stage.height * scaleY);
    }

    public function renderOffscreen( target : h2d.Tile) {
        var engine = h3d.Engine.getCurrent();
        if( target == null ) {
            var tw = 1, th = 1;
            while( tw < width ) tw <<= 1;
            while( th < height ) th <<= 1;
            var tex = new h3d.mat.Texture(tw, th,false,true);
            target = new h2d.Tile(tex, 0, 0, Math.round(width), Math.round(height));
            #if cpp 
            target.flipY();
            #end
            target.getTexture().alpha_premultiplied = true;
        }

        var oc = engine.triggerClear;
        engine.triggerClear = true;
        engine.begin();

        engine.setRenderZone(target.x, target.y, wantedWith, wantedHeight);

        var tex = target.getTexture();
        engine.setTarget(tex,false);
        var ow = width, oh = height, of = fixedSize;
        setFixedSize(tex.width, tex.height);

        render(engine);
        width = ow;
        height = oh;
        fixedSize = of;

        engine.setTarget(null,false,null);
        engine.setRenderZone();
        engine.end();
    }
}

I use it with some structure like

var game : OffscreenScene
...
game.renderOffscreen(tileRender);
engine.render(render);

i don't know if the feature is of any interest for you but nonethelss I think the Scne class should behave well out of the box for such a usage ( which is very frequent for post processing the image)

Bisous !

The README, which greets potential users, states the library only supports Stage3D, but it seems like some closed issues are regarding support on other platforms.

Could the readme be updated as to the current state of target platform support, and perhaps OpenFL compatibility, etc? It would be appreciated!

h3d/impl/Shader.hx:39: characters 2-11 : Class not found : h3d.impl.Shader.ShaderMacros

for example h2d.Tile.fromColor(0x4B555F, 50, 50), nearly always get my programmers to miss the alpha bytes( after every weekend basically)...

I suggest we change from :

h2d.Tile.fromColor( rgba_color,w,h )

to

h2d.Tile.fromColor( rgba ,w,h, alpha=1.0 ) (final a = rgba.a*alpha )

or

h2d.Tile.fromColor( rgb ,w,h, alpha=1.0 ) 

Thanks !

We need to support in Material the following additional blending properties supported by WebGL:

• blendFuncSeparate, which enable separate blending for color and alpha (for instance adding alphaBlendSrc, alphaBlendDst to material)
• color value for ConstantColor/ConstantAlpha blendModes
• equation value (Add,Sub,ReverseSub) for both blendEquation and blendEquationSeparate

Please write simple parser for obj to test your lib.

demo: https://dl.dropbox.com/u/1036911/h3d/contextLost/index.html

src: https://gist.github.com/4701470

Buffe code is perfect in features, we have awesome tools but their used is marred by self obfuscated design.

We should derive buffer into Streams and Buffers.

Buffers wil be stream containers, That would make working with interleaved data easier and allow more easy stream binding.

In fact opengl has the same semantic and we can make it better.

Allocation should be provided by classes explicitly stated as 'Allocators' because current impl is self allocating, makes it hard to understand how to work with them.

In the current math flow :

The scene premultiplies the vertices and transforms by its ortho projection. Hence the shaders receives prescaled vertices and internal 2d primitives values are scaled on the fly.

The advantage it that you don't have to pass a matrix uniform for vertex projection of 2d objects

During our talked with NC, we agreed it add unnecesssary difficulties working with primitive local or global transforms since you can't easily extract screen coordinates. For example extracting the global orientation of a mere bitmap is a challenge.

We 'll try to provide powerful primitives to retrieve them ( screen space bbox, global transforms) easily but in the end we might want to switch pre scene scaling with a more classical ortho matric on the shader approach, vertex shaders for 2d is usually nearly free and data will be way easier to work with.

thanks.

The ability to manage a selection range for Input text

Regarding resource management:

It is necessary to separate the resource tree, which is a way to map a directory in a type safe manner, from the resource storage which can be either sync/async and embedded or loaded from disk.

• have hxd.File? which can be use to embed resources and get them back
• have hxd.Resource to map a directory to a tree of ressources, using hxd.File in the backend (can be extended to provide extra extension management ?)

I implemented premultiplied alpha and my final step is to add a flag stating that data is premultiplied in h3d.mat.texture.

I leave a note here so that we don't forget it when merging with heaps..

It looks like drawCircle() produces artifacts when producing circles with small radii or circles with small nsegments.

Example:

class Circles {

    var engine : h3d.Engine;
    var scene : h2d.Scene;

    function new() {
        engine = new h3d.Engine();
        engine.onReady = init;
        engine.backgroundColor = 0xFF000000;
        engine.init();
    }

    function init() {
        scene = new h2d.Scene();

        var g = new h2d.Graphics(scene);

        // small circles
        for (i in 2...9) {
            g.beginFill( 0xffffff );
            g.drawCircle( (i - 1) * 100, 100, i);
            g.endFill();
        }

        // large circles, small nsegments
        for (i in 3...10) {
            g.beginFill( 0xffffff );
            g.drawCircle((i - 2) * 100, 200, 30, i);
            g.endFill();
        }

        hxd.System.setLoop(update);
    }

    function update() {
        engine.render(scene);
    }

    static function main() {
        new Circles();
    }
}

Output:

The number of segments in the resulting polygon/circle is correct, but it feels like we are missing another vertex in the polygon before wrapping back to the first point.

XBXMake can not build some fbx files
XBXMake.hx line 233
XBXMake.hx line 55
.....
uncaught exception -unexpected kaydara

When we exceed the max number of bones (currently 34), we should be able to split the draw calls and have different bones palettes for each call.

The problem is that some vertex might be used in two draw calls so the bones they use should be at a fixed position in the palette.

Another option is to reindex the triangles. Anyway this require indexes to be processed.

Since FP 11.4 stage3d.requestContext3D() has second parameter: baseline. Setting baseline as "baselineConstrained" by default will significantly increase amount of supported GPUs:
http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/display3D/Context3DProfile.html#BASELINE_CONSTRAINED

You should implement it by this way:
https://github.com/PrimaryFeather/Starling-Framework/blob/c418e430bf86f640f467edc094842f28aead7c0e/starling/src/starling/core/Starling.as#L275

@ncannasse Just a quick reminder to hint you that your z buffer setup for Gl is reversed, in Mtwin branch we inverted the z-buffer range values, the initial z-clear and reverted your inversion on GL constants to reflect stage3d/directx render path. It allows us to avoid branching anything.

see mtwin branch and diff the gl driver if need be.

bye bye !

In a similar manner to h2d.Interactive, we should have h3d.scene.Interactive that takes a primitive as hitbox shape.

TODO : How to handle complex animated things such as skinned meshes ?

This code is problematic since it rebuild a direct triangle list, thus ruining the index etc.. In fact vertex volumes goes from x3 to x8 and cause major performance hit on phone since animations vertex shaders are recomputed a big lot.

What should we do :

on load, we should triangulate like its done, then reweld the mesh and keep vertex mapping all the way s taht we can morph the geometry.

In order to support WebGL/GLES, we need to add a few abstractions:

• h2d.BitmapData which replaces flash.display.BitmapData, mostly manipulate Bytes (check how to load such bytes in JS)
• h3d.Floats which replaces flash.Vector as a way to have an auto-resized Float specialized buffer which we can append data to
• h3d.Indexes, the same as h3d.Floats but for (16 bits?) indexes

haxe engine.hxml gives me:

h2d/col/Voronoi.hx:24: lines 24-31 : Recursive constraint parameter is not allowed

haxe version is 3.0.0

H2d should be offset into another lib because h3d is getting to fat, It is a powerful library but having it nested makes working with the h3d cognitive space less cool. Also it is inconvenient to maintaint all the code base for 3d only projects.

Also, some people might want to implement their own 2d framework and not undergo h2d impl.

I understand how this can seem unnecesssary but I DO really feel it is the exact right time to do this.

• in 2D DisplayObject Such as h2d.Text , How to move the Rotation point from the upper-left to Center??
• 2D-DisplayObject have something like rotationX y properties?

sorryfor my poor engslih

Scaling the h2d.Scene is not properly supported atm. This needs to be handled (requires fixing event handling and mouseX/Y as well)

Currently visible child elements are taken into account when calculating bounds. We might prefer not to do so.

C:\Users\志>haxelib install h3d
No such Project : h3d

Performance on embedded devices with cpp are marred by 64 bit floats, we should fallback the engine to something like

if cpp

typedef F32 = Single

else

typedef F32 = Float

end

and leverage openfl to accept Singles.

This would allow vector optimisations by the C compiler and be less aggresive for caches.

Sorry for nitpicking, but you may want to change name of the h3d.parts.Emiter class to Emitter (double "t") to make it proper english word :)

Currently h3d.Camera uses "half-fov" angle, which is not very user friendly. Using full fov and controlling wether setFovY works as expected

Benjamin said WIkipedia formula works better

fovX = Math.atan( Math.tan(value * (Math.PI / 180) / 2 ) * screenRatio ) * 2 * (180 / Math.PI);

Hi,

We should convert the project to actual english, renaming childs to children and freezed to frozen, i ll leave it for an after merge MT<>heaps because otherwise all hell will break loose.

Invisible interactive still receiving/handling events (while it should not)

H2D UI components use "div" for defining boxes in the markup, while CSS selector for boxes is "box" which is very confusing for people knowing CSS and seems to be a mistake.

I would rather call it "box" instead of "div" in the markup to be honest, because it's not really HTML after all :)