Hey Steve

the minX/maxX, minY/maxY etc values are calculated in the local coordinates
system of the object, so transformation scaing etc. have to be applied
separately to get an external value, or you can place the object inside an
untransformed objectcontainer3d and return the min/max values from that.
bear in mind that to save processing, containers calculate min/max bounds
from bounding radii of the child objects rather than AABB.

hth

Rob

On Thu, Nov 20, 2008 at 10:05 AM, slhenty <[EMAIL PROTECTED]> wrote:

>
> Thanks, Rob! That completely fixed the min/max values.
>
> I'm discovering some additional anomalies with jeep.scale() (or
> jeep.handle.scale()... not sure which to use) where the min/max values
> are not scaling like they did in 1.9.4. I wouldn't worry about it --
> given the lack of scaling isn't affecting the way the model is
> displayed -- but that I'm apparently not grokking how the various
> coordinate frames are related.
>
> I'm new to 3D in general, and I'm just coming up to speed with how a
> rendering pipeline manages all the transformations among coordinate
> frames (model, world, view, etc.) with the help of a gaming math
> reference book. Still, I'm not clear how Away3D manages these frames,
> or what the frame hierarchy looks likes (e.g. the relationship among
> world, ObjectContainer3D, Object3D, meshes within a loaded model,
> etc.)
>
> Is there some reference I haven't spotted, yet?
>
> Best,
> Steve
>
>
> On Nov 19, 5:01 pm, "Rob Bateman" <[EMAIL PROTECTED]> wrote:
> > Hey slhenty
> >
> > sorry for not answering your post sooner
> >
> > the problems you are experiencing are due to the default way 3ds meshes
> are
> > stored - all mesh objects have the same registration point (positioning)
> > when imported into away3d, and when calculating bounding boxes (and minX
> > maxX etc positions), bounding radii are used from the child objects to
> > simplify calculations. Bounding radii are calculated by determining the
> > distance to the vertex in a mesh the furthest away from the meshe's
> origin
> > (0, 0, 0)  point. However, because all meshes have the same positioning,
> > this calulation will not accurately calculate bounding box values for the
> > parent object
> >
> > to combat this problem, a property called centerMeshes was introduced to
> the
> > loader classes. This would take the points in a mesh, and relocate their
> > registration point to the central point of the mesh geometry. This gives
> > better bounding radii calculations, and hence better bounding box
> > calulations for the parent.
> >
> > that's the long answer. ;) The short answer is: centerMeshes is a
> property
> > that help with these calulations. In 1.9.4 it used to be set to true by
> > default. But this was causing problems with imports elsewhere, so in 2.0
> it
> > was altered to be false by default. To achive the same results that you
> get
> > from the 1.9.4 demo in the current code release, change this line:
> >
> > jeep = Max3DS.load("images/jeep1.3ds", {texturePath:"images/",
> > name:"jeep", loadersize:100});
> >
> > to this:
> >
> > jeep = Max3DS.load("images/jeep1.3ds", {texturePath:"images/",
> > name:"jeep", loadersize:100, centerMeshes:true});
> >
> > and you should be set
> >
> > cheers!
> >
> > Rob
> >
> >
> >
> > On Tue, Nov 18, 2008 at 4:59 PM, Li <[EMAIL PROTECTED]> wrote:
> > > Hey, I dont have time to look at the source right now, but in the
> meantime
> > > you can try something. When I have these type of problems, I always use
> > > LineSegments to perform graphical traces, this is an example method for
> > > this:
> >
> > > private function drawSegment(x1:Number, y1:Number, z1:Number,
> x2:Number,
> > > y2:Number, z2:Number, obj:Object3D, color:uint):void
> > >         {
> > >             var mat:WireColorMaterial = new WireColorMaterial(color);
> >
> > >             var seg:LineSegment = new LineSegment({material:mat});
> > >             seg.start = new Vertex(x1, y1, z1);
> > >             seg.end = new Vertex(x2, y2, z2);
> > >             ObjectContainer3D(obj).addChild(seg);
> > >         }
> >
> > > Ill look at the source when I have some time!
> > > Cheers
> >
> > > On Tue, Nov 18, 2008 at 2:04 PM, slhenty <[EMAIL PROTECTED]> wrote:
> >
> > >> Here is my original post from last week, with the source embedded,
> >
> > >>http://groups.google.com/group/away3d-dev/browse_thread/thread/3d80a6.
> ..
> >
> > >> Any insights are much appreciated.
> >
> > --
> > Rob Bateman
> > Flash Development & Consultancy
> >
> > [EMAIL PROTECTED]




-- 
Rob Bateman
Flash Development & Consultancy

[EMAIL PROTECTED]
www.infiniteturtles.co.uk
www.away3d.com

Reply via email to