I'm new to both Bullet and Ogre 2.1, so I can't imagine how to add physic (I guess it's called Rigid body) to an Ogre's complex shape (I guess it's called Mesh).
I have read this question and I guess it likes:
step 1: Get the axis-aligned bounding box for this mesh.
step 2: Create Bullet's rigid body for this axis-aligned bounding box.
But if I do it like this, the physic matches with the box (which surrounds the complex shape), not the complex shape.
Also what if I want to add physic for the terrain (terrain has mountains, crack,...), how can I do that?
add physic for an Ogre's complex shape
-
- Gremlin
- Posts: 152
- Joined: Sat Aug 12, 2017 4:16 pm
- x 4
-
- Gremlin
- Posts: 152
- Joined: Sat Aug 12, 2017 4:16 pm
- x 4
Re: add physic for an Ogre's complex shape
mmm... I think Bullet's official examples should cover this, so I think it's time I dig the Bullet examples source code now
-
- Halfling
- Posts: 73
- Joined: Tue Jun 14, 2016 12:26 pm
- x 19
Re: add physic for an Ogre's complex shape
In any case, your physics (bullet) representation of an object will be separate from what is rendered by Ogre. And as they are separate, they don't have to be exactly the same (also don't forget that bullet has it's own limitation on collision precision). In general you want your bullet collision shapes as simple as possible for performance/simplicity reasons but still resembling the object you are modeling. For example, a capsule is often used as a collision shape for humanoids in general and player character in particular. Or you might add a convex hull for different parts of your humanoid and track them separately. Or something else. It all depends on what exactly you need/want, what kind of objects are interacting in your program etc.
Bullet supports tri-meshes as an option for a possible collision shape and that might look like a straightforward answer for your question. And sometimes they are the best or the only viable option (f.e. terrain). But other times you are better off with something more simple.
Bullet supports tri-meshes as an option for a possible collision shape and that might look like a straightforward answer for your question. And sometimes they are the best or the only viable option (f.e. terrain). But other times you are better off with something more simple.
-
- Gremlin
- Posts: 180
- Joined: Tue Nov 25, 2008 10:58 am
- Location: Kristiansand, Norway
- x 23
- Contact:
Re: add physic for an Ogre's complex shape
Also check out this thread:
"BtOgre21, forked for Ogre 2.1that uses Item. + debug drawer"
viewtopic.php?f=25&t=92567
"BtOgre21, forked for Ogre 2.1that uses Item. + debug drawer"
viewtopic.php?f=25&t=92567
-
- Gremlin
- Posts: 152
- Joined: Sat Aug 12, 2017 4:16 pm
- x 4
Re: add physic for an Ogre's complex shape
Thanks for your answers I find them very useful.
btOgre2.1 provide class StaticMeshToShapeConverter to create physic shape for Ogre's item. But I can't find a way to create physic shape for Ogre 2.1 terrain. I think there must be a way to get information from the Ogre terrain so that we can form the physic shape with bullet's btBvhTriangleMeshShape.
I took a look at this article, but this is the Ogre 1.x terrain, not Ogre 2.1's terrain.
btOgre2.1 provide class StaticMeshToShapeConverter to create physic shape for Ogre's item. But I can't find a way to create physic shape for Ogre 2.1 terrain. I think there must be a way to get information from the Ogre terrain so that we can form the physic shape with bullet's btBvhTriangleMeshShape.
I took a look at this article, but this is the Ogre 1.x terrain, not Ogre 2.1's terrain.
-
- Halfling
- Posts: 73
- Joined: Tue Jun 14, 2016 12:26 pm
- x 19
Re: add physic for an Ogre's complex shape
Technically Ogre's terrain is build over a heightmap. Bullet (IIRC) has a method of creating a shape from a heightmap (I have not tried it though). And it should not be hard to generate a tri-mesh from a heightmap by the code either.
Another question is how much of your terrain you want to be represented in bullet at runtime. If your scene is big you probably don't want it all processed at the same time, only the part(s) where something is happening.
Another question is how much of your terrain you want to be represented in bullet at runtime. If your scene is big you probably don't want it all processed at the same time, only the part(s) where something is happening.
-
- Gremlin
- Posts: 152
- Joined: Sat Aug 12, 2017 4:16 pm
- x 4
Re: add physic for an Ogre's complex shape
Wow, I didn't know that is possible with Bullet I must find out how to do that! I want the Bullet & Ogre match with each other.
Edit: I have tried this
Code: Select all
float terraSize = 10.0f;
float terraHeight = 10.0f;
mTerra->load("Heightmap.png", Ogre::Vector3(64.0f, 4096.0f * 0.5f, 64.0f), Ogre::Vector3(size, terraHeight, size));
btHeightfieldTerrainShape* pPhysTerrain = new btHeightfieldTerrainShape(mTerra->m_width, mTerra->m_depth, &mTerra->m_heightMap[0], terraHeight, 1, true, true); //m_width, m_depth, m_heightMap --> change from private to public
//Create the Body.
btRigidBody* pGroundRigid = new btRigidBody(0, nullptr, pPhysTerrain, btVector3(0, 0, 0));
m_dynamicsWorld->addRigidBody(pGroundRigid);
First time, when I set terraSize & terraSize = 14096.0f, my PC freeze, the speaker goes crazy. After force shut down my PC, I set terraSize & terraSize = 10.0f and I see that the memory usage quickly increase by GBs. This terrain stuff is crazy!!!
Last edited by 123iamking on Tue Nov 28, 2017 6:11 am, edited 4 times in total.
-
- Gremlin
- Posts: 152
- Joined: Sat Aug 12, 2017 4:16 pm
- x 4
Re: add physic for an Ogre's complex shape
But another thought, If Ogre already read heightmap and & load it into memory, don't you think it will be more efficient to read data from Ogre instead of load the heightmap again from disk?
-
- Halfling
- Posts: 73
- Joined: Tue Jun 14, 2016 12:26 pm
- x 19
Re: add physic for an Ogre's complex shape
I am far from being an expert, especially in Ogre's Terra, but I think it's all sits in videocard memory (probably as a texture). I don't think it's easy (or even viable idea at all) to make bullet work against a texture in vedeo memory directly. So it has to be separate. Especially if you consider multithreading (which you should).123iamking wrote: ↑Tue Nov 28, 2017 4:21 am But another thought, If Ogre already read heightmap and & load it into memory, don't you think it will be more efficient to read data from Ogre instead of load the heightmap again from disk?
If terrain size is an issue you should think about loading/unloading only part of it at the time. Both for visual representation and physics.