I’m trying to reproject textures onto remodelled geometry and having assumed UDIMs would be supported (because RC uses them when unwrapping) it appears they’re not. I thought I’d work around it by exporting the geo for each UDIM separately, but RC gets confused by the missing geo and projects ‘ghosts’ of objects onto other surfaces.
Searching the forum suggests the UDIM issue will be addressed in the next version, but those comments are from back in July. Is it possible to get an update on the situation?
1 Like
Forgive the bump, but a response to this would be appreciated.
For the sake of clarity I’ve attached a screenshot of the UVs I’m trying to bake. Should this work? If I’m missing something obvious then some hints would be great. Thanks 
Hi IanB
We support UDIMs, so it seems it is not compatible with your application’s results ? what app are you using to create the UDIM layout ?
Hi,
I’m using modo. Importing the model back into modo or maya shows the UVs laid out exactly as in the screengrab above. OBJ is such a simple format it’s hard to imagine how that could be the culprit.
Will do some more tests and see if I have any better luck…
Hi IanB
Get back to us with the results, and could you share the dataset so that we can take a look at the data ? have you already tried to texture the model with custom UVs inside RC ?
I’m sure allowing RC to create the UVs will work fine, but using ‘proper’ manually unwrapped textures is preferable for many reasons.
Is there a way to view the UVs of an imported OBJ? It would help determine which part of the process is going wrong.
Thanks for the help and sorry for the silly questions, RC is still pretty new to me.
Hi IanB
No, it is not possible but we support OBJ with CUSTOM UVs on import, just try this workflow and when you get in any issues, report it here so that we can take a look and fix it…
After importing an OBJ with the UVs arranged as above and reprojecting the textures, when I export from RC I get the results as attached. At some point all the UVs are being moved into the 0-1 space and textures are baked on top of each other.
I honestly can’t understand how this can be caused by the OBJ. There’s nothing in the format that specifies a ‘UDIM’, they’re simply values outside the range 0-1. For example when opening an OBJ in a text editor, the UV coordinates of a ‘UDIM’ simply look like this:
- Code:
vt 4.54622 0.504682
vt 4.54185 0.500253
vt 4.55087 0.489552
vt 4.5559 0.493019
vt 4.55762 0.477589
vt 4.5631 0.480019
vt 4.56197 0.464828
vt 4.56769 0.466182
vt 4.56385 0.451732
vt 4.56961 0.452009
vt 4.56331 0.438754
vt 4.56892 0.437989
vt 4.56045 0.426306
vt 4.56576 0.424568
vt 4.55547 0.414718
vt 4.56034 0.412103
vt 4.54858 0.404228
vt 4.55294 0.400849
I’m still convinced this simply doesn’t work. Even when running the texture command I can see from the result on the point cloud that the UVs are being improperly interpreted. Is it possible there’s some misunderstanding about what I’m trying to accomplish?
In my first post I referred to comments from July that UDIM support was in development. Those were here and here. The only info in the announcements forum since then is for 2091 (which was only a few days after the ‘in development’ comments) so I can’t tell if or when UDIM support was actually added.
I’m using 2158 now, is there somewhere I can see release notes for this or other builds since July?
Hi IanB
its possible to get the data from you so we can take a look on this ?
Send it with small quick description and put there even the UVed UDIMM model so we can figure out where the problem is…
Send it please to milos.lukac@capturingreality.com
What data is it you need? I’ve got an .rcproj, 1.7GB of source images and a folder with ~3GB of .dat files. Obviously uploading that lot somewhere would take quite some time.
Hi IanB
What data is it you need? I’ve got an .rcproj, 1.7GB of source images and a folder with ~3GB of .dat files. Obviously uploading that lot somewhere would take quite some time.
Not a problem, but we will have the same data so we can start to look for the issue and fix it…
I sent an email yesterday with a link to the project data. Just wanted to share another very simple example…
The attached zip file contains an OBJ which consists of a simple cube and sphere in the same mesh layer. The UVs for the sphere are on UDIM 1001 and the cube on 1002, as illustrated in the attached ‘before’ image (the cube is orange because its polys are selected, just for clarity). If this is imported into *any* RC project and exported again, the UVs for the cube are moved to the 1001 tile. This can be seen in the ‘after’ image.
It’s my belief that the error is happening when the OBJ is imported. Any textures created on an object like this won’t work properly because of the overlapping UVs, and instead of the export creating two texture files as expected, it only creates one.
I’ve also discovered that this problem manifests itself when only using one UV tile. If the UVs exactly fill the default 0-1 space, any values which are exactly 1 will be changed to 0 when imported.
RC certainly isn’t the only software to exhibit problems like this and it’s generally good practice to scale UVs down slightly to avoid it. However, it’s still an issue which can result in long processing times resulting in failed textures.
The attached image shows what happens to the UVs in this case. The top is before the model is imported, and below it the model when exported from RC. The reason for the red is because the error causes the all UVs to overlap, which is obviously a bad thing.