Max2Babylon: Meshes are 'optimized' even if 'Try to optimize vertices' is off

[ephb]

It seems the BabylonJS Exporter does some sort of mesh optimization or compression when exporting and there seems to be no way to turn this off. Toggling 'Try to optimize vertices' does not have any effect on this.

The screenshot shows two objects which should look the same. But the one with the jagged edges is scale to 0.001 at the start of the animation and shows up with only half the vertices in the Babylon sandbox (7072 instead of its original 18852). Everything but the starting scale is the same between these to objects in

[Drigax]

Interesting. I'm not sure off hand why this would happen, I'll have to debug through our mesh export process and see why we would be optimizing regardless of provided export setting after I take a look at #602

[Drigax]

Can you help me reproduce this?
I tried making a repro scene using text meshes but I'm unable to reproduce the issue.

All meshes have optimized toggle disabled, with the only difference between the left and right pairs are their starting scale of 0.001, which is changed to 1 at frame 11.

The top and bottom pairs are optmized and unoptimized versions of the same initial mesh, the unoptimized mesh with a vertcount of 60588, and the optimized with a vert count of 21342.

TextMeshWithDifferentScalingAndOptimization.zip

[ephb]

Thank you for looking into this.
I will look into my settings and provide the file on Monday.
It's not a text mesh problem, as I converted them all to editable polys before and it alse happens on other geometry that is scaled.

Do your meshes look fine in the resulting gltf? Also what unit settings are you using?

[Drigax]

Yes, the meshes don't look aliased in the export either:

This scene uses generic units. In my experience testing with other scenes that use hidden scaling, I haven't noticed an issue with the mesh geometry being aliased either.

[ephb]

I have no clue, what could be different on my side, that it just works for both of you.
Which Max version are you using?
I have attached a demo scene for Max 2019 that shows this behavior.
This screenshot shows it happening to the sweeped spline as well as the text, it is just more noticeable on text.

babylonjs_bug_report_v01.zip

[Drigax]

Thanks for the repro scene, this definitely helped me understand the root cause here:

Exporters/3ds Max/Max2Babylon/Exporter/BabylonExporter.Mesh.cs

Lines 739 to 751 in 992d3d5

	// Position can by retrieved in world space or object space
	// Unfortunately, this value can't be retrieved in local space
	var vertex = new GlobalVertex
	{
	BaseIndex = vertexIndex,
	Position = mesh.GetVertex(vertexIndex, false), // world space
	Normal = mesh.GetNormal((int)face.Norm[facePart], true) // object space (world space was somehow bugged for normal)
	};
	//System.Diagnostics.Debug.WriteLine("vertex normal: " + string.Join(", ", vertex.Normal.ToArray().Select(v => Math.Round(v, 3))));
	// position (from world to local/node space)
	vertex.Position = invertedWorldMatrix.PointTransform(vertex.Position);

We retrieve world space mesh vertex coordinates from max, then use the world-to-local matrix to get the mesh vertices with respect to the local (mesh parent) transform.

This worked in my repro scene as I only scaled to 0.001 of the original scale, while you used a scale of 0.00001. I'm getting increasingly convinced that this causes us to lose precision in calculating the local-space coordinates of our vertex positions, which is why the meshes appear compressed. yikes.

I'll try to see if we can work around this issue (Like why don't we transform from object-space vertex coordinates?)

[ephb]

Oh yes you are definitely right. Doing a quick check by using object space. But of course it breaks rotations to change just these lines as can be seen by my flipped objects. :)

Position = mesh.GetVertex(vertexIndex, true), // use object space instead

and
// position (from world to local/node space) commented out for test //vertex.Position = invertedWorldMatrix.PointTransform(vertex.Position);