At 11:09 AM -0400 8/19/05, Joseph Nastasi wrote:
OK, we'll look into that (though I thought it was the opposite --
it was claiming intersection when the bounds were actually far
apart?).
Ha, yes that's what I mean. Love them double negatives. It's a false positive!
OK, got it.
Well, yes -- that's the whole point of UpdateBounds. It updates
the bounds to fit the object's current size, orientation, and
position. If you don't want it to update the bounds, then don't
call that method.
Wait, ComputeBounds changing the radius I understand, but
UpdateBounds is supposed to change the Radius?
Yes. And ComputeBounds doesn't *change* anything; it constructs and
returns an entirely new Bounds3D object for you.
I understand that it would internally need to know the new
boundaries internally, but if it changes Radius, what is the point
of being able to assign it manually?
For cases when you want to manage your bounds manually, instead of
automatically. You can have it either way: assign it (and update it,
as desired) manually, or have it updated automatically. But when you
have it updated automatically, of course this negates any manual
tinkering you have done.
The reason I do it is because ComputeBounds creates a Radius that
is far too large and causes Intersect to be true when it doesn't
appear that way visually.
Aha. And I presume UpdateBounds does the same thing. So the problem
here is in how the bounds are being calculated for your object, and
not in the intersection test.
Even if I do not call UpdateBounds directly, the same thing happens
when RB3DSpace is update if the objects in question are being
rendered.
Right. That's a feature; if you have a Bounds3D stored on
Object3D.Bounds, then we update it for you upon rendering. For games
where most of the objects are moving around most of the time, this is
very handy, as the bounds are always correct and ready for collision
testing. For objects that are NOT moving around most of the time,
it's rather wasteful, since those bounds don't need to be updated.
So, in the Renegades engine, I chose to keep the bounds separately
(in an mBounds property on an Object3D subclass), so that the
framework wouldn't update them. Then I update them manually as
needed.
Really, I should be able to set a radius that is smaller than the
actual geometry and have Intersect respect and use that.
Right?
Yes, and so you can. Just don't let it be Updated (which does mean,
you'll have to store this somewhere other than the Object3D.Bounds
property).
So, while I haven't looked at your report yet, I'm starting to think
perhaps there is no bug here. Is it that you're trying to use a
bounds much smaller than the actual geometry, but the auto-updating
is expanding this to fit the actual geometry, which is then causing
the intersection to report true?
Best,
- Joe
--
Joe Strout REAL Software, Inc.
Vote for REALbasic (twice!) in the LinuxWorld Reader's Choice Awards:
http://linux.sys-con.com/general/readerschoice.htm
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
|