Do not create a redundant parent node for LOD and Switch nodes

[akortunov]

Should fix bug #4837, which affects a recent (6.0) version of Morrowind Optimization patch.

Currently when we handle a NiLODNode, we create an osg::Node and attach an osg::LOD as its child node. If the NILODNode is a root node in the mesh, we consider the osg::LOD as a root node, which is not true. For some reason in can lead to memory corruption (reference to the root node becomes invalid) and crash. The same thing for NiSwitchNode since I took the NiLODNode handling as a basis.

Possible solution: do not add a redundant osg::Node for such nodes, so reference to the root node should stay valid.

We need a someone to check if these objects do not cause a crash with MOP, especially on Windows:

1. active_bubbles00
2. furn_mist512
3. furn_mist256

These models should have particles, a first one should disappear when distance to player is > 1000, mist meshes should replace particles to billboards on distances > 2000 and disappear on distances > 5000.

Also you can test meshes from Glow in the Dahrk (since I touched NiSwitchNode handling). They still should be fine.

[Capostrophic]

Using Linux, so this is not really helpful: GitD meshes still work fine and LOD levels work fine too; no warnings logged.

[AnyOldName3]

I see DYNAMIC in this PR. That's an instant veto from me.

[AnyOldName3]

Upon grepping, I see other dynamics in OpenMW. I need to re-read some stuff, because I'm sure Scrawl said Dynamic is banned, but if they've snuck in, that could explain why MP3Butcher said there was no performance decrease when he tried adding one a while ago.

[AnyOldName3]

The wiki says this: https://wiki.openmw.org/index.php?title=Rendering_Architecture#Threading_considerations

[AnyOldName3]

So it's used 9 times already. A couple are only checks, so don't count as us making something dynamic. Another is in the Bullet debug draw, and I imagine that for debug utilities, a performance hit is acceptable if it makes threading problems go away. The rest are on nodes and textures, and I guess it's possible that it only matters for drawables rather than regular nodes and state stuff. All were committed by Scrawl. I'll try and get to the bottom of this.

[Capostrophic]

For me, a build without the fix crashes in Wine when MOP mist mesh is placed while an appveyor artifact with the fix does not.
Texafornian claims the fix works for him on Windows 10.
DSeyka initially used the wrong build but it works fine for her too.
I think it's a victory.

[ghost]

Just want to specifically mention that sometimes coc'ing to offending regions didn't crash for me even when I was using MOP 6.0 and OpenMW f405b1e, which I assume didn't have this fix in the place.
Don't want them underlying bugs creeping up later on.

[akortunov]

@AnyOldName3, if you check the createNode() code, you will see that I just took data variance from default node handling, so it is pretty the same even in master branch. If we can assume that LOD and Switch nodes can not have controllers, I am fine with replacing it by STATIC.

[akortunov]

I updated this PR to do not use the DYNAMIC variance, but it does not make much difference anyway.

[AnyOldName3]

Yeah, I saw that a bunch of other places in the same file did the same thing, so I'm not convinced that it's a bad thing any more. I know that dynamic drawables are definitely not allowed, but it's probably best to go with the flow in this situation unless we somehow gain the ability to ask Scrawl.

[Capostrophic]

I believe this can be merged.