Project

General

Profile

Bug #3957

Weird bodypart rendering if a node has reserved name

Added by Andrei Kortunov 4 months ago. Updated 3 months ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
NIF format
Target version:
Start date:
07/17/2017
% Done:

100%

Reproducibility:
Always
Operating system:
Other
Severity:
Normal

Description

Tested with Better Clothes 1.1.
Take a look on a screenshot (Screenshot_20170717_145609.png). PC on this screenshot wears "common_shirt_05".

If you open an attached NIF file, you will see that NIF file has a two nodes: a NiNode with a "Chest" name and a NiTriShape with "Tri Chest" name (look at NifSkope.png).
As result, when OpenMW searches for node for Chest bodypart, it treats the whole shirt ("Chest" NiNode instead of only "Tri Chest" NiTriShape) as a Chest node.

This NIF file can be fixed by renaming the "Chest" NiNode.

An original engine does not have this issue. It seems the engine uses only NiTriShape nodes as bodypart meshes.

bc_shirt_com_05_male.nif (72.2 KB) Andrei Kortunov, 07/17/2017 01:02 PM

NifSkope.png View (79.5 KB) Andrei Kortunov, 07/17/2017 01:03 PM

Screenshot_20170717_145609.png View (759 KB) Andrei Kortunov, 07/17/2017 01:03 PM

Screenshot_20170829_181428.jpg View (1.43 MB) Andrei Kortunov, 08/29/2017 04:17 PM

Associated revisions

Revision 3fc86342 (diff)
Added by scrawl . 3 months ago

Check for a Geometry node when attaching bodyparts (Fixes #3957)

History

#1 Updated by scrawl . 4 months ago

There's a bit of history to this one. Originally, OpenMW would only accept NiTriShapes named 'Tri <part>'. Then, to fix bug #1088, we added a check for NiTriShapes named '<part>'. Finally, with the port to OSG there was no longer an easy way to distinguish TriShapes from other nodes so the condition just became 'any node named Tri <part> or <part>'. (A TriShape usually translates to a MatrixTransform with a child Geometry, but after optimizations are run it might look different; also, skinned or morphed meshes will use different nodes).

Just an idea, maybe in this case the vanilla engine ignores the 'Chest' node because it was optimized away? Maybe you could try adding a NiMaterialProperty or a texture to that node to see if it's used then.

#2 Updated by scrawl . 4 months ago

Or maybe they search for a 'Tri <part>' node first and only fall back to '<part>' if the former isn't found?

#3 Updated by scrawl . 4 months ago

One last thought, who knows if the preceding 'tri ' has any meaning at all, maybe they just check for '<part>' anywhere in the string.

Anyway, to sum up, we could use some more research.

#4 Updated by Andrei Kortunov 4 months ago

One last thought, who knows if the preceding 'tri ' has any meaning at all, maybe they just check for '<part>' anywhere in the string.

I tried to rename "Tri Chest" to "Tri2 Chest" in this NIF. Morrowind in this case failed to find any chest part for this file.

#5 Updated by Andrei Kortunov 4 months ago

Anyway both "Chest" and "Tri Chest" are allowed, but only for NiTriShapes. It seems Morrowind does not use NiNodes for bodyparts.

#6 Updated by Andrei Kortunov 4 months ago

with the port to OSG there was no longer an easy way to distinguish TriShapes from other nodes

That's weird. We need to distinguish these nodes somehow.
Can we put an attribute to NiTriShapes, or add a special suffix to its names as workaround, at least?

#7 Updated by scrawl . 4 months ago

In order to create the equivalent of a "TriShape" we have to create several different nodes, some of which may be removed by optimization later. Usually, there will be a MatrixTransform node that creates the transform offset with a Geometry child to do the rendering. If the transform is the identity and is not updated by any keyframes, the optimizer will turn the MatrixTransform into a Group. If the Group is then empty (i.e. it has no StateSet), it may be removed entirely and replaced by just the Geometry.

If we add a tag to all of these nodes that says 'this is part of a TriShape' then that may prevent the optimizations from working at all (since the optimizer would think the tag is something important that must be retained).

In any case, adding such a tag seems wrong; the conversion process from NIF to OSG is supposed to produce something that's not reliant on NIF terminology in order to use it. And since we already support the native OSG format, that one should be (and is, until now) usable for bodyparts, as well, without having to call things 'TriShapes'.

As a second best solution, maybe we can search for a Drawable with the given name, then go up until we find the first node that contains a StateSet. Under the assumption that all body parts actually have a StateSet (i.e. not just a blank untextured model), that should work.

Note: Drawables are not currently given a name, would have to add that e.g. here:
https://github.com/OpenMW/openmw/blob/master/components/nifosg/nifloader.cpp#L1131

Similarly, we could also look for any node with the given name and then check if it has a 'Geometry' child to make sure that it's (probably) a 'TriShape'. That won't work for geomorphed (e.g. heads) or skinned meshes, though, since they use additional nodes in between. Maybe a combination of both approaches is best?

#8 Updated by Andrei Kortunov 3 months ago

Looks like solution applied in commit 3fc86342061bab0c30bed6821f66933fef546930 breaks bodypart texturing (take a look at attached screenshot).

#9 Updated by Alexei Dobrohotov 3 months ago

  • Status changed from New to In Progress
  • Assignee set to scrawl .
  • Target version set to openmw-0.43
  • Operating system changed from Linux to Other

#10 Updated by scrawl . 3 months ago

  • Status changed from In Progress to Closed
  • % Done changed from 0 to 100

#11 Updated by scrawl . 3 months ago

  • Status changed from Closed to Confirmed
  • % Done changed from 100 to 0

Looks like solution applied in commit 3fc86342061bab0c30bed6821f66933fef546930 breaks bodypart texturing (take a look at attached screenshot).

Only breaks when shaders are enabled. I can think of a fix but I need to test first that it won't impact performance negatively. Solution has been reverted for now.

Anyway it looks like there was still another issue with overlapping clothes, see screenshot. Bug in the mod or another (unrelated?) bug in OpenMW?

#12 Updated by scrawl . 3 months ago

Screenshot upload didn't work. The issue is Hul in Balmora, legs are overlapping pants.

#13 Updated by Andrei Kortunov 3 months ago

The issue is Hul in Balmora, legs are overlapping pants.

IIRC, to make Better Clothes work properly, you need a Better Bodies and BB-combatible replacer for beast races (a New Beast Bodies, for example).
This should fix bodyparts overlapping.

#14 Updated by scrawl . 3 months ago

to make Better Clothes work properly, you need [..]

I see.

#15 Updated by scrawl . 3 months ago

  • Status changed from Confirmed to Closed
  • % Done changed from 0 to 100

Also available in: Atom PDF