Problem with vertex animation (few black vertices) sorted

[lconracl]

Hello,
I would like to ask, if someone else had similar issue, when tried to combine male & female armour meshes into vertex animation.

Both male and female meshes looks good in OpeBRF.

Spoiler: male armour

Spoiler: female armour

But after merging them, there is a problem only with female frame (male part is ok): few vertices turned black and texture seams one the "skirt" (both front and back) became hard.

Spoiler: merged armour

 

[mtarini]

you mean, "hard" as in lighting?

I'm not sure, but both problems seems related to normals. Did you try recomputing them, after the merge?

 

[lconracl]

you mean, "hard" as in lighting?

I'm not sure, but both problems seems related to normals. Did you try recomputing them, after the merge?

Thank you for swift reply!

The "hard" edge (this edge is a edge of mirrored texture), similar effect gives "keep texture seams hard" tick during "recalculate normals" operation, or marking particular edge hard in Blender.

Of course I can recalculate normals, which solve black vertices, but introduce lots of unwanted "hard" edges. This option will work properly for items with less complicated, less separated regions on the uvmap.

It is really strange, as I have prepared 9 armours this way and this is the firs time I encountered issue with feminized frame. And both male & female meshes looks good before merging.

Thank you again for your help.
 

 

[mtarini]

Actually I'm curious too.


There's a couple of ways to assemble the frames in a single vertex ani...

One is to select all frames, right click, [Merges as frames in a vertex ani].
That very direct and shouldn't touch normals at all so I'm puzzled.
It assumes the mesh are just direct modifications of each other, 1:1 correspondences of vertices (and pos).

The other is to copy one frame (ctrl+C) and [Paste Frame] into another (edit->Paste Frame), or Ctrl+Alt+V.
That does a bit more work, according to the setting ([settings]->[on assemble vertex ani]),
the problem is try to guess which vertex of mesh A is which vertex of mesh B, not assuming that they are in the right order.

Which way are you using?
Can I see the .brf file with the "before"?

 

[lconracl]

Always use the first method.

I send you a PM with a link to all four armours (armour A B + feminized A B) in Blender format and as a SMD (ready for OpenBRF). If you have a bit of free time, please have a look.

 

[mtarini]

Nope, cannot replicate the bug. All smooth here.

But, maybe you didn't send me the exact same meshes?

In your screenshot, I read that the "A" set has 1570 faces, 1335 verts, 800 pos.
The "A" mesh I import from your SMD files has 2426 faces, 2165 verts, 1316 pos.

They look similar, but mine looks like has some repeated armour set.

mmmm... Anyway, here's something for you to try:

(1) Change settings:
[Settings]->[On import meshes]->[do nothing]

(2) Re-import your models.
(you'll see that they have a tremendous amount of redundant vertices/pos).

(3) Merge them into an animation.

(4) Is the problem still there?
If it is gone, then, only now, do [clean redundant verts/pos] (which is what it usually does at import time) on the assembled ani.


If that changes anything, it might mean that the problem was due to a face collapsed to exactly a line
(e.g. a face connecting vertices A,B,C where A is an exact copy of B, including text coords and postions).
This might make the "clean up" go different in the two meshes, which makes /apparently/ no difference for either of them but it breaks the "sync" between the two, causing the artifact when you put them together. MAYBE.

(but, with the models you sent me, it seems to work fine with or without that workaround).

 

[lconracl]

I have sent you the whole mesh - basically by removing these extra parts, changing their combinations, new armours are created.

The method you described is working absolutely fine! I think it was a problem with these particular meshes and vertices merging operation during models import. As I said before everything was working fine up to now. This method proposed by you looks more robust.

Thank you again!