How to import edited mesh with same UV without breaking textures

[Kayla22495955g58d]

So- I am trying to transfer a texture to another version of the same mesh. The UV map is EXACTLY the same, no edits or anything, it is only the mesh's shape that has been changed... yet, no matter what I do- whether it's importing the other mesh version into the same Substance file, or trying to use a smartmaterial in a new file, the texture ends up completely warped and incorrect.

I need a way to get the textures to match up TO THE UV, not the mesh, because the brush strokes no longer match the same way on the mesh because it has been edited... but since the UV is the same, the textures SHOULD be able to apply to the mesh just fine. Yet for some reason, it always seems to go off of the 3D object instead of the UV when applying the textures. How do I fix this??

[Manolis Poniris]

Hello,

From what I understand you have gone back and changed your model and want the textures you already made to apply to the new model? 

What you have to do is go to edit > Project Configuration > File and select your new model, make sure preserve brush strokes is checked, then bake your mesh maps and you should be done.

If you need any help feel free to ask.

Manolis

[Kayla22495955g58d]

Yes, I want the textures already made to apply to the new, edited model without the textures breaking because the projection is now inaccurate. I want it to apply textures based on the UV, not the mesh's shape.

For example, say I have a general canine model fully textured... it looks like a wolf. I edit the model into a fox, with different proportions, but the same UV. I want to be able to import that new model, or transfer the textures, without the textures breaking due to the new proportions.

From prior experience, it makes no difference whether "preserve brush strokes" is checked or not, the texture always breaks due to trying to re-project onto the 3D model instead of just matching to the UV like it should.

[Kayla22495955g58d]

Also, the advice you gave actually doesn't work at all period for this file... it just says "file import failed, reverting to previous version" and nothing changes.

[Manolis Poniris]

Sorry to hear that didnt work.

Is there any chance you could send over your substance painter save and both models?

[João21873047xqkk]

This has been happening with me as well.

I'm trying to swap the mesh with a more updated one and the little details are broken on the model when I do so. It doesn't give me any warning or error when I import the new mesh, painting just gets messed on some parts (especially the eye/face)

[Manolis Poniris]

Can you send the files over?

Also did you uncheck "auto unwrap UV" 

[Roman69]

THANK YOU! Really helped me a lot! god bless you!

[Brad288522106zw0]

Yeah I'm having the same issue, ( I'm trying to make a damaged version of a completed ship model) I get the same error.

SSame U"V mesh parts cut away. it won't import it like it used to in a few versions ago. I've tried both turning off auto UV and the preserve Brush strokes. nothing reverts back to previous model.

[Cyril Dellenbach]

Hello Kayla, hi everyone,

I can see there is some confusion about the UV reprojection option in Substance 3D Painter.

First of all (to answer you @Kayla22495955g58d), this is unfortunately not possible to reapplied the layers on a reimported mesh based solely on the UVs. To make it simple, Substance 3D Painter currently works by "saving" the brush strokes with the 3D view, and when reimporting a mesh it simply reapplies all the strokes according to the 3D view. It wouldn't be as easy as it seems to make the reimport option works with the UV view, because it would create conflicts with other features.

If you want to keep your textures according to the UVs, you can still export your textures and reimport it in a new project, but this workaround has obviously many flaws.

For the other issues you may encounter when reimporting a mesh, you can always check our documentation, but I would advise you to make sure the units of the mesh stay the same.

If you want to return to a previous model @Brad288522106zw0, you should check your autosaves.

I hope this might help with further projects.

Best regards,

[Brad288522106zw0]

Hi Cyril,
I just wanted to clarify, that the mesh and the uv's we;re from an already
finished model, to make a damaged or destroyed version of the model. So I
removed and edited the mesh parts of the model but didn't disturb the uv's.
maybe this might help to understand the issue a little better.
Thanks
Brad

--
Brad Garneau

Sr Game Artist
bgarneau@hitfactor.com
www.hitfactor.com
4231 Balboa Ave, PMB 3024, San Diego, CA 92117

[33185637m3ao]

I have seen many people post this issue on the community forum and still to this day it hasn't been solved.. I know the software is based on projection what you did in the 3D viewport, if the mesh changes the shape, it will all be messed up. But why make it work if you painted on the 2D view/UV map? Couldn't you just add a feature that when you paint in the 3d viewport, also be painted on the UV map? It's so hard to paint in the 2d mode, but right now, it is the only option to not get texture messed up when updating a new mesh with new shape but the same UV and poly count. We really need an update to this as other software can let you update the mesh with different shapes and the texture would be in the right location for the new mesh.

[Cyril Dellenbach]

As answered on your thread,

Most of the softwares rely on UVs to reproject the textures; we don't. The downside of this workflow is what you mentioned, changing the mesh will alter the textures in most cases.

On the other hand, when the mesh hasn't change, it also allows to reproject the textures without a single variation, even if the UVs are nothing alike.

Working in the 2D view is the only situation where the reprojection will work with a different mesh, because the 2D view and the 3D view are two different spaces. When painting on the 3D view, Painter will save the strokes and the camera position, but not UV coordinates. Same goes with the 2D view, it will save the UV coordinates, not the strokes and camera.

I know it sounds like both could share the info, but this isn't as easy as it seems.

Therefore, there's nothing to solve, because there's no bug or issue, this is simply the reprojection behavior. With that being said, I definitely agree the current situation isn't the best, we don't recommend using an iteration workflow with Painter, and we're exploring solutions, but nothing to share for now.

Here's an interesting thread on the subject.

Best regards,

[Strain33201825eldh]

This is a pretty awful experience, honestly. There is an issue here even if you don't consider it a 'bug'.
You even explain a workaround here:

> If you want to keep your textures according to the UVs, you can still export your textures and reimport it in a new project, but this workaround has obviously many flaws.

Yes, it has flaws but it's better than nothing. Why suggest that users export and re-import dozens of textures (terribly tedious! And not exactly elegant in substance) when you could automate it?

[Cyril Dellenbach]

Hello @Strain33201825eldh,

You are right,  this a tedious workflow, that I personally wouldn't use. Now, this isn't currently possible in Substance 3D Painter, and an elegant solution would demand a lot of time and research which we are currently doing. Therefore, I rather give a workaround, as tedious as it is, rather than not at all.

As mentioned in my previous message, we don't recommend following an intensive iteration workflow with Substance 3D Painter if you're not very clear with the limits of the reprojection feature. The reprojection is currently made for little oversights (e.g. you suddently want to add a hat to your character), or updating your UVs (which I do all the time).

This isn't a bug, or an issue because the reprojection behavior is the proper one, it is as described in the documentation (could be better explained thought), and it is the same as when it was built. However, I agree there's a strong demand for a rework of the feature, and we're working on solutions.

Best regards,

[Strain33201825eldh]

I am not going to argue semantics with you. If you have a feature in your
product that makes it a worse experience, if you have multiple users
complaining about how it makes your product more difficult to use and
justify it for their needs, if you're tracking it internally in a jira or a
similar system and intend to change the behavior some day, then I call it
an 'issue'. You can call it whatever you want.

Linking documentation on the behavior doesn't make the behavior less
problematic (though obviously it's good that it's documented and explained
so thank you). And recommending that your users don't use an extensively
iterative workflow is a complete nonstarter: your users are creators,
they're creative people often working at companies with an inherently
iterative process of development and revision. Telling your users not to
use an extensively iterative workflow is like asking mathematicians to just
do the right proof on their first try. It isn't reasonable and I think you
should drop that line of justification entirely.

Implementing something that automates the very tedious process you
mentioned as a workaround would be actually useful. If you can't give us an
option to select seamless UV reprojection for work done in the 3D view,
either because it's impossible or the code makes it too difficult, at least
give us an option to export a new project where every layer is replaced
with its 2D texture equivalent. Or export a bunch of UV mapped pngs, one
per layer to a folder so we can use that. Really, do anything to just make
the workaround leas incredibly tedious.

[Cyril Dellenbach]

Sorry if it sounded like I wanted to argue about the word "issue". I emphasized on this because I wanted to be clear that there's nothing to fix. The feature currently works as intended and was presented as such. Therefore, it is not prioritized the same way as a bug. 

Substance 3D Painter has strict limitations regarding the reprojection, which isn't a secret. I don't want people to based their projects on iterations, without being well aware of the software limitations. 

Another workaround to prevent reimporting your maps would simply be to make a Smart Material out of the entire Layer Stack and apply it on your newly imported model.

Thanks for the feedback.

[Strain33201825eldh]

I've used a smart material approach to this situation before and it actually doesn't solve this problem. For example, parts of a mask that were hand painted in the 3D view still reproject incorrectly onto a changed mesh, so you might as well just re-import the FBX. It serves as a way to package things up but it doesn't help with the 'same UVs, different shape in the FBX' problem.

> Substance 3D Painter has strict limitations regarding the reprojection, which isn't a secret. I don't want people to based their projects on iterations, without being well aware of the software limitations. 

To be candid, projects are necessarily iterative in development. These limitations are not a secret insofar as they're documented in the links you've provided. But I'm not convinced it's something folks are well aware of, unfortunately. Not only is it a somewhat complicated thing to explain, we see it show up over and over: you have linked this good breakdown from 2021 from someone explaining why they no longer find Substance fits their needs: https://community.adobe.com/t5/substance-3d-painter-discussions/painter-option-to-record-3d-painted-... and this thread is over a year old. People are continually surprised by this. I very much appreciate the honesty in these responses but I think 'Substance doesn't have a good solution if you want to adjust the shape of your model and continue to update your textures' would give a lot of folks pause before clicking 'buy' if they saw it in a features list.

What I don't understand here is if folks are bringing this up repeatedly as a problem and we agree that it makes Substance a worse fit for an iterative workflow, and an imperfect but suitable workaround exists that could be automated, why isn't at least an implementation of a workaround on the product roadmap? "We'd like to explore some solutions but don't have anything planned in the near future" is essentially a polite phrasing of "never". Do I just vastly overestimate the extent of how many people encounter this problem?

[33185637m3ao]

Hi Cyril, I have tried the method you mentioned above, the smart material, but unfortunately, it doesn't work, for example, if I made the hat less tall or changed any shape of it, the texture would reproject differently even if it's a smart material. 

[Strain33201825eldh]

Any chance we could see a fix or workaround for this on the 2024 roadmap? Especially since the suggested 'smart material' approach doesn't actually work.

[Cyril Dellenbach]

I should have specify that the "Smart Material" workflow will indeed not work for non "procedural" parts of the Layer Stack. With that being said for all the Layers using Mesh Maps (smart mat, smart masks, etc.) or for simple materials, the result should be pretty close from the initial result.

Regarding a rework of the reprojection feature, I can't give (don't have) any info or ETA to share. 

Regards,

[derekw84996922]

Are there any plans to implement additional API capabilities, so that the userbase can write its own solution to this issue? I don't think anyone is particularly picky about how this is solved, as long as the users can avoid redoing countless hours of work, or exporting/reimporting every mask in a texture set, just because there were modifications to the mesh. 

I understand that the official vision for SP doesn't prioritize iterative-based workflows, but the industry requires it, and is using it that way. I have personally spent dozens of hours exporting/reimporting/plugging in masks, when a simple script could have done the same job in seconds. It may currently be working "as intended," but it's unacceptable.