Modelviewer - mesh analyzer tool and wrong faces

Started by bitterman, May 25, 2016, 10:30:08 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

bitterman

This is .ase model making in Blender, exported and loaded into modelviewer.

What's wrong with these two faces (colored red)? Ligthing on it also broken.

Normals go outside. And ideas?

And more global questions - what makes (how works) this tool ('mesh analyser')?

Thanks.

The Happy Friar

Can you show a picture in game?  For lighting issues for me it's always been a normal wrong or the material wrong.

bitterman

Sorry, but I even don't have any texture for this model.

But I think this option ('mesh analyzer') related with UW.

Every time when I used other type of unwrap, the wrong faces changed position.

Perhaps this option detect faces with wrong UW.

Thanks anyway.

The Happy Friar

Well, I was figuring if it looks find in game then why worry?  :)

kat

In case this is still outstanding (and for the archive) the model viewer is indicating a split in the mesh, either as a result of a UV split or mesh (smoothing) split.

bitterman

#5
In my case I remade UV (with correcting this part) and problem is gone.

Btw I still don't really understand your tutorial about smoothing mesh in Blender (what really makes Split and how it's related with lighting).

I should probably reread it again three or more times :)

kat

You mean this? Briefly... smoothing is about surface continuity, the way light and shadow/shading is distributed across a mesh. Managing smoothing is essentially about breaking this continuity into manageable sections to give the impression of hard edges. This can be done using 'splits' (ASE) or UV map sections (MD5).

bitterman

#7
On this picture we see smoothed/unsmoothed surfaces via recalculate normals. In idTech4 light distribution is based on normals AFAIK.

Is Split does the same (left figure)? Is it returns the normals to the unsmoothed state?

********************

Hmm, Split adds doubles...

********************

1. Smoothed sphere.
2. Split single face (upper row).
3. Split group of faces (bottom row).

See also Edge split.

kat

#8
Ah right.. mesh splits create physical breaks or holes in the mesh, forcing light/shading to adhere to what such splits define, hard/soft edges. Normal map images over-ride or utilise these splits depending on their being uniquely baked or tiled textures - unique normal maps over-ride because they're high-res versions of the same object, tiled don't because their purpose is to represent 'surface' detailing not an 'object' relative data.

(note: baked normal maps don't actually over-ride, it's more correct to say such mesh objects don't need forced splitting if the object uses uniquely baked normals - if splits exist they tend to adversely affect the appearance of the object because they supersede smoothing based on normals)

A wooden table for example can be mapped with a unique normal map baked from a high-res version of the object. In such instances the normal map defines smoothing/shading (and optionally surface detailing). Mapping the same object with a tiled 'wood' texture however, doesn't work as all that provides is surface detailing, i.e., wood grain. Left in it's raw state this latter approach makes the object appear mushy because the normal map is not providing *object* relative smoothing information (normal orientation as you mention), the mesh is. In such instances it (the mesh) would need to be manually split to define edges and break the uniform surface continuity.

The upshot is that splits tend to be required when models are covered with tiling textures, but not if they are using unique baked data. And yes, the split is caused by a surface break and duplication of vertices along the break - which is what's shown exactly with the pics you've attached... that's the expected behaviour from that arrangement.

bitterman