I would like to ask, does Gltf also apply different textures to each polygon like Fbx? I use the same set of images to generate a material collection in the project (of course, FBX uses LambertMaterial, GLTF uses PbrMaterial), the same MaterialIndices, FBX export is good, but GLTF export is not good, what is the reason?
Could you please share a sample code snippet and some sample files for our reference so that we can test the scenario in our environment and address it accordingly.
What I did is after importing an Fbx, the parameters of Node.Materials, VertexElementMaterial, VertexElementUV were not modified, and after exporting it as a Gltf file, the texture effect of some polygons changed. The effect diagram is as followsGltf-Renderings.jpg (24.1 KB)
Fbx-Renderings.jpg (57.0 KB)
We have logged a ticket as THREEDNET-1111 in our issue tracking system to perform an investigation on this scenario. We will be looking into its details and will inform you as soon as analysis is complete. Please be patient and spare us some time.
Is there any progress on this issue please?
The earlier logged ticket is currently under the phase of investigation. GLTF uses primitive to separate polygons with different materials, each primitive represents a draw call.
Aspose.3D will split the mesh into multiple primitives by material before export it to GLTF/GLB file.
Can you please also share the FBX file that produces this bug as this would help us in investigating the issue accordingly.
sdgc-4.zip (674.3 KB)
Please check the attached file, when I use aspose to import this file, and then use aspose to export as fbx, the texture effects of the new fbx file are all correct, but when I export as a gltf file (Node.Materials, VertexElementMaterial, The parameters of VertexElementUV are not modified, FBX uses LambertMaterial, GLTF uses PbrMaterial) The texture effect of some polygons has changed and become wrong, please help me to find out what is the reason.
Thanks for providing the sample file. The information of the ticket has been updated accordingly. We will let you know once we have further updates.
It is certain that the correct original UV data is written when using aspose to export GLTF, and the UV data read when importing the same GLTF file using aspose is inconsistent with the original UV data (the number is inconsistent, the value also inconsistent), which might be the reason for the texture error? Moreover, the texture of this gltf file obtained on the special gltf browser is also wrong, which means that the exported GLTF file is wrong, please help.
Thank you for your prompt reply, I found some problems, I want to ask you, that is, when I exported the GLTF file, I created one entity, and then when I imported the GLTF file I just exported, I read 8 entities. Are the corresponding attribute values in each entity not corresponding? For example, the materialIndex of each entity has only a value of 0. Is this a reason for texture errors?
This is because the mesh has been split into different sub meshes defined by material, the glTF does not natively support multiple materials in one mesh. Furthermore, we need to check the file that you have shared and we will try to complete the investigation next week. We will let you know about further updates. Please give us little time.
When exporting the gltf file, after writing the correct UV coordinate data, does aspose do some processing on the UV coordinate data (and this processing is not always correct)? The same process of creating a scene, after exporting fbx, it is correct to read the texture coordinates of fbx, and the texture displayed by the fbx file model is also correct. After exporting gltf, go to read the UV coordinates of gltf, you can find and write the original The input UV data has changed, resulting in the wrong texture displayed by the gltf file model.
1.zip (96.1 KB)
After importing this FBX file, it can be read that the count of UV coordinate data is 147, and the count of indices is 435. After exporting to gltf, the count of UV coordinate data of re-importing this gltf becomes 392, and the count of indices is 0. A noticeable change can be seen.
We have logged an issue as THREEDNET-1229 in our issue tracking system for the sake of further investigation. We will look into its details and let you know as soon as it is resolved. Please be patient and spare us some time.
We are sorry for the inconvenience.
Check the comparison snapshot, rendered by 3D viewer from Windows, the UV data is correct at render stage.
Here’s why the data has changed:
FBX separates the definition of control point, UV, each of them can have different index, and polygon can have more than 3 vertices this format is much easier for editing.
GLTF is essentially records the draw calls of OpenGL, the vertex data must be triangulated, the raw number of control points, uv, normal are exactly to the number of vertices, indices reuses the vertex, not the vertex component.
VertexElementXXXX uses different ReferenceMode + MappingMode to identify the data in the final vertex, that’s why you have zero for glTF and non-zero for FBX, we have internal deduplication utilities, can gather indices, but this would slow down the import procedure, so it’s only used in few format importer.comparison.jpg (223.1 KB)
Thank you very much for your patience.
1 Like