Star-Demon wrote:
I'm looking at the roadmap, and in unplaced tasks we have an item for bullet and the item for terrain, in addition to our NIF animation.
I was thinking: What are we doing about collision?
From the looks of things - it seems that all the collision in Morrowind is done by cubes. It's horribly simple, but probably very effective.
Now, if we were to add in Bullet Physics, these bulky and often cumbersome cubes will always be colliding, making for a really strange and chaotic experience.
There's also the danger of objects with Data blocks for collision dropping through the world like they are want to do in many interiors and exteriors in Fallout and Oblivion. If possible, we should cook up a way to fix that.
One question is: What do we do about the collision meshes? Are they in the meshes? Are the collision bounds calculated in game based on the end of normals or something like that?
It would be a real problem if we had to go back into every mesh and place a collision data block on it...Although this WOULD be a good opportunity to improve meshes and textures...I mean..might as well at that point.
Then there's another issue with bullet, if we have the option to turn it off but code it in anyways, how will that affect collision as the original did?
What can be said for Morrowind's collision in all this? I firmly remember having a hard time getting around inside any Telvanni interior...
Then there's the issues of collision with animated meshes.
What should we be gunning for when it comes to setting up the project to let bullet do its job but then allow the game to switch to a more advanced mode of physics and collision handling?
nicolay wrote:
We had the problem of collision more or less handled in the D code version of OpenMW, and I don't think porting them over would be much of a problem.
NIFs have their own collision mesh, which is a simplified (and non-textured, obviously) version of the mesh itself. This is what the original Morrowind uses, and this is what we should use as well. We had code for stripping out those part of the NIF upon loading and streaming it into a Bullet collision mesh. All we have to do is transfer that over to the new architecture (barring any radical API changes in Bullet in the meanwhile, but we can figure those out.)
There were a couple of problems though. Bullet didn't (last time I looked) support scaling of mesh instances. That is, if I load a NIF mesh of a staircase for example, but insert into the scene with a scale factor of 0.8, then there's no way to make that work in Bullet without recreating the scaled staircase as an entirely new mesh. This which wastes memory and is more complicated to implement. Bullet had (again, last time I looked) a class hierarchy that makes it APPEAR as though it's easy to insert new mesh types easily to fix these sort of things, but when you look closer you find that all the existing mesh types are hard-coded in the core itself.
Also, as you point out, animated meshes are not handled at all yet. But I believe all these things can be worked out, or at least worked around.
Star-Demon wrote:
nicolay wrote:NIFs have their own collision mesh, which is a simplified (and non-textured, obviously) version of the mesh itself. This is what the original Morrowind uses, and this is what we should use as well. We had code for stripping out those part of the NIF upon loading and streaming it into a Bullet collision mesh. All we have to do is transfer that over to the new architecture (barring any radical API changes in Bullet in the meanwhile, but we can figure those out.)
Okay, so it *is* inside the actual NIF. That's good. Good to know that the actual collision meshes aren't just big cubes. Man, that would be so cheap.
There were a couple of problems though. Bullet didn't (last time I looked) support scaling of mesh instances. That is, if I load a NIF mesh of a staircase for example, but insert into the scene with a scale factor of 0.8, then there's no way to make that work in Bullet without recreating the scaled staircase as an entirely new mesh. This which wastes memory and is more complicated to implement. Bullet had (again, last time I looked) a class hierarchy that makes it APPEAR as though it's easy to insert new mesh types easily to fix these sort of things, but when you look closer you find that all the existing mesh types are hard-coded in the core itself.
That's really strange. I mean, it would make sense that the mesh would also include the collision data, So if the mesh object was placed inside, then scaled (A lot o objects get scaled...) you would assume that the collision mesh that surrounds the regular mesh would scale with it
Why do they have to be taken separately? Yhe nif is a single thing - collision and all - isn't the ogre mesh the same? (trying to remember Blender3D to OGRE tutorials...) Wouldn't it make more sense to treat it as a single big object and let it do more work for us all at once, as long as we classify it into different roles?
Also, as you point out, animated meshes are not handled at all yet. But I believe all these things can be worked out, or at least worked around.
I think once we figure out the best way to handle the NIFs, get them in and get them behaving properly with OGRE and the world, this issue might solve itself.
