Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

DarkBASIC Professional Discussion / Extended Terrain: Finding the coordinates of the surface

Author
Message
Agent
21
Years of Service
User Offline
Joined: 7th Sep 2004
Location: Sydney, Australia
Posted: 1st Jul 2013 21:23
Hey guys,

Started working on my new project two days ago, and I'm using Extended Terrain for my landscape. I haven't used ET before, so I'm still figuring the ins and outs of the plugin. I've got the terrain loading and displaying, and I've written a few nice world effects like a day/night cycle and weather effects. Now it's time to place my characters in the scene, but I ran into a positioning problem:

I need a function that takes an X and Z coordinate as parameters, and returns the Y coordinate of the ground level at that point - sort of like GET MATRIX HEIGHT() - so that I can position my character models at the appropriate height. Is there a method for this built in to the library? I've only found very sparse documentation on the plugin. If there's nothing builtin, how can I find the coordinate I want?

JackDawson
14
Years of Service
User Offline
Joined: 12th Jul 2011
Location:
Posted: 1st Jul 2013 22:13 Edited at: 1st Jul 2013 22:15
Like this ?



I use this with a Matrix Terrain. Not sure on anything else.
Rudolpho
20
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 2nd Jul 2013 03:07
You can also use intersect object. It will work with any object (not terrains using their own system unless they're internally represented as an accesiible object though). For large terrains it might be slow to use this function as it doesn't divide the object into sections and cull these ase it goes but rather raycasts against the whole mesh. If you're using a collision system (for example Sparky's) there usually are more efficient raycasting functions to be found there.


Here's an annoyingly hard to read function for calculating the height at a certain position of a terrain mesh that is constructed from a grid mesh. This is C++ code but there should be no problem converting it for use with DBP (it is really just interpolation based on the surrounding vertices Y-positions):



"Why do programmers get Halloween and Christmas mixed up?"
Agent
21
Years of Service
User Offline
Joined: 7th Sep 2004
Location: Sydney, Australia
Posted: 3rd Jul 2013 06:48
Thanks for the responses, guys.

GET GROUND HEIGHT() would be exactly what I need, but I can't use it because I'm not using a matrix. The terrain in the Extended Terrain system composed of a few hundred objects knitted together to look like a large field of open ground. I thought about raycasting from my entities straight down to find the height of the ground below it, but I am hoping there's a better, faster way.

I will look into INTERSECT OBJECT but it's not exactly what I need. In order to find the height of the ground I'll have to move an object downwards until it does intersect the ground and then take the test object's height as my return value, but that'll be time consuming. I'm hoping for a mathematical calculation, rather than a mechanical process, that will return the value I need.

I'll investigate the use of raycasting for the time being, but in the meantime I am hoping someone can think of a better way of doing this.

Does anybody know of an equivalent of GET GROUND HEIGHT() that can be used with a set of objects representing the ground?

Pincho Paxton
23
Years of Service
User Offline
Joined: 8th Dec 2002
Location:
Posted: 3rd Jul 2013 14:40 Edited at: 3rd Jul 2013 14:41
Quote: "I will look into INTERSECT OBJECT but it's not exactly what I need. In order to find the height of the ground I'll have to move an object downwards until it does intersect the ground and then take the test object's height as my return value, but that'll be time consuming. I'm hoping for a mathematical calculation, rather than a mechanical process, that will return the value I need."


I'm pretty sure that Intersect object can get the distance to the intersect point, so it's not as bad as you think. It uses vectors, not the object themselves. So it is like a 3D line in space.

JackDawson
14
Years of Service
User Offline
Joined: 12th Jul 2011
Location:
Posted: 3rd Jul 2013 15:08 Edited at: 3rd Jul 2013 15:17
As Rudolpho originally was saying, Intersect Object is actually better if you do not want to convert your objects to a Matrix format.


To get the ground height use intersect object. You can see the example code here. Keep in mind, this came directly from the DBPro HELP area. And it does work. It gives the height at the specific spot on the sphere that the Point of the cone is pointing at. So if you point the cone toward the sphere, its actually giving you the height at that spot on the sphere. Use the LEFT and RIGHT arrow keys to rotate the cone point toward the Sphere. Use the UP and DOWN keys to collide with the Cone. Slowly move the LEFT and RIGHT keys to see the height at those spots on the sphere. It will display it on the top left of your screen. It will even tell you at what point you collided with the sphere. The higher the number the further away the point is from the cone. So from here you would need to calculate how to "FAKE" the ground height in reverse if your treating it as terrain.



Hope this helps.

Quote: "I'm pretty sure that Intersect object can get the distance to the intersect point, so it's not as bad as you think. It uses vectors, not the object themselves. So it is like a 3D line in space."


Exactly right. It's actually pretty simple.
Rudolpho
20
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 3rd Jul 2013 18:43
Quote: "It uses vectors, not the object themselves."

It must use the vertex data to determine where faces on the object lies
It can perhaps opt out at an early stage if the ray is found to not hit a bounding box around the mesh or similar.


"Why do programmers get Halloween and Christmas mixed up?"
Pincho Paxton
23
Years of Service
User Offline
Joined: 8th Dec 2002
Location:
Posted: 3rd Jul 2013 19:02
Quote: "It must use the vertex data to determine where faces on the object lies"


That's not what he said though...

Quote: " I'll have to move an object downwards until it does intersect the ground and then take the test object's height as my return value"


Rudolpho
20
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 4th Jul 2013 15:41 Edited at: 4th Jul 2013 15:42
Oh, well the "height" of the object at a certain point is just the difference between the starting point of the ray and the point where it hits:

Still, my point was that the intersect object call itself may be too slow for realtime use on a complex object if you're for example using it to snap hundreds of characters to the ground in each loop cycle.


"Why do programmers get Halloween and Christmas mixed up?"
Mobiius
Valued Member
23
Years of Service
User Offline
Joined: 27th Feb 2003
Location: The Cold North
Posted: 4th Jul 2013 17:17
I'm going to have to ask, what's extended terrain? I know of enhanced terrain, and blitz terrain.

This is my current project, check it out! [href]forum.thegamecreators.com/?m=forum_view&t=204576&b=8[/href]
This is my website, check it out! [href]http:\\www.TeamDefiant.co.uk[/href]
JackDawson
14
Years of Service
User Offline
Joined: 12th Jul 2011
Location:
Posted: 4th Jul 2013 17:19 Edited at: 4th Jul 2013 17:24
Quote: "I'm going to have to ask, what's extended terrain? I know of enhanced terrain, and blitz terrain."


Extended Terrain XYZ are functions built into DBPro now days. It used to be a plugin if I remember right. But now its part of the DBPro Help command structure. So any extended terrain functions you might remember back in the day, no longer need a plugin.

At least, that's how I remember it. Could be wrong.

EDIT UPDATE :
Here is a link of the original back in 2007.
http://forum.thegamecreators.com/?m=forum_view&t=113993


Here is an link from last year.
http://forum.thegamecreators.com/?m=forum_view&t=198744&b=5
Mobiius
Valued Member
23
Years of Service
User Offline
Joined: 27th Feb 2003
Location: The Cold North
Posted: 4th Jul 2013 17:24
Enhanced terrain used to be a third party plugin until it was included as standard. That link is another third party plugin. Looks quite good too, I've just never heard of it until now.

This is my current project, check it out! [href]forum.thegamecreators.com/?m=forum_view&t=204576&b=8[/href]
This is my website, check it out! [href]http:\\www.TeamDefiant.co.uk[/href]
JackDawson
14
Years of Service
User Offline
Joined: 12th Jul 2011
Location:
Posted: 4th Jul 2013 17:26
Quote: "Enhanced terrain used to be a third party plugin until it was included as standard. That link is another third party plugin. Looks quite good too, I've just never heard of it until now."


Yea I might have that backwards.
Latch
19
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 4th Jul 2013 20:49 Edited at: 4th Jul 2013 21:27
@Agent

Hello,

The math to find the height isn't too hard. What I'll explain and the terms I'll use you probably already know most of it. The concept is this:

The distance to a plane can be found by using the dot product. The bumps and slopes of a terrain are all planes facing different directions. To determine which direction a plane is facing, or rather, the tilt of the plane, you need the face normal of that plane.

The normal is a vector that points perpendicular to the plane. We will call the plane a face from now on - meaning a face is one of the triangles that makes up your terrain. The face has 3 vertices. If we know the value of one of these vertices, and we know the face normal, we have enough to know where the face is in 3d space. If we have some other point in 3d space, we can find the distance between this point and the face. This distance can be our terrain height for that face.

Assuming that the terrain is X wide and Z long with height Y, we assume our height check point is from some X,Z position where Y=0. So basically, we are saying that a height of 0 is the lowest point and the distance from (X,0,Z) up to a face on the terrain is the height on the terrain at that point. Using the dot product, we can find this distance.

The first thing is to find out which face your X,Z position is under or over. You can do that by knowing the dimensions of your terrain and it's position relative to the lower left corner of the terrain being at (0,Y,0). Let's say your terrain is 10x10 cells, and it is 1000 units in both the x and z directions. Cell 0 is in the lower left corner and cell 99 is in the upper right corner.

If your object's X,Z position on the terrain is 78,34 , which cell is it in?



You'd have to add bounds checking to make sure you are within the terrain.

Anyway, we know in this scenario the cell at position X,Z=78,34 is cell 0. We will assume 2 faces per cell. We will also assume that the vertices for each cell/face have been previously stored or are accessible. To find which face (triangle) in the cell we are under or over, we want the slope between the lower left X,Z vert of the cell and our X,Z point. For Cell 0, the lower left X and Z is 0,0.



If this slope is greater than (cellsizez/cellsizex), then we are under triangle 1 in the current cell. If the slope is less than or equal, we are under triangle 2 of the current cell. In our case, our slope is less so we are in triangle 2. This assumes the rotation order of the vertices is the same as for a DB matrix. The cells look like this


Once you know the triangle, assuming you have also stored the face normal for each triangle (face), you can use the dot product and all of the information we have gathered to determine the height at any given X,Z position.




It's pretty fast, especially if you have your normal and points stored ahead of time for look up. If you don't have the face normal, you can calculate those using the cross product and any two edges of the face. Just make sure your vectors (edges) are going the correct direction or your normal will be in the opposite direction.

This dot product method only checks the cell you are over so it doesn't have to query the entire mesh.

Enjoy your day.
Agent
21
Years of Service
User Offline
Joined: 7th Sep 2004
Location: Sydney, Australia
Posted: 5th Jul 2013 09:53
Hi, Latch.

So far your response seems to be most like what I need. I understand the steps you've used to calculate the terrain height at any given X, Z plane position. However, I'm not certain how to implement the solution within the context of Extended Terrain.

I've been using the code in this link:

http://forum.thegamecreators.com/?m=forum_view&t=198744&b=5

There's a terrain editor in the download package, which I've been using to create my landscape. I'm then using the #include code as demonstrated in that download package to deploy the map into my scene.

Now, I don't fully understand the techniques used in the package. How do I access the vertex and normal information in the ET format?

chafari
Valued Member
20
Years of Service
User Offline
Joined: 2nd May 2006
Location: Canary Islands
Posted: 5th Jul 2013 16:48 Edited at: 5th Jul 2013 16:50
Hi there.

Terrain editors use a grayscale image to built up the terrain, so why do not use the same principle. We could make an array and check for pixel color to get the ground height. Something like:



The formula could be a little bit bumpy and we need to smooth the y# according our speed.....could be like so:

Quote: "player speed =0.02
if yy#>y# then dec yy#,0.025
if yy#<y# then inc yy#,0.025

position camera xx#,yy#+2.2,zz#"


I'm not a grumpy grandpa
Pincho Paxton
23
Years of Service
User Offline
Joined: 8th Dec 2002
Location:
Posted: 5th Jul 2013 18:45
Quote: "Terrain editors use a grayscale image to built up the terrain, so why do not use the same principle."


That's thinking out of the box... genius.

Latch
19
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 7th Jul 2013 11:13 Edited at: 7th Jul 2013 11:16
Quote: "So far your response seems to be most like what I need. I understand the steps you\'ve used to calculate the terrain height at any given X, Z plane position. However, I\'m not certain how to implement the solution within the context of Extended Terrain.
"


From what I gather from taking a quick peek at the source code, there is a global array created called map(x,y) of user defined type map when you load an ETM map in.

It seems that the X and Y indexing of the array are the number of X verts and the number of Z verts. So say you had a 10x10 celled terrain, X would be 0 through 9 and Y would be 0 through 9.

The array itself has 6 elements to the UDT. The first three are the actual vertex values and the next three seem to be the vertex normal.

So, position 0,0 vertices would be indexed as such:

map(0,0).xpos = some x value
map(0,0).ypos = some y value
map(0,0).ypos = some z value

I haven\'t run or played with extended terrain, so I don\'t know if this is how it\'s truly set up - but it seems that way from looking at the code.

The data seems to be stored sequentially, which is good. That makes it easier to deal with - i.e. all of the X\'s are iterated over each Y. It also seems that it\'s stored in a width height fashion which also makes it easier to deal with. Width height here is really width depth (X,Z). We should be dealing with cells and triangles - but again, you should verify with the author to be sure of the format.

Anyway, if it\'s sequential then you\'ll have to figure out an algorithm to determine which vertices go to which triangle. In a 10 x 10 grid, for instance, cell 0 would be made up of:



Once you figure that out, you\'ll need to find the face normal of each triangle in a cell by taking two edges (vectors) of each triangle and using the cross product. You\'ll need to normalize the normal. Also make sure the Y values of the normal are positive assuming positive Y is up. Store all of this information in an array for quick lookup later for when you are calculating the height.

Enjoy your day.

Login to post a reply

Server time is: 2026-07-06 20:31:46
Your offset time is: 2026-07-06 20:31:46