Indices Optimization and improved simplification

[RaananW]

Hi gang,

 

After dad72 sent me a few meshes he has been trying to simplify, I noticed there was some kind of a problem with the simplification process.

The meshes I have tested always worked, but external meshes were not simplified correctly - holes appeared where they shouldn't have had appear. 

 

Investigating that took a little while, and the result was that the meshes' indices are not optimized. meaning - Some vertices were duplicated during the export process, and were used as a reference of an index. this leads to no problem viewing the mesh, but presents a problem to the simplification process, since it relies heavily on the number of triangles using each vertex.

 

Tl;dr

 

Some of the exporters don't try to avoid redundant vertex data which is fine for viewing but not for simplification.

 

If you encounter such a  problem using the simplification function, you first need to optimize the indices. you do that by (surprisingly)  using the optimizeIndices function now implemented in BABYLON.Mesh. It takes some time to optimize the indices (especially if it is a large mesh) so use it only when you really need it.

 

Other than that I have accelerated the decimation process (removed a few unneeded lines of code and corrected some others).

 

An example can be found here - http://www.babylonjs-playground.com/#2JBSNA#2 (be a bit patient, you will eventually see an alert dialog when it finishes).  The skull simplifies quite nicely 

 

I will document everything in the next day or two.

 

Any questions - please let me know.

[GameMonetize]

Huge! Thank you so much Raanan!

[Dad72]

Hi Raanan

 

I have three problem:

 

1) with new.optimizeIndices. This distorts completely Multimaterial textures. That may not be supported.

 

Can be seen on the T'SHIRT character and the stairs.

 

 

2)  quality 0.9 simplification greatly reduces the number of vertices as you can see in the picture:

 

Also, the character does not simplify all the same scale (the decimated) (the scale he places in 1,1,1 instead of 0.3, 0.3, 0.3) than the base and you can see a part of the body (the head ) but not the rest of the body.

 

 

Code used:

mesh.optimizeIndices(function() {    mesh.simplify([{distance:90, quality:0.9}, {distance:150, quality:0.8}, {distance:200, quality:0.7}, {distance:300, quality:0.6}]);});

3) With mesh.optimizeIndices distorts certain part of the mesh

 

before:

 

after:

[RaananW]

Hi,

 

so :

1) MultiMaterial should work fine, I will need the mesh to check this. to me it looks like the border problem which cannot be addressed (If the mesh is not completely "closed" it will remove triangles and not just "simplify" them).  What level of reduction did you use there?

 

2) This can have a lot of reasons. Did you use the optimization method? it can be that the original mesh has a lot of redundant vertices. The 2nd option is that a lot of vertices are marked to be removed at the first iteration (the simplification works with threshold filtering per iteration and not with sorted arrays to make it faster). Again, I will need the mesh to check this.

 

3) that's odd, I have tested the optimization with this mesh (you sent it to me already). I will check it again and let you know. Might be a sub-meshes issue, but i thought i resolved this.

 

All in all - simplification should be used for relatively far objects so that the gpu will not be "overwhelmed" with too many vertices per rendered frame. It will sadly alter the shape of an object to a certain extent as this is the downside of simplification :-)

[Dad72]

Ok, I send you the models by MP

[RaananW]

Ok, that took a while :-)

 

A new PR was just mrged into the 2.1 alpha version ob babylon js, improving the improvement. The main problem was that in certain cases the optimizeIndices will not work correctly. Certain vertices will have the same position and normal, but different uv definitions, which lead to those errors that dad72 has found. The same goes to submeshes. Most of the submeshes has those issues, since they are not more than one mesh divided. so the overlap is problematic.

 

I have integrated the indices optimization into the decimation process. A new option was introduced to the settings that will enable/disable mesh optimization. I have tried improving the uv coordinates after decimation, but this will take a little longer than expected, so it might be implemented for BJS 2.2 or 3 .

There is still the option to use optimizeIndices (which will save some time and improve performance), but it might lead to those errors.

 

Everything will be soon documented.

 

A small note about submeshes - the entire process should work with submeshes. There is however a big chance that triangles will still disappear. This is again due to the lack of border detection. The triangles that will be gone are always at the border, the connection between one submesh and the other.