Someone provided me a case class I could test on yesterday.
I've found and fixed a bug where extra subgeometries were added.
Explains why the MeshHelper recenter was failing and also why using apply 
method in a loop was that slow...

Fix is uploaded.

Fabrice


On Aug 2, 2011, at 6:36 PM, DBird wrote:

> I thougt is 1 by default:
> 
> Cube (material:MaterialBase = null, width:Number = 100, height:Number
> = 100, depth:Number = 100, segmentsW:uint = 1, segmentsH:uint = 1,
> segmentsD:uint = 1, tile6:Boolean = true) …
> segmentsW: The number of segments that make up the cube along the X-
> axis. Defaults to 1.
> 
> ...but to test it, I used this piece of code:
> 
> var cube1:Cube = new Cube(colMat, 100, 200, 100, 1, 1, 1);
> var cube2:Cube = new Cube(colMat, 100, 200, 100, 1 ,1 ,1);
> 
> 48 Polys after the merge... :(
> 
> Cheers,
> Dirk
> 
> On 2 Aug., 16:07, Fabrice3D <[email protected]> wrote:
>> The Cube primitive class doesn't have the same default subdivisions in both 
>> engines.
>> and in your Cube constructors code you do not set them.
>> 
>> Fabrice
>> 
>> On Aug 2, 2011, at 2:41 PM, DBird wrote:
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>> Hi Fabrice,
>> 
>>> I'm still on the merge-problem. Perhaps you could give me a quick info
>>> about that.
>> 
>>> I'm using the merge-class to put cubes together, something like this:
>> 
>>> // Creating my "word-Cube" witch persists
>>> var myCube01 = new Cube( { material:"green#lime" } );
>>> myCube01.x = -300;
>>> view.scene.addChild(myCube01);
>> 
>>> // Creating the source-cube, for adding cubes as often as needed
>>> var myCube02 = new Cube( { material:"green#lime" } );
>>> myCube02.x = -150;
>>> // and not adding it to the scene. the merge-object will do this.
>> 
>>> // create MergeTool
>>> var merge:Merge = new Merge(false, true, false);
>> 
>>> // Merge them baby
>>> merge.apply(myCube01, myCube02);
>> 
>>> // After that we have 3 Cubes, because i put myCube02 again in
>>> myCube01. is like a copy of it.
>>> myCube02.x = 150;
>>> merge.apply(myCube01, myCube02);
>> 
>>> After testing this with Away3.6 and Broomstick I got these results
>>> from the debug-panel:
>> 
>>> Test with Molehill & Broomstick
>> 
>>> Cubes      Polys normal    Polys after merge
>>> 2          24                      48/0
>>> 3          36                      144/0
>>> 4          48                      384/0
>>> 5          60                      960/0
>> 
>>> Test with FP10.2 & Away3.6
>> 
>>> Cubes      Polys normal    Polys after merge
>>> 2          07/24           07/12
>>> 3          11/36           11/12
>>> 4          15/48           15/12
>>> 5          19/60           19/12
>> 
>>> What is happening with the molehill-test? A bit to many polys...
>> 
>>> I thing, because of this I can't compile your example
>>> http://www.closier.nl/broomstick/mergetest.html
>> 
>>> Any idea?
>> 
>>> Thanks again in advance!
>>> Dirk
>> 
>>> On 30 Jun., 15:23, Fabrice3D <[email protected]> wrote:
>>>>> Yes they are, but this sounds a bit more tricky...
>> 
>>>> not really trickky, just a bit more work, a brick = from / to
>>>> so if you loop over the mesh indices vector, you simply increase count + = 
>>>> mybrickfacecount
>> 
>>>>> To get one "brick" out (to delete it), i have do some vertice-operation 
>>>>> or a
>>>>> complete rebuild without that deleted brick. is this correct?
>> 
>>>> yes and no.
>> 
>>>> yes it is correct you can do this way.
>>>> no, you could ask FaceHelper class for this dirty job ;)
>> 
>>>> Fabrice
>> 
>>>> On Jun 30, 2011, at 2:08 PM,DBirdwrote:
>> 
>>>>> Wow, that's really good news! Thank you very much.
>> 
>>>>> Ah, and for all who what to watch it, here is an example from Fabrice:
>>>>> http://www.closier.nl/broomstick/mergetest.html
>> 
>>>>> ... and some addition background information:
>>>>> http://www.mail-archive.com/[email protected]/msg21091.html
>> 
>>>>>> if your bricks have exact same face count, it would be also easy to 
>>>>>> alter them vertice wize into the buffers.
>>>>> Yes they are, but this sounds a bit more tricky...
>> 
>>>>> After some code-reading I found out, that after the merge, there is no
>>>>> access to all my objects I have merged in my master-mesh. To get one
>>>>> "brick" out (to delete it), i have do some vertice-operation or a
>>>>> complete rebuild without that deleted brick. is this correct?
>> 
>>>>> Dirk

Reply via email to