new ogre terrain use triangle list instead of triangle strip

[moagames]

Hi,

I just upgraded my project to use the new terrain system of Ogre instead of ETM.
It really works great and is exactly what I needed for my project, except for one thing: the terrain system uses triangle strip instead of triangle list.
These leads to major problems as you start using physics engines (Havok in this case), as they expect the triangles of the terrain to be aligned equally, but this isn't the fact, as in the triangle strips, the triangles are flipped every row, as you can see in this screenshot:

.

So here is my feature request:
can the terrain system be changed in order to use triangle list instead of triangle strip ?
For projects with a physics engine this would be a great benefit, and for those that doesn't use any physics, it shouldn't make any major difference.
Maybe this can also be added as an option during creation of the terrain with triangle strip as default, this way it wouldn't change anything for current projects.

thx in advance.

[boms]

I'm not sure how you create your terrains, but I have no trouble using Ogre and Havok heightfields from the same image.

Here's how I create my Havok heightfield from the exact same Ogre::Image I use for the Ogre terrain.

Code: Select all

//heightMap is an Ogre::Image
const int xRes = heightMap->getWidth();
const int yRes = heightMap->getHeight();
	
mHeightData = hkAllocate<hkReal>(xRes * zRes, HK_MEMORY_CLASS_USER);

for (int x = 0; x < xRes; x++)
{
	for (int z = 0; z < zRes; z++)
	{
		hkReal height = heightMap->getColourAt(x, z, 0).r;
		
		mHeightData[x * zRes + z] = (height * -1.0f);
	}
}

hkpSampledHeightFieldBaseCinfo cInfo;
cInfo.m_xRes = xRes;
cInfo.m_zRes = zRes;

SampledHeightFieldShape *heightFieldShape = new SampledHeightFieldShape(cInfo, mHeightData);
...

You can find the rest in one of the Havok demos (Demos\Physics\Api\Collide\Shapes\HeightField\SampledHeightField I think).

[jacmoe]

The trick is to use the source image, not the terrain data.
Using the latter is a bad idea, because of LOD and other terrain specific peculiarities.

[reptor]

Isn't there then a mismatch between physical and visual terrain... in some games this may actually be a problem. Like in a game in which you can use a sniper rifle to shoot at enemies a kilometre away... the enemy might be lying down on the ground. There can be unpleasant surprises if the visual and physical terrains do not match. Like, a shot that looks like it should visually hit the enemy but it doesn't, it will hit the 'invisible' physical ground instead. Or the other way around that it will go through the visual terrain and hit the enemy when it actually should not hit the enemy. The player may be the enemy too so the player can be unpleasantly surprised that he took a hit when he thought he was completely in cover.

So I think my point is that a possible mismatch of visual and physical terrain can't be overlooked in all game types. So we should have a good way to ensure this won't be a problem. I guess the OGRE terrain settings can be adjusted to counter this but there can be performance problems as the visual terrain may become too detailed.

[moagames]

first thanks to all for your answers.

Shouldn't the getHeightAtPoint function just return the same as a heightmap image would return at this point, without considering any lod ?
Furthermore, at the lowest lod level, so directly in front of the camera, the terrain shouldn't be using any lod data, but instead just outputting the data from the input, so I just can't see, why the problem should be lod related.
I still think, that the problem with the triangle strip is the key issue, as the quads of the terrain changes the triangle flip with every row, and this will lead to an inaccuracy with the physics terrain, that keeps the triangle flip at the entire terrain. This wouldn't make much difference with terrains with very high resolution, but as soon, as the resolution decreases to a distance of 1 or 2 meters between the grid points, the effect is very noticeable.
In my application I can see, that most of the time the physics terrain matches the visual terrain very fine, but there are some points where the physics terrain is lower or higher than the visual terrain (mainly at small hills) and this can be explained with the triangle flip. Just imagine, a plane made of 4 points and two triangles. If you now move only one of these points down on the Y axis it will make a big difference how the triangles of the planes are flipped.
So in my opinion, this is the real issue with the new terrain system. Changing this behavior should fix the alignment.
ETM also uses lod and all these things, the only difference is, that it uses triangle list and there the visual and the physics terrains matches perfectly (of course at the lowest lod level = near to the camera)

[CABAListic]

So, why don't you change the triangle orientation in your physics code?
Triangle strips can save quite a bit of memory. Don't underestimate that.

[moagames]

Havok wants all triangles to be either left or right flipped (this can be set up), but not mixed.
The memory gain of triangle strips for a terrain is so little, that it shouldn't make any noticeable performance difference.
See also sinbads post at this thread.

[jacmoe]

Sinbad wrote that in 2005, mind you.
The question is how the terrain component deals with it.
And if it could be made to deal with strips..

Why not perform the conversion in your physics code?
IMO, keep rendering data apart from physics data - as long as the representation is accurate.

I am aware that the terrain component has some issues regarding accuracy - you need to set the max pixel error level to match your scale.
And when you do that, you need to down-size the pages.

[CABAListic]

Havok wants all triangles to be either left or right flipped (this can be set up), but not mixed.
The memory gain of triangle strips for a terrain is so little, that it shouldn't make any noticeable performance difference.
See also sinbads post at this thread.

Keep in mind that Ogre doesn't solely target high-end hardware. Triangle strips can save a couple of megabytes on a 512x512 terrain, even more for bigger terrains. And sinbad made a conscious choice for triangle strips after that post you mentioned, so he'll have had his reasons. (Might be he posted them somewhere, would be useful for this discussion.)

Unfortunately, the effort to support both strips and lists is imho too high, the ordering is relevant for too many sections of code, it would be a maintenance disaster. So we will have to make a choice either way. I know I got some negative feedback for ETM using lists instead of strips, so suiting everyone will be difficult.

[moagames]

Why not perform the conversion in your physics code?

I already asked this in the havok forums and there the conclusion was, that there is no optimal way to support flipping triangles in a heightfield. Havok wants all triangles either left or right flipped.

IMO, keep rendering data apart from physics data - as long as the representation is accurate.

The representation is only accurate in maybe 60% of the cases, but as soon as there are any hills, the difference is very obvious.

I am aware that the terrain component has some issues regarding accuracy - you need to set the max pixel error level to match your scale.
And when you do that, you need to down-size the pages.

I also tried to set max pixel error to 0, but this just had no effect on the accuracy at all, as I understand, the max pixel error has only effect on the terrain parts, that are farther away.

I am not really sure, how other physics engines work, but it might be an issue with other terrain systems too.
At the current stage, I just can't really use the new Ogre terrain, because of this issue, as the inaccuracy is just too noticeable at some parts of the terrain (like I said, especially at hills). Therefore it becomes an option now to downgrade back to ET, what would be really bad, as I really like the new Terrain system

[jacmoe]

You are wrong:
http://www.ogre3d.org/forums/viewtopic.php?f=2&t=55113
setMaxPixelError is what you need. When you're close to the terrain.

[moagames]

OK, then I'll try Ogre::TerrainGlobalOptions::setMaxPixelError(1); as soon as I get home today, let's see, if this helps .

Thank you for your kind help

[moagames]

I investigated in getting the two aligned and found out some things:

1. setMaxPixelError just had absolutely no effect for me. I tried 8, 1, 0 and 0.0000001. In all cases the terrain just looked exactly the same

2. the morphing of the terrain is much too aggressive and I didn't find a way to disable it, so I just removed the code from the generated vertex shader. To try it out just set any point of the terrain to a very high value. You will see, that with the morphing left in the vertex shader, the spike that was just created is completely removed from the terrain during rendering. But as the value is still stored in the terrain data, the physics engine will keep using it => mismatch between Ogre and Havok

3. I made a little experiment to test the data stored in Ogre:
- change the height of one single point of your terrain using:

Code: Select all

m_Terrain->setHeightAtPoint(5, 5, 100);
m_Terrain->update();

- Now start your application and change to wireframe
- check which point in wireframe was changed to the height 100
My result was, that on the x axis it was like expected the sixth point, but on the z Axis, it was the fifth point!
This would explain, why it was so impossible to align Ogre and Havok using the getheightAtPoint function.
This sounds like a bug in the terrain system to me, so could please someone else check this ?

[jacmoe]

Check that you are actually using the new terrain, because you could be using a precompiled, binary dump - which would explain why you're not seeing any change.
What you're saying just sounds very, very wrong.

[moagames]

i am definitely using the new terrain . I am using Ogre from trunk (last update a few weeks ago)
As I said, if you just remove the morph part of the VS in the material generator, the changes are visible, but with them in the shader the change to that single point is just "morphed away".

Edit:
for the other problem with the wrong grid point changed, I'll first have to check my code again (as soon as I get home).
It might be, that I did something wrong, so this error is out until I check it again. But the morph problem still exists

[jacmoe]

I meant: check that you are not making the same mistake as I did a while ago and your program is not generating any new terrain because there is a binary terrain file present.
If you have this check in your code, the terrain won't change no matter what you do.
Remove the check, or delete the file, and your terrain will be regenerated.
I am not saying that you do, but it's worth checking.

[moagames]

You were right, there was an error in my code, both in the material generator I wrote and in my application during creation of the terrain.
Now the terrain is aligned pretty well with havok, the triangle strip problem is now pretty much negligible.

So now I am really happy with the new terrain, the only remaining issue I have is described in this thread: link