Jump to content
3DCoat Forums

Feature Request - Import multiple textures by UDIM ID


Recommended Posts

  • Member

I would post this in the appropriate forum section but I don't seem to have the permission to create a topic there.

There was a similar feature request from 2014 on Trello here: https://3dcoat.com/mantis/view.php?id=1102

This request is for UDIMs(which 3DCoat doesn't seem to officially support and treats as additional UV sets).

We have a 1MB FBX asset, when imported It uses around 40GB of RAM to support 20 UDIMs at 4k. We'd like to work with 8k but the way 3D Coat seems to handle this is keep all textures in memory even if no colour data is painted on or loaded in via textures?

We already have the 8k textures from an external bake and would like to bring these in to do some post work with 3D Coats tools, the required amount of memory is a bit of an issue.

This feature request is about importing multiple textures at once(our UDIMs), if 3D Coat supported UDIM layouts properly it should be able to easily infer the appropriate textures for each UV set(which is named by it's UDIM ID in our case). All that needs to happen is provide a list of textures or a folder containing them, remove the extension from the file and look at the last 4 numbers for the UDIM IDs to match their UV set. I considered trying to implement this via the Angelscript support, but did not see any information on how to perform these actions with the docs I came across?

Additionally to handle memory issues, would it be possible for 3D Coat to allow a disk cache/scratchdisk to be set by a user to write/read the individual textures from and to until the user actions a save? This way 3D Coat could perhaps use a format where it only reads in the mipmap data of an appropriate resolution or separate files only keeping textures in memory when they're in the viewport and proxying others based on viewport culling or screen/viewport size, ie 512 or 1024 px maps could be used elsewhere on the model data, and keep memory usage down, only presenting/using actual texture when applying paint or some other conditions?

I'm not sure how the software Mari or others might approach it but it'd be great to use 3D Coat for this workflow. We have one asset with 100 UDIMs that just wouldn't be possible to work with in 3D Coat beyond setting very low texture texture resolution and manually adjusting the size and textures loaded in.

Is there a way to fund features/priority in any way? I can understand this may not be as useful/valuable to the existing 3D Coat userbase much, it could attract a new community of users that do have these needs.

Edited by Carlosan
Link correction
Link to comment
Share on other sites

Hi !

Thanks for your suggestion, this feature was forwarded to the developers. It would be nice if you contact them directly so that you can improve the details

Please send this feature request to Andrew Shpagin at



Link to comment
Share on other sites

  • Member

Hi Carlosan, yes I contacted them with this and something else. Haven't heard back yet.

We tried playing around with it a bit again today but not much success. Some similar details as described above.


3DCoat would be great for texturing low poly meshes(less than hundred thousand triangles for us),but our work uses many 8k textures via many udims(uv sets). 3DC needs better import support so that we can bring in all udim textures at once instead of manually.

3DC also does not have good efficiency/optimization for memory with per pixel painting, empty textures(before any texture importing) still allocate memory in full with a long delay(20 UDIM asset is fast at 64px resolution, actual 8k px not so much.), on the hexacore, some operations I've noticed are stuck around 10%(single thread?) and some others will use around 94% but this is less common).

Painting/fill on these was horribly slow too, we could perform a fill and wait around 10 seconds for the operation to be performed. It seemed to be faster if performed via UV preview pane(2D) vs 3D view clicking the mesh. Using a brush wasn't very smooth in 3D, I think it was alright when in UV view(but not really useful for us). We tried to isolate to just two UDIMs(for this mesh two sections that are very planar like), to paint over a seam issue with clone brush but 3DC was too unresponsive for us to make use of it. I guess it's due to texture size since the mesh was quite low poly.

Toggling UV layer/sets(udim tiles) visibility doesn't reduce memory(I guess there is no disk cache for the textures or memory compression?), Mari uses considerably less memory. A 1MB FBX file with 20 UDIMs used 300MB roughly with these set to 64px each, adjusted 5 UDIM/UV-Sets to use 8k textures and 50GB+ RAM was used. Said something about changes when moving from UV room to Paint room, don't believe I did anything beyond toggling visibility and loading/importing textures, confirmed it and went up to 100GB roughly before dropping back to around 50GB RAM. Toggled visibility off for all UDIMs and showed 2 UDIM(two very low poly squares(1,000 triangles maybe?), set resolution to 8k, didn't reset the other 5 from before to 64 px, RAM usage went over 100GB, had to kill 3DC to try avoid memory usage crashing my system.

Link to comment
Share on other sites

  • 1 month later...
  • Member
On 10/10/2017 at 1:15 AM, Andrew Shpagin said:

Of course, maybe you tried import checkbox "Import tiles as UV sets". Why is it not working for you? It is done specially for UDIM.

Memory consumption is big issue, not easy to resolve, it requires complete re-ingeneering ppp painting...

Hi Andrew, I did enable the checkbox to import the UDIMs correctly. The issue was texture size setting and number of tiles/uv-sets can slow down 3DC and cause huge memory usage. If the mesh data loaded in has no texture loaded in/connected(blank data) perhaps don't allocate memory? Only when start to interact with that mesh data with paint or load/import texture to that uv-set/tile, should memory be allocated.

I have seen from recent research that octree data structure can be used for making texture data more efficient to work with. Some form of proxy mode would also help(cache to fast M.2 NVMe SSD? Compressed/low-res texture proxy, load full-res textures for current and nearby UV islands around brush, perhaps on stroke?). 3DC could also proxy/cache by taking large texture like 8/16k and treating it as several smaller tiles/textures, it would make streaming more possible for memory efficiency, smaller textures can load in parallel neighbours in a faster time too. Take a look at active branch of Crunch texture compression being maintained by the Unity engine, it has good compression with recent 5x speedup of compression time, it is open-source so 3DC could make use of it for building texture cache. Then during export, can write the texture chunks back into original 8/16k textures.

Currently I only know of Mari as being able to effectively handle painting over multiple UDIMs without big issues due to texture streaming. Unreal Engine 4 has a third party tool called Graphite that also approaches texture handling differently to get performance gains(but may not be applicable for real-time texture editing).

Link to comment
Share on other sites

  • 2 years later...
  • 1 year later...
  • Member

+1 vote for this. Having texture files proper named including the "UV Set names" (1001, 1002, ...) and "channels" (diffuse, specular, ...) we could then use a wildcard during import, sending it directly to the correspondent UV Set, that would be amazing!

  • Like 2
Link to comment
Share on other sites

  • 3 weeks later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Create New...