"Optimise Vertex Buffers For Shaders" breaks smooth shaded faces

[Slamy]

I first thought that this was an ogre bug. But it seems that this converter was to blame. Please have a look at this model.

I've exported it using "Optimise Vertex Buffers For Shaders" checked and opened it in the HLMS editor. The specular part looks weird and divided. Then I disabled this option and got this.

I don't reallly know why this happens and how. But still I want you to know this.

[paroj]

moving this to ogre-next, as we merely forward the options to OgreMeshTool for post-processing: https://github.com/OGRECave/blender2ogre/blob/e04087ed80017d017cca93f445cfd6b609a0b32e/io_ogre/util.py#L192-L194

[darksylinc]

Optimization is lossy.

If the mesh is too big (scale problem, e.g. size > 50 units) precision problems appear in the position due to half floating point. This is the most common problem

Same happens for UVs. If UV are outside 0...1 range half floating point may not be accurate enough.

QTangent optimization is the less prone to problems, but I suppose if the topology is funny it could cause trouble specially if the normals or tangents perform near 180° flips across edges

The first thing to do would be to enable each optimization one by one to find the culprit. Once isolated it may be possible to fix by changing the mesh. But depending on the cause, the solution may be to disable that specific flag, because basically it'd be "working as intended" and the optimization simply should not be applied for this case

[Slamy]

I mean. Now I know and knowing is half the battle. But how shall this tool proceed from here? I now know this but the next poor soul will fall into this trap again. Concerning psychology the usual user will always click on something which has the term "Optimize" in it.

@paroj There should be at least some sort of warning in the blender2ogre tool next to the check box. Or even rename it to "experimental optimization".

[darksylinc]

I agree on the wording/messaging. But "Experimental" would send the wrong message (it's not experimental, it's not going to improve over time).

The technically correct term would be "lossy optimization" or "Optimization (lossy)", but I don't know if it's user friendly enough.

Alternatively: "Strict quality", when disabled we apply optimization