Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - pacsuta.david

Pages: 1 [2]
Hi Froyok,

thanks for your continued support.

Isolating the channels produces the same colours in the 2d view. Something I wanted to mention is that I baked the base normal map in Substance Designer 5 which looks fine (see attached). I would assume that the strange colours are added somewhere in the normal detailing process within Substance Painter. One thing I cannot remember unfortunately is if I originally started texturing this prop in SP1 or SP2

Thanks again,

Thanks Froyok but I don't think my issue has anything to do with padding?
Have a look at the same image with my UVs overlaid on top. I'm clearly getting strange orange colours inside my UV islands



I exported my textures from Substance Painter 2.3.1 (also previously tried with 2.1.0) and my normal map has all these strange colours. I have exported normal maps in the past just fine, this is the first time I'm encountering this issue. Can you please explain what is causing this?


Substance PainterSubstance Painter - Discussions - Re: Re-merge Texture Sets?
 on: February 01, 2016, 05:54:29 pm 
Jumping on the bandwagon for this feature request, please implement <3 Need to murrrge all doze texture setts

Hey Fabian,

thanks for the reply. Unfortunately it turned out that my model had terrible topo for baking and the way I rebuilt it, it was no longer feasible to overlap the UVs. So right now I cannot confirm if your assumption was correct:) but if I ever come across a similar situation I'll be sure to share my findings in this post

Hey everyone, I hope someone can help:)

So I know that when baking a normal map your cage must have the same UV layout that your lowpoly.
I also know that when you bake a normal map, you cannot have any overlapping UVs in your lowpoly because the bakes get added on top of each other.

My question is: Do I have to move overlapping UVs outside the 0-1 UV range for the Cage mesh as well? Or do I keep the Cage UVs overlapping?

Thanks a lot in advance!:)

Hey I tried to see if I could find anything for you in Google but not much luck.
Is your model going to be used in such a high resolution that you require separate UV maps?

By the way your model does not have to be 1 single mesh to be in the same unwrap. You can have multiple objects that each take up different space in your UV layout. For the moment that would be a workaround but hey, with my comment you are back in the front page of the subforum so maybe you'll get a better answer this time around:)

Thanks Froyok, what I actually did is that I moved the high-poly plane just slightly away from the low-poly (maybe there was some z-fighting going on during baking because they were just 2 planes in the exact same position?) and I also found that my high-poly had some loose verts. I didn't use any ray-cast distance because it was a caged workflow - anyway I rebaked the whole thing and everything is rendering correctly now. There was no need to extend the gap between the faces.

I never thought a normal map could completely flip a face. This was an interesting learning experience for me.

Sorry to give you all the trouble when the issue wasn't even with Painter in the first place.
Thanks again for your help and kudos to all of you at Allegorithmic for your work.

Edit: Oh and compared to the newly baked normal map, the errors quickly become obvious in the previous one!:)

Hi Fabian, Froyok,

thank you for your answers.

Because it's a uni assignment, target engine is just Marmoset. So I brought the model and textures into Marmoset and I have the same issue there.
So clearly there must be something wrong with my textures and there you go, the problem only occurs with the normal map applied. I added two more images from Painter - one with the normal map (obvious transparency) and one without the normal map (faces show up correctly - opaque).

I'm going to try to see if there's anything I can fix about my cage or the high poly and then rebake but that takes some time so in the meantime I was wondering:
Would it solve the problem if I flipped one of the channels in the problematic areas of the normal map? Do you guys have any other suggestions?

Thank you for your continued support!

Hi everyone,

I have a problem with my phone box model that I'm texturing. It seems that the faces of my mesh that make up the window panes are flipped.
If you look at the attached image, you can see that the windows appear to be see through and that 2 areas with the same material facing in the same direction produce different shading. For the modeling I used Blender and I made sure that every normal is facing in the right direction. Heck, because it did not work with the properly set up normals I even tried flipping the problematic faces to see what happens but I got the same result. Which is extremely strange because how can these faces only ever look in one direction regardless of the normals I set up during modeling, right?

Each window is made up of 2 large faces, intersecting with the window frame, one of the faces facing outward and the other one facing inward.
Is it possible that the problem is caused by the fact that these face pairs as too close to each other and they cannot be displayed correctly?

I also attached the .fbx, hopefully you can help.

Many thanks in advance!! :)

Thanks Froyok!! It worked ;D

Hello everyone,

so far I am loving Designer and Painter and it's been a blast working with the package.

For the first time I bumped into an issue. I baked a High -> Low normal map using a cage in Designer in DirectX space.
Looking at the mesh in SD with normal map applied it looks perfectly fine; Painter on the other hand produces all sorts of artifacts.
I made sure that I import the normal map in the right tangent space and I also downloaded Painter's latest version to no avail.
I added an image both from Designer and Painter.

Any advice?

Edit: Added the fbx and normal map as well. Thank you for having a look at this!

Pages: 1 [2]