Uv channels keep switching

(Shaderbytes) #1

hi there so this was a problem from blender fbx files, but now when importing the .blender file directly im getting the same issue. What is weird is that it is not switching all the materials UVS… but most of them, like about 80 - 90% if i had to guess.

This is a huge problem to me now as i need to target uploading textures from the viewer api to these materials diffuse and you have no means to siptulate which uv channel to target from the api.

The UV’s on index 0 where for those uploaded diffuse textures , the UV’s on index 1 were for surface patterns and normals set in the editor. This worked great…


Now these got switched in sketchfab , so the surface patterns/normals are on index 0 and the diffuse UV’s are on index 1.

If i upload any textures they will just be assigned to index 0 by default and will be incorrect. @james had a hunch it might just use the uv index already assigned for that channel, but here is the catch … there are no textures assigned to that channel in the editor and so it is not possible to select the UV index to use

I just had to fix up a heap of models for virtual studio because of muddled uv channels, I was told this could be because of some reprocessing but i even tried to reupload those models and they were still broken. So i had to fix all of them by hand.

This model im currently talking about had its UV’s inverted this morning while reuploading… please somebody get to the bottom of this issue. the model has a huge amount of materials, editing is really painful and long and in this case causing the model to be usable by your api for lack of ability to target uv index of channels.


Hey, thanks for the follow up. @waleguene is going to take a look when he gets back from holiday.


It was on some of the phone models right? Do you have any super simple sample file (say that 5 times fast :thinking: ) that reproduces it?

(Shaderbytes) #5

it was on many different models , cars, vr headsets … many, anyway i fixed those up manually - those dont bother me now, it is the current job im busy with , the fight suite that is causing me trouble now and it is not a small model. I will create a simple model with multi uv channels for testing purposes and send you the file and upload link a bit later

(Shaderbytes) #6

@james here you go :

blend file :

fbx :

So i first uploaded the fbx , all materials have two uv channels , channel one is mapped to a quarter of the texture size and i assigned it to the top left and bottom right of this diffuse texture :

uv channel two is a full frame UV and i assigned the normal map to this texture :

the result is this :

I tried reuploading the same fbx a few times and could not get the bug to trigger i even added two planes to try and change some things to get the bug to happen but had no success. Then i uploaded the .blend file the fbx was exported from and it switched the uv maps channels as can be seen here :

I had to reassign the texture of the diffuse as it lost it reference because of switching the source to a .blend from fbx , anyway regardless of that the uv channels were switched, this is evident because the diffuse is showing a full frame texture and the normal is showing a quarter frame… exactly opposite of the original fbx upload.

model link is here :

chat soon

(Shaderbytes) #7

i just tested re uploading the exact same blend file two or three times , no edits were made to the blend file … and it switched the uv channels again…

so this issue is happening only with .blend file uploads it seems not fbx. I cant use fbx uploads because of the animation bug i had with importing fbx (remember not too long ago , you helped me with this )

So anyway to conclude , uploading fbx file produced correct uv order , switching to .blend source changed the uv order , uploading the same .blend two or three times changed the order back again…

I cant say how many times it would change the order , this is enough testing to show there is a bug. You have the fbx and .blend files now and they are super tiny so it is easy for doing repetitive testing :wink:

chat soon

(Stephomi) #8

Did you try to set the correct texCoordUnit in the viewer api call? It should work normally.

What version of the api are you using? I don’t know what version you are using, but you can add graph_optimizer=0 to make sure we don’t delete one of the 2 UVs (if no channel is using it).

Edit : we tried and can confirm that texCoordUnit is working fine through viewer API
Here’s an example when we switch albedo on uv 0:

(Shaderbytes) #9

why do all the materials switch in the fiddle? there are 8 planes and 8 materials. In the fiddle i see you are only targeting one material, yet all have switched?

(Stephomi) #10

On top of graph_optimizer:0 you can also add merge_materials:0 :

The current logic is that graph_optimizer and merge_materials are enabled only if

  • there is no version provided
  • the version used is 1.1.0

Viewer-1.2.0 mouse events not working
(Shaderbytes) #11

ah neat , thank @stephomi

Im using my utility and the texture changing function does accept an optional argument to change any of the texture object properties so this would be easy to handle thanks.

OF coarse this helps and is a work around for now / super useful to know for future reference, but obviously the bug with .blend uploads still needs to be fixed at some point anyway since if i need to update the model and it end up switching the uvs for some reason im going to have to adjust all my code to target a different texCoordUnit each time…

(Stephomi) #12

I’ll let @waleguene see if there is really something wrong (maybe the .blend is correctly referencing the texture and we fail to assign it on any channel, not to mention the UV assignment too).

I had to reassign the texture of the diffuse as it lost it reference because of switching the source to a .blend from fbx

UV assignment is only done if a texture is referenced in the original file, if the .blend isn’t referencing any texture then it won’t work.

Note that yon can simulate a “frontend reprocessing” with https://sketchfab.com/models/7ffe7399c5b44602bcffcf299440ebfd/edit?process_options=1
As you can see, no texture is bound, so any texture that you’ll bind manually in the editor will end up on the first UV.

(Shaderbytes) #13

well i cant say how the fbx exported but in the .blend ( from which the fbx is exported ) there are no textures assigned to any of the uv channels. You have links to the source files posted above.

Texture were only uploaded and assigned in the sketchfab editor. Only two channels of the materials were used and both had textures assigned diffuse and normal.

Regardless of this, re uploading the exact same .blend file ( which has no textures assigned ) a few times (to the scene where textures are assigned to two channels of each material in the editor ) caused the uvs channels to switch… so there is a bug.

Anyway @waleguene has the link to the simple blend file and can test it himself , i tested it last night and know there is a glitch, hopefully he can find it and sort it.

Thanks for the help :wink:

(Waleguene) #14

Hi @shaderbytes,

Thanks a lot for sharing these samples.
There are some known inconsistencies in UV channel order between several processings of a same FBX model. I reproduced the issue with the .blend file so the inconsistencies are also in Blender processing.

I’ll debug and keep you in touch,

(Shaderbytes) #15

thanks @waleguene , I have never had the problem with fbx so far , well with uploading all previous models , just had the thing where recent reprocessing causing some switching with existing models, but reuploading that same model fbx then produced the same new ordering so that i can understand. The .blender upload seems to switch nearly every time i upload it. Im only using .blender format because of a bug in importing fbx with animation … the .blend imports correctly , the fbx does not. I tested importing the fbx in unity and back into blender and it works as expected, anyway i did post about it here in the forums in another thread, so something else to look into :wink:


(Waleguene) #16

@shaderbytes Could you confirm that you have the issue ONLY when you follow this process:
1- Upload a model with textures (or not)
2- Reupload a new version of the model with no texture

(Shaderbytes) #17

i never zip the upload so it is only the .blend and no textures are packed in it.

My fbx exports also dont have textures packed.

The fbx and .blend file i attached close to the top of this thread are perfect examples of my .blend files and fbx export ( the one with just planes )

no textures are ever uploaded with these models all textures are assigned in the editor.

You can reupload the same .blend file provided here ( no changes in the source ) and it switches the uv over and over most of the time , sometimes it does not.

EDIT so i guess it is because the materials have textures assigned in the editor and the re uploaded model has materials without textures then?

(Waleguene) #18

Ok thanks.

Then, in the case of an upload with no textures, UVs order is random and depends on Python internals (where dictionaries iterate over key/value pairs in arbitrary order).
This is something easy to fix on our side, but there is no workaround that you could use in the meantime.

(Note: when the model has textures, the order remains the same, the order remains the same between several processings, but can be different from original order in Blender)