Heightfield Support

Eltharyon · Post by **Eltharyon** » Wed Jun 07, 2006 1:41 pm

well, I'd really like to know what became of that demo. I'm attempting something similar.

All I want to use is Bullet's collision detection.
My collision engine will be receiving height data which complements a fixed resoultion x,z grid. I need to be able to detect collisions between this terrain and my CollisionObjects.

As far as I understand I'll need to turn this height information into a triangle mesh, but at the same time I cannot afford to make a copy of any of the data; I'll have to take the x,y value from the array index(and possibly scale it) and the y value from the array itself.

I *think* to make this work I'll have to override the StridingMeshInterface's ProcessAllTriangles function, but thats probably not all of it.

Erwin Coumans · Post by **Erwin Coumans** » Thu Jun 08, 2006 2:49 pm

I split the posting into a separate Subject 'Heightfield', because it was different from the 'Terrain mesh and collision', which deals with triangle meshes. This one has to generate triangles on the fly.

Eltharyon wrote:well, I'd really like to know what became of that demo. I'm attempting something similar.

All I want to use is Bullet's collision detection.
My collision engine will be receiving height data which complements a fixed resoultion x,z grid. I need to be able to detect collisions between this terrain and my CollisionObjects.

As far as I understand I'll need to turn this height information into a triangle mesh, but at the same time I cannot afford to make a copy of any of the data; I'll have to take the x,y value from the array index(and possibly scale it) and the y value from the array itself.

I *think* to make this work I'll have to override the StridingMeshInterface's ProcessAllTriangles function, but thats probably
not all of it.

An implementation that interfaces the heightfield to the StridingMeshInterface should be able to do this. It is possible to create 'temporarily' triangles from a heightfield.

but thats probably not all of it.

Which problems do you forsee?

Thanks,
Erwin

Eltharyon · Post by **Eltharyon** » Fri Jun 09, 2006 2:17 pm

Thanks for the reply and thanks for giving this topic its own thread!

Which problems do you forsee?

Well, I've looked at the StridingMeshInterface some more, but still all I can see is a way to interface with memory containing complete vertex data / triangle data. The data I was originally planning to use did not contain anything but height values (so no x or z axis information!). I don't think there is an easy way to utilise that kind of data without any kind of copying.

I will now receive normally configured (vertices/indices) mesh data which should be no problem to use.

Eltharyon · Post by **Eltharyon** » Thu Jun 22, 2006 12:27 pm

Hi again.

I'm happy to report that my experience with Bullet has been quite positive and that I've been successfully using heightmap based terrain via a terrain callback for a while now.

Unfortunately some other issues regarding the terrain have turned up. This one probably deserves its own thread, but I didn't want to flood the forum and so I'm leaving that decision to the moderator.

We're considering using Bullet for a larger game project. We're quite happy with many of its features, but one major feature we require is missing in the current bullet release: Materials by Triangles.
Many game situations require the ability to have terrain featuring various degrees of friction/restitution (take a road through a landscape for example).

As far as I can tell Bullet currently calculates friction based on bodies' friction, but it is done via constraints which are applied to the respective contact points. My approach would be to store friction information for both involved surfaces in each contact point. I haven't checked how feasible it is to retrieve this information during collision, however.

I guess this post contains two questions.

a) Are you aware of this potential requirement for game environment and do you have plans for it / do methods already exist which I am not aware of.

b) Do you think the suggested contact point friction approach is feasible / What would your approach be?

Thanks,
and keep up the good work.

PS.: Another issue is the reliability of the CCD when combined with triangle meshes. I realize the CCD is in the very early stages of development so I'll bring this up again in the future.

Erwin Coumans · Post by **Erwin Coumans** » Thu Jun 22, 2006 2:08 pm

Eltharyon wrote:Hi again.

I'm happy to report that my experience with Bullet has been quite positive and that I've been successfully using heightmap based terrain via a terrain callback for a while now.

That is great. Do you have some example or contribution how to do this? Ideally you can even have some page in the wiki as a how-to?

Unfortunately some other issues regarding the terrain have turned up. This one probably deserves its own thread, but I didn't want to flood the forum and so I'm leaving that decision to the moderator.

We're considering using Bullet for a larger game project. We're quite happy with many of its features, but one major feature we require is missing in the current bullet release: Materials by Triangles.
Many game situations require the ability to have terrain featuring various degrees of friction/restitution (take a road through a landscape for example).

As far as I can tell Bullet currently calculates friction based on bodies' friction, but it is done via constraints which are applied to the respective contact points. My approach would be to store friction information for both involved surfaces in each contact point. I haven't checked how feasible it is to retrieve this information during collision, however.

I guess this post contains two questions.

a) Are you aware of this potential requirement for game environment and do you have plans for it / do methods already exist which I am not aware of.

b) Do you think the suggested contact point friction approach is feasible / What would your approach be?

There is already preparation for per-triangle friction. You can see the triangle index / part number is passed through the interfaces. Indeed, a per-contact point friction / restitution would be good. Best, with some optional user-callback, so he can find the friction value based on the CollisionShape / triangle/part index.

Will add it to the todo-list.

Thanks,
Erwin

Eltharyon · Post by **Eltharyon** » Thu Jun 22, 2006 3:12 pm

That is great. Do you have some example or contribution how to do this? Ideally you can even have some page in the wiki as a how-to?

I'll be happy to contribute. Once I've got some time I'll post a how-to. My method is far from perfect but it might prompt some other contributions.

I'm unsure where to post this guide though, as I we can't edit the main page of the wiki and there doesn't seem to be a "how-to"/"tutorial" section yet (and its not really a FAQ).

Cheers,

Robin Henkys, aka Eltharyon

PS.: We're quite happy to hear you're putting this on the todo list. As I hinted we're planning to replace our current collision/physics engine with an open source alternative and bullet looks, as has been said before, very promising. Any accomplishments we'll hopefully be able to share with the community in order to further improve bullet's usefulness for games.

Erwin Coumans · Post by **Erwin Coumans** » Thu Jun 22, 2006 3:39 pm

Please feel free to follow the Height Field link here:

http://www.continuousphysics.com/mediaw ... umentation

Unfortunately, spam and abuse cost a lot of time, so this forum has 'manual' registration for users for example (to fight spammers with url's). I protected the frontpage, because it's the main Bullet page, I don't want people to mess that up

Most other wiki pages can be editted (except for things like the Bullet Blender contest, otherwise people can make themselves winner

Can you let me know if that works?
Erwin

Eltharyon · Post by **Eltharyon** » Thu Jun 22, 2006 5:19 pm

Seemed to work, the article is available here:

http://www.continuousphysics.com/mediaw ... ight_Field

Haven't got the time to go into detail and its not that complicated a topic anyways (compared what usually happens in these forums), but it might be a practical snippet for other users who aren't necessarily physics engine specialists.

Cheers,

Robin

Dalfy · Post by **Dalfy** » Mon Jun 25, 2007 7:01 am

Hello,
I would like to know what is the status of heightmap support in the current version.

Eternl Knight · Post by **Eternl Knight** » Mon Jun 25, 2007 11:01 pm

As I never got around to doing this either - I too would appreciate some information on this... It doesn't need to be done or anything, but knowing it's status helps

Thanks!

--EK

Erwin Coumans · Post by **Erwin Coumans** » Wed Jun 27, 2007 4:31 am

Basic heightfield support has just been added into Bullet c++ repository, so it will be available in next release.

The VehicleDemo has been modified to show its usage.
Thanks,
Erwin

Eternl Knight · Post by **Eternl Knight** » Wed Jun 27, 2007 12:20 pm

That's great news. I'll check it out tonight for a quick review

Thanks again, Erwin.

--EK

binofet · Post by **binofet** » Wed Jun 27, 2007 11:14 pm

First:

Thank you very much Erwin! This is great!

Second:
For anyone confused about why they have a flat world when they try this!

Code: Select all

btScalar	btHeightfieldTerrainShape::getHeightFieldValue(int x,int y) const{
    btScalar val = 0.f;
    if (m_useFloatData){
        btScalar val = m_heightfieldDataFloat[(y*m_width)+x];
    } else{
        unsigned char heightFieldValue = m_heightfieldDataUnsignedChar[(y*m_width)+x];
        btScalar val = heightFieldValue* (m_maxHeight/btScalar(65535));
    }
    return val;
}

Made a local 'val' inside the conditionals and assigned the height to it instead of the val that gets returned. Easy fix, confused me for a bit though

Again, thanks for sharing this Erwin!

Erwin Coumans · Post by **Erwin Coumans** » Thu Jun 28, 2007 12:37 am

Thanks binofet, the bug has been fixed in the repository.

Erwin

Eternl Knight · Post by **Eternl Knight** » Fri Jun 29, 2007 1:43 am

Quick Question:

I haven't played too extensively with the height-field at the moment (currently working on code that will allow for "fractal terrains" calculated on the fly). So please don't hammer me if this is obvious in some of the code I haven't looked at...

Does the height-field support include "penetration" support? That is, given an object of sufficient speed, there is a high probability it can (between timesteps) trvel completely from on side of the terrain triangles to the other. does the current height-field code detect this and still classify it as penetration (hence being able to handle it in the solver)?

--EK