search

STORM-IRIT / Radium-Engine

Research 3D Engine for rendering, animation and processing
https://storm-irit.github.io/Radium-Engine/
Apache License 2.0
100 stars 50 forks source link

Animation/Skinning of textured objects #236

Closed hoshiryu closed 6 years ago

hoshiryu commented 6 years ago

The actual animation/skinning mecanism recomputes a vertex normal from its one-ring. While working fine for non textured objects, it fails to give the correct normal for textured objects, where vertices are duplicated for each face. Even though there are util functions providing the computation of a duplicate table, it would be better not to discard the one that is computed when loading the file.

hoshiryu commented 6 years ago

The thing is that when texture loading is enabled, then the duplicates are also loaded, in the sense that duplicateTable[i] == i so that edges and faces are loaded correctly w.r.t. texture coordinates. Thus, the duplicateTable loses all meaning and cannot be used anymore to correctly compute the normals after editing the mesh (vertices for skinning, faces for decimation, ...)

A possible work around could be to always compute the duplicate table as if not loading duplicates, and use the corresponding flag of GeometryData to determine which index to put in edges and faces.

dlyr commented 6 years ago

Why the normals are recomputed ? For animation the normals should be transformed along with the vertices right ? Moreover I think if a topological mesh is needed, it should be created at load time, with an association table from topoMesh -> viewMesh ... having a duplicateTable is misleading I think.

nmellado commented 6 years ago

I do agree with @dlyr, it is not clear to me why the normals need to be recomputed.

Regarding topological meshes, we have the work by Xavier submitted in another PR.

hoshiryu commented 6 years ago

I agree that in the case of simple geometric skinning methods (LBS, DQS, CoR) the normals can be transformed along with the vertices since we know the applied transformation. However, in some cases (implicit skinning, mesh manipulation) the normals has to be recomputed w.r.t. the neighborhood of the vertices.

Regarding topological meshes, since the aforementioned PR is not ready for merge by now, we have to manage things somehow, thus the use of a duplicate table.

nmellado commented 6 years ago

Fixed by #239.