openmw.org

I'm pretty sure that's a problem with how bullet implements cylinders. I added cylinders to my personal 3d collision toy and it didn't have a real negative impact on performance. Either way cylinders are potentially problematic for vanilla level design too since they let you slip through some gaps that you can't in vanilla, since you're 30%ish skinnier when walking on 45 degree angles (relative to the euclidean axises).

Yeah, our own implementation only has to represent characters so it shouldn't cost significantly more than any other type of collider.

Are there any places where that difference is actually used in vanilla though? Or even in PT/TR? As far as I've seen the vast majority of tilesets are designed and used aligned to axes and I think them behaving differently when rotated 45 degrees would be more annoying for level designers moving forward than expecting diagonals to work differently, especially with TR's Dres tileset having a hexagonal motif.

On the subject of vanilla behavior actually, I see that actors have their armature/skin/skeleton loaded and kept up to date for physics purposes but is this actually used for anything? As far as I can tell both vanilla and OpenMW at current just use an actor's world collider for detecting melee strikes and projectiles as well. Showing the collision grid also only shows world colliders for actors.

For now I'm just going to ignore armatures for collision purposes as even if they were to be used, armor damage to limbs is randomly rolled anyway and the work done to maintain these armatures in bullet appears to be completely wasted in the current implementation. In theory these could later be used for ragdolling and more accurate hit-detection but neither of these appears to be worth the effort, at least for the current idea of the 1.0 release.

Will this not be the case eventually with Oblivion and onward? (ragdoll/havok)

It will be but that's something to be discussed when (or perhaps if) ever OpenOB gets off the ground. For now I'm considering what's best for running Morrowind and this appears to be a lot of complex code and extra clock cycles completely wasted for no good reason.

It's fine as long as you're not going to back yourself into a corner where adding support for what Oblivion needs is difficult.

OpenMW is focused on Morrowind now, but OpenMW will eventually support other netinverse/gamebryo games. That is the long term goal of the project, not an eventual fork.

It shouldn't be a problem to add this back in the future, keeping the system simple is one of my priorities. I just don't want it wasting time right now unless it's actually being used for something, as animation appears to be one of the biggest bottlenecks in the codebase already.

OK. Just to be clear, we don't want Morrowind's use-case to be the only motivating factor here. Keep in mind the possibility of extending your work (perhaps by those after you) to add that back for Oblivion and beyond. It would be a pity to throw the baby out with the bath-water when we eventually get there.