Merge Class

[Pete Shand]

It seems the Merge class isn't working, anyone else experiencing this?

[Pete Shand]

For anyone else experiencing the same issue, change the follow to resolve:
line 148 to:
destGeom = new Geometry();

and add the following line to the bottom of the private merge functuion within Merge.hx:
destMesh.geometry.addSubGeometry(destGeom.subGeometries[0]);

[Greg Caldwell]

I just tried the Merge class without any changes and it seemed to work for for my example. Simply having a plane & a sphere then using the 'apply' method.

Did you have an example that was failing?

[Pete Shand]

Hi Greg

What target are you using? This issue only effects the html5 target

[Greg Caldwell]

Ah - I tried mac (cpp). I'll give html a go and see. Thanks

[Pete Shand]

I think it has to do with the fact that the geometry is being overridden by a new Geometry object, Due to slightly different interpretation of the syntax. So any references to the Geometry object are getting lost. Instead the subGeometries need to be added to the current Geometry object

[Greg Caldwell]

Just a quick update.... All the data from the merge seems to be working e.g. vertices, indices, etc that I've seen, so it seems like there is some invalidation that's not occuring on HTML. It also occurs targetting Neko as well. What's weird and is a bit of a workaround is to simply clone the resulting mesh and that (from my tests anyway) seems to fix it, without the changes.

Still looking for the missing bit though

[Jeff Ward]

FYI, I'm trying to merge a bunch of cubes, and it crashes in neko, but works fine in html5 / linux targets.

var m = new away3d.tools.commands.Merge();
var result:Mesh = cubes.shift();
m.applyToMeshes(result, cubes);
scene.addChild(result);

>lime test neko
Called from ? line 1
Called from ApplicationMain.hx line 138
Called from ApplicationMain.hx line 51
Called from lime/app/Application.hx line 218
Called from lime/_backend/native/NativeApplication.hx line 120
Called from a C function
Called from lime/_backend/native/NativeApplication.hx line 274
Called from lime/app/Event.hx line 141
Called from lime/app/Application.hx line 107
Called from lime/app/Application.hx line 675
Called from openfl/display/Stage.hx line 1105
Called from openfl/_internal/renderer/opengl/GLRenderer.hx line 303
Called from openfl/_internal/renderer/opengl/GLRenderer.hx line 340
Called from openfl/display/DisplayObjectContainer.hx line 1007
Called from openfl/display/OpenGLView.hx line 185
Called from openfl/display3D/Context3D.hx line 668
Called from Basic_Shading.hx line 290
Called from away3d/containers/View3D.hx line 891
Called from away3d/core/render/RendererBase.hx line 237
Called from away3d/core/render/DefaultRenderer.hx line 60
Called from a C function
Called from away3d/core/render/RendererBase.hx line 276
Called from away3d/core/render/DefaultRenderer.hx line 102
Called from away3d/core/render/DefaultRenderer.hx line 164
Called from away3d/materials/MaterialBase.hx line 454
Called from away3d/materials/passes/CompiledPass.hx line 621
Called from away3d/core/base/SubMesh.hx line 234
Called from away3d/core/base/SubGeometryBase.hx line 145
Called from openfl/display3D/IndexBuffer3D.hx line 78
Called from lime/utils/ArrayBufferView.hx line 292
Called from /opt/haxe/std/neko/_std/Std.hx line 39
Uncaught exception - std@math_floor

[Greg Caldwell]

Hmm. Just tried the following, based on your code snippet and Neko worked fine for me on OSX.

    var cubes = new Array<Mesh>();
    for (i in 0...100) {
        var s = 25+Std.random(50);
        var m = new Mesh(new away3d.primitives.CubeGeometry(s, s, s), new away3d.materials.ColorMaterial(0x009900));
        m.x = -1000 + Std.random(2000);
        m.y = Std.random(600);
        m.z = -1000 + Std.random(2000);
        cubes.push(m);
    }

    var m = new away3d.tools.commands.Merge();
    var result:Mesh = cubes.shift();
    m.applyToMeshes(result, cubes);
    _view.scene.addChild(result);

Are you doing anything different?

[Jeff Ward]

I'm reusing the same geometry and material instance every cube I generate, but otherwise no. It could be a neko/linux thing...