View Full Version : 3D collision in OpenGL

sebastian

04-13-2000, 04:11 AM

has someone got any idea/code for this?

creating a little world or terrain,moving through it (with a car,person,ship or some other stuff)...no problem...but how should i detect wether my object hits the ground or not ( the height level of the ground varies on some places,like hills and valleys)

Just compare the position of the object with the height of the landscape (I suppose you have the heightmap somewhere in the memory).

If you object is at (x,y,z) (y-axis upwards in landscape), you compare y with the heightvalue at (x,z)

Bob

Humus

04-13-2000, 12:02 PM

Yeah ... and that might mean that you'll have to calculate the plane equation of your polys that makes the terrains. That's easy done with vector cross product. Then, when you have the eq like A*x + B*y + C*z + D = 0 you just need to check wheter y > -(D + A*x + C*z) / B.

Hmm, can't see why you should use the plane equation to calculate wether or not you are above the terrain. All you have to do is obtain the height value of the terrain and the heightposition of the object and compare these two. Just two loads and one compare, nothing more.

Humus

04-14-2000, 04:38 AM

The terrain is not necassary flat, it can be built of sloping triangles (like sebastian said: "the height level of the ground varies on some places,like hills and valleys") and in that case you need the plane eq to obtain the y coord for the ground at the viewers (x,z).

Let me explain what I mean here. You most certainly have a heightmap of the landscape. If you are at position p=(x,y,z), just look in the heightmap at element heightmap[x][y]. If heigtmap says the height at this position is 50, and you are at height 40, you are placed below the ground.

sebastian

04-14-2000, 06:01 AM

Thanks guys for getting a headache about my problem...

you are right,comparing the value of the heightmap to the y-coord of my object is definetly no problem,i have already implemented it 2 hours ago.

but i want to have this stuff to be more realistic,so i think i'll have to turn on my brain in the next days.

there's another question i have:

do you want/have you got time to test my little game?i'd really appreciate it :-) !!!

i've never seen it run on another 'puter,so i would be glad to see some differences.

i'm using VC++ 6,the game is written in "old windows"..

NOTE: the game is in a really early stage,so

don't run away if you see it!

when moving around in the scene,you should notice the changes of the object's height(very very basic)

if you wanna help me,just post here.

i think i will put some download on my site on monday or tuesday..

thanx in advance,have a nice weekend...

[This message has been edited by sebastian (edited 04-14-2000).]

Let's sum up...

Bob was right and Humus was too...

Sebastian has done what Bob said and for more realism, he should do what Humus said.

By the way, Sebastian, if you post a link here, loads of people will try your soft !

Eric

MikeC

04-14-2000, 06:11 AM

Bob, I think the misunderstanding arises from different assumptions. You're assuming a very high resolution heightfield (or very low resolution collision detection).

Suppose you're using 10-metre sampling, so each "pixel" of your heightmap represents a 10x10 metre area of terrain. For a polygonal terrain rendering scheme, these sample points are the vertices of triangles.

The point is that the heightfield values only represent 'true' height at the exact sampling points, e.g. at {0,0}, {10,20}, {430,60} etc. At intermediate points (e.g. {5.1, 3.7}) you have to interpolate the true height from the three vertices of the triangle you're over, which is where the plane equations come in.

Humus

04-14-2000, 07:34 AM

Yes, Eric & MikeC are right ... but i did never mean Bob was wrong. Which method is best varies with the need. A heightmap can increase the performance a lot, but could need a lot of memory if the terrain is built of many polys or is heavily sloping at times. The method i proposed will always give an exact y value, but it may need some extra calculations.

MikeC

04-14-2000, 08:09 AM

There are any number of ways to speed things up here without sacrificing precision.

F'rinstance, you could generate a second bitmap with the same dimensions as the heightfield, which stores the maximum height difference between the sample and any of its neighbouring samples. This second map stores what we'll call "maximum variance", or V.

E.g. if a bit of the heightfield looks like this:

3 2 7

6 4 4

4 3 3

then V for the centre sample is 3, the difference between it and the neighbouring 7.

Okay, now you've got this set up and you want to check whether an object at height Y has collided with the landscape. Just find the nearest height sample H, and the corresponding max variance V. Now:

If Y > ( H + V ), you're clear.

If Y < ( H - V ), you've crashed.

Otherwise, check using the plane equation.

So you still have the precision of the equation approach, but you can almost always skip the actual calculation.

Ok, now it's my time to say a few words.

Humus: Sure, you are correct about using the plane equation, I just thought it was abit unessecary when (if) you had a heightmap.

MikeC: Yes, I was thinking about writing about interpolation when you have nonintegers as coordinates, but I changed my just before I sent the post (dunno why). I have interpolation in my landscape engine (it just look too ugly otherwise).

I realized that the plane equation can be used for heightcolision. I will have a look at it and see if it's faster than my interpolation. I have an array for normals in my landscape structure, so I can use it for plane normals.

Sure I have learnt something in this thread, thank you all...

Bob

Humus

04-15-2000, 01:31 PM

Just a comment to my last reply:

I did write in a way that may have sounded as using the plane of the triagle was an slow method. Well, it isn't especially inefficient since you only need to do it for the triangle you're above ...

Powered by vBulletin® Version 4.2.2 Copyright © 2015 vBulletin Solutions, Inc. All rights reserved.