Bullet loading time

[Ovan]

Hello everyone, i follow the project from some years
today i see the src, and in bullet i see you use btTriangleMesh for trimesh but
you can make an interface with btIndexedMesh and use the pointor in Nif::NiTriShape in place of making a copy for bullet
so you can saved a loading time, and performance is same

[Chris]

today i see the src, and in bullet i see you use btTriangleMesh for trimesh but
you can make an interface with btIndexedMesh and use the pointor in Nif::NiTriShape in place of making a copy for bullet
so you can saved a loading time, and performance is same

The NiTriShape, along with the rest of the NIF structure, will get unloaded after the necessary resources (materials, meshes, etc) are created. We can't assume it'll stick around. We might be able to link the Bullet shape to use the Ogre mesh data, assuming it has a static copy of the vertex data, but I'm not sure it'd be worth the hassle since the shape is only loaded once (per scale..) and then shared by all the collision objects that use it.

[Ovan]

oh, ok

but if you use OgreMesh and if the resource is shared
it's possible to use btScaledBvhTriangleMeshShape for trimesh and for other btUniformScalingShape

but ok, if the shape are loaded only one per scale the loading time is not really slow,
on the other side this little time is seeing when a world chunk is loaded (on world transition)

sorry for disturbance and incrust

[scrawl]

There were some attempts to use btScaledBvhTriangleMeshShape by jhooks, it didn't really work.

[jhooks1]

Just to quote what was going on:

Scrawl, I am not sure we can use btScaledBvhTriangleMeshShape. I didn't test long enough to notice a problem until now. When viewing shapes in tcg, it looks identical to using the previous way. When we turn on collision (tcl) though there are bad problems - including player getting stuck, player running up rocks, and player going in the wrong direction. Going back to previous string ID solution, the problems disappear.

It would be cool if a more efficient solution could be implemented, or if someone could get btScaledBvhTriangleMeshShape to work.

[Ovan]

ok, i don't know how and where the resource are loaded, but bullet allow to share a btStridingMeshInterface between multiple shape and btIndexedMesh can be usefull, using Ogre meshbuffer in btIndexedMesh and share it between btBvhTriangleMeshShape, so btScaledBvhTriangleMeshShape is not needed, and no data is copied

I am Interesting to do it, but I have too little knowledge in the engine and ogre
(I'm irrlicht user)

[gus]

As far as I remember, when there are two identical objects, the same shape is used, and when objects are not identical, no collision information is shared (in the file format) . But that might be some post 1.0 stuff, I have not really thought about this. Actually, for post 1.0 we should really drop trimesh shapes and switch to convex shape which should be way faster (and trimesh are only statics, for oblivion-like collision it does not work).

[Chris]

Actually, for post 1.0 we should really drop trimesh shapes and switch to convex shape which should be way faster

That will only work if the collision shapes in the Nif are actually convex, and there's no way to guarantee that when the collision shape is one or more NiTriShapes. It's only a bounding box collision shape that we know will be convex, and we already do create a btBoxShape for that.

[gus]

Sure, I should rephrase: we should strongly encourage modders to have convex collision shape for their objects, and have it supported by openmw.