createInstance not cloning Children.

[Pryme8]

So I have a scene where I am creating presets, and a few of them have children.

When I try to createInstance of the preset None of the children come through, even though I can see them in the presets._children array, but they do not appear in the new instance.
Ive noticed they have the flag of hasChildren = -1, or something like that, would that be causing them to get skipped?

Also I tried to do a workaround where i looped through the child array and created instances of them, but that ended up making my draw calls in the thousands.
I tried to see what was going on by then just doing a simple preset.clone() and that worked as expected with the children coming through, but one draw call for each object now instead of each instance.

Im thinking createInstance is bugged?


*EDIT after reviewing the documentation I think I may need to use synchronizeInstances
**EDIT EDIT... nope unless im using it wrong...

[Pryme8]

http://babylonjs-playground.com/#ISZHF#0

quick demo proof.

it works if you set the visibility of the object to false:
http://babylonjs-playground.com/#ISZHF#1
but looks like it does not effect the children and I would have to make a recursive loop to set all the visibility off on the original Parent mesh?


*EDIT

Nope none of the children carry over period:

http://babylonjs-playground.com/#ISZHF#2

[Pryme8]

@Wingnut, @adam, @NasimiAsl, @Deltakosh, @iiceman, @Dad72

I just tagged a couple heavy hitters to have you guys hopefully address this with me today, I have a clients project hitching on this and normally I would not press so hard but Im on a time limit.  I can move on to other things and use a work around of cloning the presets that have children but that is far from optimized and will lead to way to many draw calls once the scene is done...  We have a couple thousand unique objects and buildings.

[Dad72]

If the houses uses the same textures for example, you can merge your objects that share the same textures.

In fact, you clone your identical objects and you merge them into a single object. Then you can create instances of the merged object.

And use as octree to optimize the scene.

I do not understand your parenting meshes on the PG.

[adam]

I think you're going to have to create instances of the children too:

http://babylonjs-playground.com/#ISZHF#3

[Wingnut]

I agree.  Clone() will make new children (if you don't set doNotCloneChildren), but not createInstance.

http://babylonjs-playground.com/#ISZHF#4

Simple to test.

[Pryme8]

So I think what dad is saying is prolly going to be the close to what I want.  So I need to make the submeshs on what ever and then merge them?  I figured inherently the createInstance function should carry over the children of the original mesh.

Something does not seem right, because to my understanding of how an instance should work is it should be almost a exact clone of the parent object just without some independent variables, to where if I moved one of the child meshs on the parent mesh and run and update on the Instances, all instances should have their child move.

What I am seeing as a bug, is the children do not carry over onto the instance object what so ever unlike a clone.  I cant use clones because it will way bring the draw calls out of scope.

In trying what adam said, I tried that method, but by the end of the construction of the scene the draw calls were like at 1200 instead of 321 like when I tested with cloning to figure out wtf with the children. 
@adam ill see if I can replicate that draw compounding in a PG really fast.

Somethings not right. Thanks for your help guys I have a facetime meeting with the client at 11 and I want to have a work around before then hopefully.



***UPDATE
Ok I must have something wrong with how I was instancing the children. Because I could not get the compounded draw calls, after Instancing the children it seemed to work this time... but that's still odd we cant carry children over on the createInstance, I feel like it should function like clone() with its parenting param.

http://babylonjs-playground.com/#ISZHF#5

3 draw calls is what was expected though so Ill figure out what I was doing wrong on my children loop in my program and go from there, thanks guys.
@adam - I got it working with instancing the children on a simple loop, they are only ever going to be one level down so non recursive will work, thanks for that I dont know why I ended up with


Also can we drop the bounding boxes into a separate drawcall count on the debug UI?

 

 

Also my clickable labels stopped working for some reason.

[Dad72]

What there is to know with the instances and the clones is that this includes instances like ghosts of the base mesh. they can not be modified in relation to clones. Clones are copy of the base mesh. The mesh cloned is loaded once and quickly create copy (the gains is the loading of the scene that only support a single object and copy on the fly the mesh)

Me, I use clones on objects, after I merge the same meshes, then I instanciate if necessary (in the case of city, All that is vegetation I create that  instances). Then I apply a octree to end.

After my ways of doing is personal preference, but gives good results in general for optimization. In terms of textures I also create textures only 512*512. I avoid 1024*1024 which are heavier to load.

[Pryme8]

If you do that, how do you apply physics to each object independently?  Like so each street cone was a single mesh you could not just knock one over then right?

[Dad72]

In fact I avoid using physical, but you can use physical objects on it to clone receive collisions. Is the character who receives the most physical (pulse, gravity, restitution velocity...).

But I prefer to avoid the use of the physical. I use collisions and other offered babylon and consumes less that the physics

The cloned objects clone impostor logically, but I did not really try it.

[Pryme8]

@adam I owe you big time bro, you saved my product presentation.  If you need anything from me at anytime let me know.

[iiceman]

Ah, I am too late, but sounds like you already solved the problem.

[NasimiAsl]

i am not good in this stuff but look your scene and your material

clone is faster plan always 

too late