irrBullet and TerrainSceneNode

[serengeor]

It's true that using pure Bullet for simple games is easy, but the reason I created irrBullet is because I need very advanced physics in my game, and the only way to do that in a logical manner is with a wrapper.

Very advanced physics can be achieved with bullet it self, can't they?
Besides if you need advanced physics you should write some sort of framework that would support them, for me it's my entity system. Of course you can do that in irrBullet but it adds one more layer, to my entities. Thats not a big problem, but in some situations it can become really unnecessary.

I think it depends on what you need and how you think you need it implemented.

[ChaiRuiPeng]

You just don't feel right

I do feel right.
Doing stuff with bullet is really easy, and doing it by digging trough additional layer is a bit weird. Unless doing some sandbox apps, then the wrapper makes it a bit easier, because it cleans up everything when you remove objects.

It's true that using pure Bullet for simple games is easy, but the reason I created irrBullet is because I need very advanced physics in my game, and the only way to do that in a logical manner is with a wrapper.

if you need advanced physics then its even more reason to use pure bullet AND THEN write your own custom wrapper classes/methods. since then they will be tailored to suit your needs.

[cobra]

if you need advanced physics then its even more reason to use pure bullet AND THEN write your own custom wrapper classes/methods. since then they will be tailored to suit your needs.

irrBullet is tailored to suit my needs. I didn't make it for kicks and giggles.

I designed it to be one of the main parts of my game, and it works very well in doing so. They are my own custom wrapper classes/methods.

Very advanced physics can be achieved with bullet it self, can't they?
Besides if you need advanced physics you should write some sort of framework that would support them, for me it's my entity system. Of course you can do that in irrBullet but it adds one more layer, to my entities. Thats not a big problem, but in some situations it can become really unnecessary.

I think it depends on what you need and how you think you need it implemented.

That's the thing: there is no second layer for that in my game with irrBullet. Physics and movement is entirely handled with irrBullet, which was created for my game. The classes simply contain a pointer to its IRigidBody or ISoftBody and have the methods unique to them, such as for scripting.

I'd have to explain the way I designed my game and irrBullet for you to understand it properly.

Anyway, I'm not trying to advocate use of a generic wrapper or use of Bullet itself; I'm just stating the reasons why I chose to make a wrapper for my game and release it to the community.

There are also some other reasons: free debugging and contributing to the community.

People get a free wrapper to use in their games, and in return I get free testers. I can't test every part of my library all the time. Moreover, it's better to share my code than to keep it closed up and take it to my grave. IrrBullet can be used by hundreds or thousands of people in their own games and game engines, whereas if I made it 100% specific to my game they could not; that's why I chose to make it specific to my game, yet still generic enough that others could easily use it.

Look at ENet for example. It was made (and further wrapped) for the creator's game (which is/was very popular), yet still made generic enough to work for others (and very well, I might add) freely as well as what it was designed for. It's also easier to manage as a separate project, as I've found with irrBullet.

[ChaiRuiPeng]

irrBullet is tailored to suit my needs. I didn't make it for kicks and giggles.

>.< sorry , i didnt see who i was replying to... its late...

[ChrisDicko]

Hi Cobra

Apologies, I didn't mean to start an argument about wrappers. My requirements are for a teaching environment where the students will/may be using physics in their final projects. These students have generally less than 3 to 400 hours of experience in C++ so a wrapper is attempting to ease their pain.

My only issue with irrBullet was the creation of a collision IMesh reference from a TerrainSceneNode. The student work flow is to build their environment in IrrEdit/CopperCube and then extract the terrain and other assets from the loaded irr file. Unfortunately IrrEdit doesn't export terrain in another format and probably for the same reason as the problem I have.

I tried to use the createTerrainMesh function but couldn't work out the undocumented parameters after much experimenting. I'm not alone with that there is at least one unanswered post about createTerrainMesh.

We will be using irrBullet in class and it will also be serving as a good example of what a wrapper should do. Thanks for making it available!

[cobra]

Hi ChrisDicko.

No worries. I'm glad irrBullet is useful for you guys.

- Josiah

[tjohns20]

This is the quick and extremely dirty solution I found for this:

Code: Select all

 
        scene::CDynamicMeshBuffer meshBuffer(video::EVT_2TCOORDS, video::EIT_16BIT);
        terrain->getMeshBufferForLOD(meshBuffer, 0);
        scene::SMesh mesh;
        mesh.addMeshBuffer(&meshBuffer);
        ICollisionShape* shape = new IBvhTriangleMeshShape(terrain, &mesh, 0);
        mPhysicsWorld->addRigidBody(shape);
 

I *just* got it to work, have't optimised and the framerate is chugging so this is obviously not an ideal solution

[edigames]

The above methods of extracting a mesh from an ITerrainSceneNode work. However I would use a LOD more like 3 rather than 0 as the speed can be an issue.

It is most important to know that irrBullet's trianglemesh implementation will not support 32bit indicies.

This had me going for a few days and didn't notice it mentioned anywhere.

This means your terrain verticies should not be greater than roughly 65,000 verticies; even if you're using a low LOD (as it still references indexes in the high vertex numbers).

If you do end up using vertex indexes over ~65,000 failure will be silent and result in a corrupted collision mesh; that is usually identifiable in the collision bounding box (if you have debug draw on) not fitting properly to the drawn mesh.

irrBullet's triangle mesh conversion function should at least check max verticies of the incoming mesh for 16bit compliance.

but fixing this with a modification should be simple, as using u32 temp variables in the triangle mesh conversion code.

I hope this helps some people, I sure could have used it

-Raymond