You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have a standard .obj mesh that has a couple materials.
The mesh's charts are correctly computed and packed according to material, but every resulting chart is assigned material index 0, regardless of the material that the chart is composed of.
Digging into the source code, this is deliberately done in PackCharts, but only when ctx->uvMeshInstances is empty; for uv meshes, the output materials are assigned correctly.
outputChart->material = chart->material;
for (uint32_t f = 0; f < outputChart->faceCount; f++)
outputChart->faceArray[f] = chart->faces[f];
chartIndex++;
Is there a reason for this behavior?
I understand that that UV mesh counterpart uses internal::pack::Chart, which has material data whereas I couldn't find easy access to any material data in the case for normal meshes.
The only way I have been able to avoid this is by changing line 9787 as follows, and referencing the material of the mesh faces in my meshDecl in the external code I am using.
outputChart->material = 0; // Old
outputChart->material = chart->mapFaceToSourceFace(0); // New
The text was updated successfully, but these errors were encountered:
I have a standard
.obj
mesh that has a couple materials.The mesh's charts are correctly computed and packed according to material, but every resulting chart is assigned material index 0, regardless of the material that the chart is composed of.
Digging into the source code, this is deliberately done in
PackCharts
, but only whenctx->uvMeshInstances
is empty; for uv meshes, the output materials are assigned correctly.Here's what I'm referring to:
xatlas.cpp:9787
Versus:
xatlas.cpp:9845
Is there a reason for this behavior?
I understand that that UV mesh counterpart uses
internal::pack::Chart
, which has material data whereas I couldn't find easy access to any material data in the case for normal meshes.The only way I have been able to avoid this is by changing line 9787 as follows, and referencing the material of the mesh faces in my
meshDecl
in the external code I am using.The text was updated successfully, but these errors were encountered: