Heightfield Support
-
- Posts: 13
- Joined: Wed Jun 07, 2006 12:55 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.
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.
-
- Site Admin
- Posts: 4221
- Joined: Sun Jun 26, 2005 6:43 pm
- Location: California, USA
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.
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.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.
Which problems do you forsee?but thats probably not all of it.
Thanks,
Erwin
-
- Posts: 13
- Joined: Wed Jun 07, 2006 12:55 pm
Thanks for the reply and thanks for giving this topic its own thread!
I will now receive normally configured (vertices/indices) mesh data which should be no problem to use.
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.Which problems do you forsee?
I will now receive normally configured (vertices/indices) mesh data which should be no problem to use.
-
- Posts: 13
- Joined: Wed Jun 07, 2006 12:55 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.
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.
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?
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.
-
- Site Admin
- Posts: 4221
- Joined: Sun Jun 26, 2005 6:43 pm
- Location: California, USA
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?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.
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.
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?
Will add it to the todo-list.
Thanks,
Erwin
-
- Posts: 13
- Joined: Wed Jun 07, 2006 12:55 pm
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.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'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.
-
- Site Admin
- Posts: 4221
- Joined: Sun Jun 26, 2005 6:43 pm
- Location: California, USA
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
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
-
- Posts: 13
- Joined: Wed Jun 07, 2006 12:55 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
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
-
- Posts: 2
- Joined: Mon Jun 25, 2007 6:56 am
-
- Posts: 44
- Joined: Sun Jan 22, 2006 4:31 am
-
- Site Admin
- Posts: 4221
- Joined: Sun Jun 26, 2005 6:43 pm
- Location: California, USA
-
- Posts: 44
- Joined: Sun Jan 22, 2006 4:31 am
-
- Posts: 20
- Joined: Fri Jun 15, 2007 5:03 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!
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!
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;
}
Again, thanks for sharing this Erwin!
-
- Site Admin
- Posts: 4221
- Joined: Sun Jun 26, 2005 6:43 pm
- Location: California, USA
-
- Posts: 44
- Joined: Sun Jan 22, 2006 4:31 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
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