In article
<58ae07f8-ceb5-4d92-b424-1572a4d5a71c@[EMAIL PROTECTED]
>,
IsaacKuo <mechdan@[EMAIL PROTECTED]
> wrote:
> On Apr 4, 4:25 am, "Jens Hilwig" <jhil...@[EMAIL PROTECTED]
> wrote:
>
> > Im realy not familar with the different kinds of collision detection.
In my
> > case I have a kind of water pipesystem (3D Lines) and I have to check
the
> > connections and intersections of the lines. Because its a closed
system,
> > there are many connections and intersections between the lines.
> You mean some sort of static model of water pipes (i.e. not moving)?
> The pipes have a certain thickness--you surely have to account for
> that, right?
>
> This scenario has a few interesting complications, in that each line
> segment will typically share endpoints with at least two other
> segments.
> Thus, the "special" case where intersections are at the endpoints
> is actually the normal case.
>
> Also, in a typical water pipe system, most pipes will be aligned with
> a coordinate axis, and will exactly share a coordinate plane with many
> other pipes. This increases the chances of an intersection.
....But greatly simplifies detection! Also, it matters a lot if the
pipes are allowed to be anywhere, or have to be placed on a grid. That
is, can I have 2 pipes exactly parallel, but one of them is 1/4
pipe-diameter higher than the other? Or does the grid require that
parallel pipes either occupy the same space fully or fully-not?
Etc. There are lots of things that can simplify the answer, if we knew
more about your game.
> > There are no other elemets than 3D lines, so I think a classic
collision
> > detection is "too good" for my special problem. Im wrong here ?
> > If you know a "simple" collection detection that can handle my
problem,
> > please let me know.
> From what it sounds like, you need reliability and simplicity more
> than you need speed. Personally, I'd go with a dumb O(n^2)
> check between each pair of pipes. That's the easiest to implement
> and debug. You simply check each pipe against each other pipe
> with a couple nested FOR loops. That way, you just need to
> debug the collision detection routine; the rest is practically
> foolproof.
>
> How many line segments are we talking about, here? I suspect
> performance will not be an issue, compared to simplicity and
> reliability.
Agreed on simplicity and reliability. But, also, if his pipes are on a
gridwork (as with many plumbing games, or the pipes screen saver), he
can do much better. On a grid, each pipe pretty-much becomes its own
bounding box!
I'd concur with your "go with dumb algorithm" to start, but keep it in a
cleanly separate method, to allow optimisation later, if that proves
necessary.
(But optimise LAST!)
--
Please take off your pants or I won't read your e-mail.
I will not, no matter how "good" the deal, patronise any business which
sends
unsolicited commercial e-mail or that advertises in discussion newsgroups.


|