ElementFactory only uses default Position, Facing, and Bounds

[GoogleCodeExporter]

Someone who gets the XML better than I do (I'm looking at you, Omer) needs
to change ElementFactory so it doesn't only assign default position,
facing, and bounding box.

It needs to look through the XML for the proper tags and then construct the
values. Only use the defaults if the tags haven't been specified.

The tags should be:
<element>
   <center>x
   <center>y
   <center>z
   <rotation>rotX
   <rotation>rotY
   <rotation>rotZ
   <bounds>x-length
   <bounds>y-length
   <bounds>z-length

Original issue reported on code.google.com by joelwr...@gmail.com on 14 Mar 2007 at 5:40

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

• Changed state: Fixed