Closed GoogleCodeExporter closed 9 years ago
Hey, Joel! I completely agree about the need to have the option of specifying an
element-level bounding box (any particular reason that it's three lengths
rather than
eight points?), and probably element-level rotation too, but element-level
center is
likely something that should be determined by the World's XML file, since the
default
elements don't actually exist in the World (they are just used to instantiate
real
elements with ElementFactory's getGameElement function, and then _those_
elements
need a center in the World). Or, do you disagree?
Original comment by Omer.Ba...@gmail.com
on 14 Mar 2007 at 5:49
Okay, I see how the World's XML file will specify the center and stuff. I guess
I got
confused because we don't have a World XML file to look at yet :p
I specified three lengths because it's easier to determine and write in (by
hand at
least). Also, the points need to be in a very, VERY specific order. So I figure
it
would be better for the user to specify length, width, and height, and then
have the
machine go through and actually create a bounding box that matches those
parameters
and can be handled by the collisions function (so has the points in the proper
order). Plus it keeps the XML more tidy since there are only 3 tags instead of
8 on
every element.
Original comment by joelwr...@gmail.com
on 14 Mar 2007 at 8:56
Good points! What would you say about making both options, e.g.:
<bound type="vector">
<value>x</value>
<value>y</value>
<value>z</value>
</bound>
OR
<bound type="box">
<point>
<value>x</value>
<value>y</value>
<value>z</value>
</point>
<point>
<value>x</value>
<value>y</value>
<value>z</value>
</point>
...
</bound>
It'd be easy enough to parse in the ElementFactory, and that would make it so
that
editors/users could specify more complicated bounding boxes (any polygon,
actually...
well... depending on how you're doing the collision detection :P), and it would
save
us computing time when the game starts up.
Original comment by Omer.Ba...@gmail.com
on 14 Mar 2007 at 9:07
Works for me. I have no problem with added options. But because we don't have a
GUI
yet, I wanted to have something that was easy to manually type in.
At the moment collision detection works on a bounding BOX. That's it. I gave up
generality for speed. By requiring a 3D box (as opposed to an n-D polygon, or
even an
n-D box) I cut the work load to about 20-30%. But I also divided the method so
that
it's pretty easy to include different kinds of detection, specified either by
the
element or by the resolver.
And again, because the system is currently inflexible, one wrong value for a
point
can mess it all up. But we might as well include both. You just have to parse it
already ;)
Original comment by joelwr...@gmail.com
on 14 Mar 2007 at 10:00
Change of plans. Bounding box will be specified by half-dimensions (so the
distance
from the center in each of the three cardinal directions), AND ONLY in
half-dimensions. Why? Because there is an absolutely beautiful algorithm for OBB
collision detecting using half-dimensions. It's perfect:
1) We only need to store 3 floats
2) It's a fast check--instead of probably 100 checks, we're doing like 100
operations
TOTAL (in worse-case senario).
3) I managaed to get it mostly implemented and it works.
4) Best of all--we don't ever have to change the bounding box. The algorithm is
dependent on the half-dimensions (which are specified at initialization), the
position (which we have) and the facing (which we have). That's it! We have to
jump
through a pair of hoops to get the facing into a format we can use, and then
presto!
It all works nicely. So instead of having to do that nasty vector rotation using
Quaternions, we now just have to occassionally convert into a matrix (pretty
fast)
when we want to check a collision! And we don't have to pass the BoundingBox
along
through the network! We get collisions at no extra cost (as opposed to the
extra cost
of the float[][] box).
5) We also get almost free Bounding Sphere checking if we pick a way to choose
the
sphere radius from the box radii (say either the longest, the average, the
X-length,
something like that).
So if an object is going to have a BoundingBox (a rectangular cube), it will be
specified with half-dimensions in the form of three floats. However, that
doesn't
mean we can't also have different kinds of bounding polygons. Maybe our XML
will look
like
<bounds>
<box>
<half-dimensions>...
<polygon
<points>...
It is really really hard to specify a random bounding polygon (and then use
it!), but
it is doable. Maybe we'll just take the mass of specified points and
deconstruct into
a tree of OBBs (there is an O(nlogn) algorithm for doing that).
So yeah. I'm out of time for today so I'm not going to get collisions fully
implemented, but they should be there on Monday.
Original comment by joelwr...@gmail.com
on 16 Mar 2007 at 9:48
Issue has pretty much been resolved. ElementFactory now reads in <bounds> tags,
and
WorldFactory deals with specified position and rotation. It has been decided
that
ElementFactory will not specify position or rotation, and that that information
will
always be present in WorldFactory. This means that we may have to tweak
something
somewhere so that new players are always added into the origin, but this can be
changed once we have some method for determining Spaces (and once we have some
kind
of persistance across accesses).
Original comment by joelwr...@gmail.com
on 27 Mar 2007 at 8:12
Original issue reported on code.google.com by
joelwr...@gmail.com
on 14 Mar 2007 at 5:40