Option to record 3D Painted strokes in UV space and not in world space or auto transfer 3D paint via UV space when the new model is imported
In production the model changes after feedback. The textures need to be updated still. When I import the new model change into Substance Painter, the 3D paint strokes are reprojected at the previous locations of the old model and end up not lining up with the new model change. This breaks any kind of use in production.
SP is built assuming there are no model changes, which is not production friendly. Model changes are common.
We should have the option to set projects to not record brush strokes in 3D space.
Looks like when I paint in the 2D UV window, the re-projection is ignored and the paint there applies correctly to the new imported model. This should be the same behavior with 3D painted strokes also.
SP is currently biased towards a workflow that assumes that the model always stays the same and that only the UVs change. This is the case less than half the times when we import a new model. Most of the time it's actually a model change that warrants the textures being updated. SP needs to be open to allowing both workflows. Let us choose to not have 3D brush strokes recorded in UV space so that texturing work can be reused when the model changes.
I am leaving Substance Painter in the meantime in favor of Mari because of this very reason. In Mari I can import multiple mesh versions and the paint is never re-projected. It's always saved in UV space. If I wanted to transfer work into the same model but it has different UVs, I have options in Mari to transfer entire channels via baking in world space. It's more production friendly.
I hope you guys look into this and take it seriously. I saw this "soft declined" in a previous post. It's crucial for production to get this fixed.
If you do a survey of users you will find that when the model changes in SP, they often export the painted color or painted masks from the old model as texture files and reimport the texture files and reapply them to the proper place in the layer stack and apply the mask data to all the fill layers one at a time after the model changes.
This should be a process that SP does automatically at least. If you are unable to change the underlying architecture of the software to prevent storing 3D strokes in world space, at least consider this. Create a way to automatically transfer all painted color or painted mask data across differently shaped models via same UV space. This saves all work painted in 3D and uses UV space to preserve it after the model change is imported.

-
ireneus brewka commented
You could make it a new layerType (UV-Paintlayer). So if you want to have the strokes in 3d-Space you could still use the existing paintLayer. But i know i never ever had one single instance where i needed that :/ and on a regular basis my model change at least a bit, and your assumed workflow ruins a lot of fun i could have otherwise have with this app :/.
Please listen to us :).
It wouldn't hurt you to add this type. And not only would it save us from the frustration to export and reimport all those layers again, tho i made a script for that that aides me in that torture, but it can't be fully automated.
It would even speed up project loading times as well, as all those strokes don't need to be reconstructed on load.
Thanks :) -
lx h 0 commented
This is really important, or can add a warp projection function in the 2d view to solve this problem.
-
SethMeshko commented
YES! 100% I don't even understand why strokes would be in a 3D space. Particularly in the case of paint layers and masks, doesn't it make sense that they would simply be 2D bitmap layers?
-
toonafish commented
Yes please, I had to redo stuff so many times after a model has been changed because of this.
-
RedstarDEV commented
This is indeed absolutely essential and would save a lot of time in the pipeline.
-
itinfo@playstudios.com commented
Voted! This is really an essential aspect of production and there has been times where there is model change multiple times and we would run into this very issue time and again.