Windows Glow Mod: Collision Problem and disabled objects

[Pherim]

I have tested OpenMW with my MGSO Morrowind installation, which I use mainly for testing purposes, since I am still actively playing my self-modded German Installation of Morrowind. So there are a lot of replacers included, which seem to work fine for the most part, but I have left most esps unchecked. However, by chance I had activated Windows Glow and also by chance I happened to discover that it does not seem to work correctly and even causes collision issues in the Gostgate interiors.

I believe I have identified two different issues which appear to be caused by OpenMW.

First, disabling the dome objects does not happen as it is supposed to, but both the original dome and the glowing one that should only be visible during the day while the other is disabled, are displayed at the same time - during the day that is. At night the glowing one is invisible, but apparently the original dome that should be disabled during the day just remains enabled - and I could also not disable it with the console. That made me realize that disabling objects behaves strange in general - some objects disappear entirely, others just lose their collision, but remain visible. So far I have not been able to determine why this happens.

The collision problems I encountered are an entirely different issue, as far as I can tell. When I tried to enter the lower level of one of the domes I discovered that I couldn't, as if an invisible object was blocking me. I didn't understand at first why this would happen, as it didn't happen in original Morrowind (the very same installation that I'm running OpenMW with). When I enterend tcg to display the collision geometry (by the way, this does not seem to work in original Morrowind to me although it is described as a console command on the UESP) I saw horizontal lines crossing the entrance, as if there was a collision mesh. It took me a while to discover the cause: The windows glow mesh of the dome has a collision mesh with unapplied translation values (The NiTrishape inside the RootCollisionNode, not the RootCollisionNode itself, and somehow, the Game does not handle that correctly and places the collision mesh where it would be if all translation values were 0. After I applied them to the NiTrishape, collision worked fine again ingame.
The stange thing about this is that the RootCollisionNode is exactly the same as in the original mesh, including the translation values. However, the game handles the collision correctly on the original mesh, as the way is not blocked at night when the Windows glow mesh is disabled. I have no idea what could be causing this.

And there is another thing I discovered: As you probably know, if there is no RootCollisionNode present in a mesh, the actual geometry is taken for collision, which is no problem for the low-poly meshes in Morrowind that are like this, but there are a number of mesh replacers out there (and also in MGSO) which subdivide the original meshes to make them smoother, but as a result they have much, much more polygons than the originals. In most cases I know the authors did not add RootCollisionNodes to meshes which don't have them but take into account that the now very complex geometry of the entire mesh is used for that (maybe they are even unaware of that). An example of that are the urns included in MGSO. Now I discovered that while I have mostly 25-50 FPS in interiors in OpenMW with MGSO installed, the framerate drops to 1-3 when I run against these urns, while in original Morrowind there is no change in FPS at all. It would appear that collision detection is still very performance-heavy in OpenMW, but you are probably aware of that.
By the way, it would be quite easy for modders to avoid this by simply keeping the originals as RootCollisionNodes for the smoothed meshes - When I did that with the urns the performance drop in OpenMW was gone entirely.

One last thing: MGSO uses the detailed glass cuirass from Baldurians Transparent Glass Amor (Baldurians_Transparent_GlassArmors_HD.zip under Additional Files) which is based on Detailed Armor (another example of excessive subdividing, but that's a completely different topic), and in OpenMW it appears over the NPC's head, rotated by 90 degrees. Comparing it to the vanilla meshes I saw that the detailed mesh (that's apparently also true for the rest of the cuirasses from the detailed armor mod) was placed at the axis origin in NifSkope, but all vanilla ones are above it. In the vanilla meshes, the root NiNode (the one that contains everything else) has translation and rotation values in it, and when they are set to 0 the mesh is in the same place as the detailed ones. In the original game that does not matter, but in OpenMW it leads to the cuirass being misplaced above the character's head.

I don't know if you are already aware of these issues. It would seem that for some reason they only appear with modded content, as the vanilla game seems to work mostly alright with OpenMW already. As it would be very difficult to track down all mods which would cause things like these, I hope you will find a way to fix this in OpenMW so that the Mods can be used the same as in the original game.

[dEnigma]

The collision issue with window glow is on the bugtracker (more or less): https://bugs.openmw.org/issues/2086. But you definitely provided a lot more insight into the problem, I'm sure the devs will appreciate it. Great to see modders actually trying out OpenMW (love your mods btw )

[Pherim]

Yeah, that's definitely related, seems that so far nobody is aware that this problem is connected to the RootCollisionNode being misplaced. By the way, there's yet another thing I noticed that is related to collision: As it is now, it is possible to collide with both sides of a polygon, whereas in the original engine only the front side is used for collision detection. Vurt's Ashtrees (the branchy version), which are also included in MGSO are a good example of this: Their collision meshes are basically inside out, so that the front sides of their polygons are facing inwards, which results in the player being able to go inside them and get trapped within the collision meshes, as now he has front faces all around.

However, in OpenMW this cannot happen, as both sides are used for collision detection, so in this case it actually helps.

The truth is, it is probably extremely unlikely that this could cause problems as I can't think of any situation or mesh where one would want to have a mesh or a part of it so that you can walk through it from one direction, but not from the other. But it's like that in the original engine and I can't think of a reason why it should be changed.

[Nivim]

The truth is, it is probably extremely unlikely that this could cause problems as I can't think of any situation or mesh where one would want to have a mesh or a part of it so that you can walk through it from one direction, but not from the other. But it's like that in the original engine and I can't think of a reason why it should be changed.

Actually, there was one mod that included a sorceresses castle with a theme of various magic traps springing on you, and that mod would be broken by this because it made heavy use of one-way-walls in mazes and such. Indeed; when I was scribbling up mods of mine own I really liked the unreal and eerie quality of something that only exists in one direction.

[dEnigma]

Pherim: After talking with scrawl, I took the liberty of posting (or pasting) your observations to the bug tracker

https://bugs.openmw.org/issues/2122
https://bugs.openmw.org/issues/2123
https://bugs.openmw.org/issues/2124

If you have anything else to add you could do it right there.

[Pherim]

Thanks!