Apparently it's not possible to merge more than two cubes. It always
returns an error when trying to add the third cube, using apply or
applyToContainer.
The error is trying to get an indice which does not exist (Merge.as
line 198):
for (j = 0; j < vecLength;++j){
index = indices[j]*3;
indexuv = indices[j]*2;
Using the apply method, i create 3 meshes:
_merger = new Merge(false, false, false);
_merger.apply(_mesh1, _mesh2);
_merger.apply(_mesh1, _mesh3);
_view.scene.addChild(_mesh1);
If i change the order, trying to add the double cube (_mesh1) to a
single one (_mesh3), only two single cubes appear on the screen. No
error though.
_merger = new Merge(false, false, false);
_merger.apply(_mesh1, _mesh2);
_merger.apply(_mesh3, _mesh1);
_view.scene.addChild(_mesh3);
I think it's probably something related to the patch you received. In
the error the vecLength value is 72, and the indices vector length is
36. Seems like it is after all a problem due to the shared vertices.
Thanks for the info Fabrice, i'll keep testing and trying other ways
to merge them succesfully.
On May 4, 5:18 am, Fabrice3D <[email protected]> wrote:
> PathExtrude, as the name suggests, allows you to project a profile along a
> path definition, so I do not think this would fit your needs.
> PathDuplicator, allows you to clone objects along a path. that can be any
> Mesh object.
> in an upcomming update I will add the option to merge. right now, if you pass
> a cube, it would clone and align to path all the duplicated cubes
> with this option, you will end up with one mesh sharing geometry for each
> duplicated cube.
>
> Another option of this class, is to pass a container, this way if you make a
> "myforest" container and pass a tree mesh, all the trees are added to this
> container "myforest".
> The idea behind has nothing to do with geometry, its made to allow you to
> toggle parts. like "show trees" so you do not have to loop over the
> duplicated objects to id which one is a tree
> if you have multiple kinds of objects.
> What you could do now, is then to ask the Merge class to make a single mesh
> of it. Note here that i've received a patch for Merge class that i need to
> add.
> So where my tests were successfull, the patch shows that depending on wether
> or not vertices are shared, the code may or may not fail for now. So it is
> possible
> that merging this cubes would work, tho no garanty till I have conducted more
> tests and patched the class.
>
> but if your cubes are spreaded like on a grid, probably the easyest way to
> proceed is simply to make one cube, and save its vertices as reference.
> then loop for your cube count and add this vertices data to the mesh applying
> each iteration the offset position of each new cube.
>
> Fabrice
>
> On May 3, 2011, at 9:44 PM, Agoth wrote:> Is it possible to use PathExtrude
> to reproduce all the cubes (or any
> > other primitive) inside the same mesh? Maybe it'd be possible to
> > create "the grid" this way, having just one mesh instance on the
> > scene.
>
> > When you say mapping does you mean changing the UVs directly? Thanks!
>
> > On May 2, 6:58 am, Fabrice3D <[email protected]> wrote:
> >> As said in previous replies,
> >> use one or few meshes to store the geometry, just keep track of indices if
> >> you need to alter/access the data
> >> think that mapping can help you a lot, as submeshes must be generated if
> >> materials are different.
>
> >> Fabrice
>
> >> On May 2, 2011, at 11:26 AM, rjgtav wrote:
>
> >>> hi Fabrice. In my case it is a tilebased game that is built in a for
> >>> loop, from a 3dimensional array. What do you suggest for increasing the
> >>> performance?
