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
Describe the bug
Collada: Now that we properly import uv channel numbers used by textures (merged today), it becomes apparent that second half of problem is importing data into correct uv channels. We properly find out that mesh contains data in channels a, b and c (example). But then d6aacef changes a,b,c to 0,1,2 and we store data into wrong uv channels.
To Reproduce
Steps to reproduce the behavior:
Import and render .dae with texture mapped mesh that uses uv channel 1.
See that render is wrong, material wants data from channel 1 but data are stored in channel 0.
Expected behavior
Collada files should be imported with original uv channel numbers in both meshes and materials.
Additional context
I have problem locally fixed by reverting "empty slots are not allowed" paragraph of d6aacef,
I'll send patch.
I'll also document that empty slots in mTextureCoords are ok... are they?
Also, I don't use GetNumUVChannels(), but I see it's implemented wrong. If we allow empty slots, it needs small fix.
Finally, I'm concerned about .dae files that contain channel numbers higher than AI_MAX_NUMBER_OF_TEXTURECOORDS. Do they exist? Are they common? (My approach in LightsprintSDK was to make array of channels resizable, so I never had to figure out how large numbers exist in wild.)
The text was updated successfully, but these errors were encountered:
StepanHrbek
changed the title
Bug: Collada uvs from channels a,b,c are imported into channels 0,1,2.
Bug: Collada uvs from channels a,b,c are imported into Assimp channels 0,1,2.
Jun 21, 2024
Describe the bug
Collada: Now that we properly import uv channel numbers used by textures (merged today), it becomes apparent that second half of problem is importing data into correct uv channels. We properly find out that mesh contains data in channels a, b and c (example). But then d6aacef changes a,b,c to 0,1,2 and we store data into wrong uv channels.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Collada files should be imported with original uv channel numbers in both meshes and materials.
Additional context
I have problem locally fixed by reverting "empty slots are not allowed" paragraph of d6aacef,
I'll send patch.
I'll also document that empty slots in mTextureCoords are ok... are they?
Also, I don't use GetNumUVChannels(), but I see it's implemented wrong. If we allow empty slots, it needs small fix.
Finally, I'm concerned about .dae files that contain channel numbers higher than AI_MAX_NUMBER_OF_TEXTURECOORDS. Do they exist? Are they common? (My approach in LightsprintSDK was to make array of channels resizable, so I never had to figure out how large numbers exist in wild.)
The text was updated successfully, but these errors were encountered: