There is a little nuance to your comment: here's the logic: when the mesh to be merged must not keep own material, it's data is added to the last subgeometry of the mesh and inherits its material.
when keepmaterial is true the code doesn't add a subgeometry (here comes the nuance) it first look if it can find a subgeometry shared the same material so if and ONLY if the material is not to be found in gteh reciever mesh, it will add a new one, even if there is room in other subgeometries simply because each upload can have only one material reference. If you read back older mails, you will notice I have said to you: offset the uv's and scale them down or apply any kind of logic to them so that a larger amount of cube can share the same material, yet look like if they are all unique. It would be, even from a classic cpu flash perpective very optimistic to expect flash to run ok with hundreds of maps on screen. Not even talking about the loading nightmares, the bandwidth that would bring with it etc... basically if you do not change the uv's, you're looking at the worst case scenario for this class. To answer John's question on the diff in vertices length from 72 to 108, that's because I do respect the smoothing of the surfaces. A smoothed mesh holds less vertices/uv's than indices, while a flat shaded one holds exactly same amount. If the mesh would have been manipulated so that its using both flat and smoothed parts then the count lays in between the two values. Because I do not want be lynched, I have written the class so that it respects this finishes without adding the cost of a massive compair to find doubles in case of shared vertices during generation. Therefor, new normals are either rotated, recalculated or kept as is as often as possible, but indices even pointing at same ref value are becomming unique, no matter if they were shared or not. In short, unless I did wrong, the data is most of the time reorganized in an optimized way to allow massive generations and still run fast while retaining the sources appearance. Yet doing all this as fast as possible. That explains the 17 subgeom compaired to your expected 9000+ which is a substantial improvement I think ;) > if i set its material to null, the loop never ends This is something that I must check. I'll look into it asap. Fabrice On May 13, 2011, at 1:41 PM, rjgtav wrote: > Ok, what I suspected is correct. When adding cubes of different materials to > the same mesh, with keepMaterial set to true, the length of vertices > increases so much that it takes an year to loop. > > Important Note: > In the main mesh (where i add all the cubes to it), if i set its material to > null, the loop never ends and the length of vertices keeps increasing till > its max (21678) > But, if i set a material to it, the loop only takes a minute and the length > of vertices at the beginning stay at 36, but only at the end they increase > till their max. > > (will post the class later)
