While each of materials having its own UV and texel density ? While keeping same or synced node pr layering system across all those materials and automated export.
Just use UDIMs - it's what they're for The only thing you lose is different shaders in your painting app.
You can set painter up to export with specific naming templates for each tile etc so you aren't stuck with the default UDIM naming We're doing this at work currently and it's working a lot better than using separate texturesets
An example is repeating tilable road 2kx2k material set with narrow 64x2k painted lines and 512x4k road edges and a second layer of alternating dirt road 1kx4k. But when it came to crossroad or branching it's unique cut also non-square mostly that needs to blend into tilable materials well . All this having 512x2k tillable with very big interval splat macro to mix dirt and asphalt + color /normal /spec macro layer.(another macro layer). The unique areas have to be slightly bigger texel size in general in macro layers because of too many unique varieties .
Or another example: A roadside barrier with tilable long 4kx512 left/ right side textures , narrow top like 64x4k both set to be tilable only in U and unique start /end parts matching certain area on side of left/ right/top repeating sides for seamless appearance.
If set UDIM style Painter wants everything in perfectly square factor and does ugly /blurry stretching . my guess even brush dab stretching probably. Not sure what genius decided we would be using only square textures and perfectly same texel density everywhere. Not in macro layers for sure.
Blender can paint across different materials with different texel density on top of base/macro layers setup. with quite nice brushes but it's an ancient , one channel only way never been upgraded since v2 and setup nightmare to bake and export . I wonder what are alternatives? If any?
ps And I would love some vector style non-destuctive brushes, post stroke editable to paint tire tracks , stripe like details across tilable and unique parts .
Blender can paint across different materials with different texel density on top of base/macro layers setup. with quite nice brushes but it's an ancient , one channel only way never been upgraded since v2 and setup nightmare to bake and export . I wonder what are alternatives? If any?
The ucupaint add-on lets you paint across multiple channels in Blender and also makes baking less of a pain. It simply creates all node setups necessary to mask and mix things under the hood and organizes textures and color fills in a layers-style panel, with quick access to baking per layer, channel or everything without having to use Blender's contrived native workflow. You can paint across different materials if you setup the layers to use the same images. No help in exporting though, and all other annoying quirks of the texture painting system remain.
Thanks Celosia. I assume you still only can paint on a single image target only? So each brush stroke goes to only albedo , or only bump , or only roughness channel and using silent stroke recording to paint on other images as well has a same issue Photoshop has when it records strokes but dosen't record brush dab spacing and jitter? Also I assume it works on a single material or can create a synced layers/ node setup on multi materials ?
Wonder why nobody has modified Blender painting part yet with multi channel G buffer. As far as I heard modern videcards support up to 8 rgba imags. Something requiring C++ codding my guess . Chat GPT happily suggested me to do so but my experience with it tells me it would a nightmare.
As far as I know it's not possible to paint multiple images at once. It seems to be a limitation of Blender, and while I found a couple of very old add-ons that seem to have been maybe able to paint across images they fell out of support a long time ago so I can't even confirm if whether someone found a way or not. The ucupaint dev is very responsive; if it's possible, requesting it would be worth a shot.
The best but still contrived and limited workaround for ucu today is to treat images as instances. You can have as many layers using the same images as you wish, making it possible to create things like a roughness group using an image you're also using for the color channel but with different masks and adjustments, added and subtracted to other images inside the group, etc.
Overhauling the painting system is in Blender's roadmap. The bad news for anyone looking forward it is that it seems sculpting will be done first, and there's a lot to fix on this side, so unless a dev with love for texturing adopts the painting system it'll probably be years before they get to painting.
Good luck finding something that does it all! I don't think you'll find it, but I wish you well.
Not adding much to the thread sry, though wanted to mention this, in-case someone behind the scene actually did or does this. (pst, pm me. )
Wouldn't that be the thing, in my naivety (or just not being very informed) i thought a coder C++ (+) person could "reverse engineer things (being illegal sure but for production purposes amazing and very helpful) could "extract" codes for functions of each application and make their own "viewport/engine", using all the best of all the applications. thanks celosia, by posting that link i remembered i should get a krita update.
On topic: i tried to udim i think once, might have to force myself eventually, guess i'd need a video or updated how to udim, wiki maybe?
that's not really how it works - what you're suggesting is more difficult than implementing it from scratch and is expressly forbidden by the EULA in most cases.
gnoop isn't asking for anything particularly difficult or new here, the problems have all been solved and solutions are well understood. it's just the case that nobody identified this as a featureset they should build. I'm 99% sure someone said 'giv UDIM support, everyone wants', walked off and left programmers to make UDIM support
This is usually what you get when you listen to marketing/artists without questioning the motivation behind their requests and identifying what it is they actually want from a feature.
Replies
The only thing you lose is different shaders in your painting app.
You can set painter up to export with specific naming templates for each tile etc so you aren't stuck with the default UDIM naming
We're doing this at work currently and it's working a lot better than using separate texturesets
The best but still contrived and limited workaround for ucu today is to treat images as instances. You can have as many layers using the same images as you wish, making it possible to create things like a roughness group using an image you're also using for the color channel but with different masks and adjustments, added and subtracted to other images inside the group, etc.
Overhauling the painting system is in Blender's roadmap. The bad news for anyone looking forward it is that it seems sculpting will be done first, and there's a lot to fix on this side, so unless a dev with love for texturing adopts the painting system it'll probably be years before they get to painting.
gnoop isn't asking for anything particularly difficult or new here, the problems have all been solved and solutions are well understood. it's just the case that nobody identified this as a featureset they should build. I'm 99% sure someone said 'giv UDIM support, everyone wants', walked off and left programmers to make UDIM support
This is usually what you get when you listen to marketing/artists without questioning the motivation behind their requests and identifying what it is they actually want from a feature.