On 8/22/07, Kai Sterker <[EMAIL PROTECTED]> wrote:
> So during the following days, I will look into the problems with the
> current object bounding boxes and try to come up with a plan. Chances
> are that it'll have to do some reading on basic 3D stuff up front, to
> get a feeling for how complex our object models need to get to allow
> for a fairly accurate collision detection. Any suggestions and input
> in that area is welcome.
After some browsing today, I stumbled across
http://www.peroxide.dk/papers/collision/collision.pdf
It's quite old, but it seems to cover everything we really need:
collision detection, gravity (i.e. falling and sliding), climbing of
stairs, etc. It's fairly easy to understand too; pretty standard math
and some sample code is included too.
Now, the only drawback is that character collision is calculated
against triangles, meaning that our objects would have to be composed
of those. I really don't want to go so far that a true 3D program
becomes required to create object models. At most, there should be a
set of basic shapes that could be scaled and transformed to fit the
underlying 2D graphic most closely.
My idea here would be to pick a couple of representative graphics and
figure out how they could be best portrayed by such shapes. These
shapes could later be decomposed into triangles by the engine, as
required for collision detection. I'll do some more reading on that
matter, but I also want to figure out the basic shapes we might need
to represent our objects. A post regarding this issue should follow
tomorrow ...
(OTOH, using an existing 3D modeler to create those basic shapes might
save us some work, so we should also consider it).
Finally, there is the matter of optimization. As the 3D data is not
used to actually render our objects, we can probably get rid of
transformations between world space and "eSpace" described in the
document above. But as people said before, this can wait. Compared to
real 3D environments, we'll probably end up with very small numbers of
triangle per scene anyway.
Kai
_______________________________________________
Adonthell-devel mailing list
Adonthell-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/adonthell-devel
