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 <fabric...@gmail.com> 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 <fabric...@gmail.com> 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/away3d-dev@googlegroups.com/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
