Problem With Bump Mapping (Decal Baking)

[ludo_si]

Hello,

 

I tried to put a bump mapping with bake texture to work in 3dpainter.

And I also tried using a projection, with the projection, it is correct.

you can see that if I use the bake, bump mapping is not correct rendering.

 

we see al the coat of the patch with bake texture.

Bake is for me very great to work with complex texture.

 

And if i use normal map the problem is greater

[Fuchur]

Hello,

 

I tried to put a bump mapping with bake texture to work in 3dpainter.

And I also tried using a projection, with the projection, it is correct.

you can see that if I use the bake, bump mapping is not correct rendering.

 

we see al the coat of the patch with bake texture.

Bake is for me very great to work with complex texture.

 

And if i use normal map the problem is greater

 

I am quite sure they are, but Normals are facing the right direction, right?

 

See you

*Fuchur*

[ludo_si]

Yes, absolutely. They all are in the same direction, towards outside. One can even note that gives the impression which the percentage of the bump is different for each patch.

 

And with normal map, it is unusable. All this problem come from bake texture.

[robcat2075]

Good looking bump map!

 

What happens if you change the map to "displacement"?

[ludo_si]

Good looking bump map!

 

What happens if you change the map to "displacement"?

The Appearance is better than the bump, it is certain.

[robcat2075]

Why is baking with tiles better than a continuous decal?

[ludo_si]

Why is baking with tiles better than a continuous decal?

It's very important. With this you can use al software painting and sculpting. Because uv is not a problem, you can use paint per pixel in 3dcoat, 3d painter, and why not blender to do sclupt.

But baking and rendering should be correct. With thi we can work with all texture software.

[ludo_si]

Here a sample of all type of bump in AM.

 

There is the problème with all type of bump.

And normal map don't know the direction of the normal. it is always different for every patch.

Displacement mapping is not correct too with the rendering.

 

This simple sphère si baked.

[ludo_si]

Here is a file with a .prj

sph_reprobbump.zip

[ludo_si]

In this image, you can see that the problem is only with 5 point patch.

Hook, 3 point patch and 4 point patch are alway correct.

[robcat2075]

In this image, you can see that the problem is only with 5 point patch.

 

I'm looking at your sample case. The problem seems to be on 5-point patches but not on all of the 5-point patch. It looks like part of the patch works right and part does not?

 

I wonder if it's possible that one of the sub-patches that A:M creates to fill in 5-point patches has its normal reversed?

[ludo_si]

In this image, you can see that the problem is only with 5 point patch.

 

I'm looking at your sample case. The problem seems to be on 5-point patches but not on all of the 5-point patch. It looks like part of the patch works right and part does not?

 

I wonder if it's possible that one of the sub-patches that A:M creates to fill in 5-point patches has its normal reversed?

Each side of the patch is divided into two. They meet in the middle. This creates 5 pieces in the patch. And the pieces do not always have the same direction of normal. It is a problem with the subdivision of the 5 point patch

[robcat2075]

In this image, you can see that the problem is only with 5 point patch.

 

I'm looking at your sample case. The problem seems to be on 5-point patches but not on all of the 5-point patch. It looks like part of the patch works right and part does not?

 

I wonder if it's possible that one of the sub-patches that A:M creates to fill in 5-point patches has its normal reversed?

Each side of the patch is divided into two. They meet in the middle. This creates 5 pieces in the patch. And the pieces do not always have the same direction of normal. It is a problem with the subdivision of the 5 point patch

 

I think that could be fixed, we just need to make a really clear example case for Steffen to look at.

[Rodney]

Something (actually some things) are definitely out of whack here.

 

I note in the little time that I had to test that some mild distortion around the added circle itself was corrected by changing the in and out bias from 100% to 166%. That really doesn't do anything with the decal images and their apparent inverted-ness however.

 

There is one aspect of this that I'd like to know more about and it is this:

 

Is there any chance that the initial decal was applied onto the model when the normals were facing in other ways than what they are in these test models. In other words, were any normals changed after the decal was applied to correct them?

 

I'm trying to rule out that variable as well as understand how the normals effect the application of the decal itself when it is originally applied. My assumption is that it shouldn't matter as flipping the normal should flip the image applied to that location but there is something nagging at the back of my head regarding why the decal doesn't seem to flip orientation even when the normal itself is flipped. This seems to indicate a flawed decal image and not a flawed model... which is impossible because the test model we are looking at has all of its normals facing out. My pea sized brain is just trying to understand why the decal seems to be flawed and yet the model doesn't. I suppose the easiest way to test this would be to supply a different image (perhaps completely the same color) in place of the one currently applied and review the results. If the decal might have been applied to a model with normals incorrectly aligned perhaps another test would be to reapply the decal again knowing that the normals are all facing the right way.

 

Another question to reduce the variables we are looking at would be to make sure we understand where the decal was initially applied: In A:M, in 3DPainter or in some other place. This is important in knowing if the fix needs to be applied to A:M or some other place.

 

 

P.S. Thanks for sharing the Project File as that helped in understanding what the problem is a great deal.

[ludo_si]

In this image, it's more easy to undertand the problem of de direction of the normal with the 5.patch

bouclier.zip

[ludo_si]

In this image, it's more easy to undertand the problem of de direction of the normal with the 5.patch

The model is without probleme if i don't use bake decals. here it is the same model but with a projection of the texture.

boublier2.zip

[Rodney]

So something in the baking process is creating inverted areas on the decal?

 

You mention projection so... I assume you are baking in A:M but then painting in 3DPaint.

 

Could you apply a standard cylindrical decal and then project paint in 3DPaint?

[ludo_si]

There is really a problem with the bump mapping.

here, I test with a texture projection without using bake texture and one notes that rendering is bad.

bumpprob.zip

[robcat2075]

In this simple example the problem shows up in Progressive render but not Final render

 

[ludo_si]

In this simple example the problem shows up in Progressive render but not Final render

 

 

yes but is the example flat?

 

Here is two example with the same problem. always the bump have a bad rendering.

The orange model have a cylindric decal.

 

The rendering is final.

 

I have always the problem in the final rendering.

cylindric.zip

[ludo_si]

Here is an example with normal map.

It's the same but more visible

And the texture is simple, the model too

 

All the methode to get bump have the same problem.

Bump, legacy bump and normal map.

none works perfectly and even less with a bake texture

[robcat2075]

Now I've added the complication of baking the decal. Would you say this shows the same problem you have?

 

The left models have the map applied as a regular decal, the right models have it baked.

the top models have it set to Color and the bottom models have it set to Bump.

 

 

BakedBumpTest.zip

[Rodney]

Hmmmm....

 

That looks to me more like a seam issue than one concerning normals as the oddness is directly over the splines.

[robcat2075]

A spline is an infinitely thin area but the reversal of the lighting happens over real area so it's got to be something happening on the patch.

[Malo]

Hi everyone.

By doing some testing I realized that the phenomenon seems to be found on other patches :

 

 

[ludo_si]

A spline is an infinitely thin area but the reversal of the lighting happens over real area so it's got to be something happening on the patch.

this is a real problem as it appears on almost everything I did today.

With regular decals and bake too.

Same displacement mapping have the problem with the rendering.

[Rodney]

A spline is an infinitely thin area but the reversal of the lighting happens over real area so it's got to be something happening on the patch.

 

Yes, but I'm just noting that the difference between what is rightly and wrongly bumped doesn't conform to the area of the patches themselves. That is particularly odd. It would make a lot more sense to me (normal wise) if it did. Where the patches overlap.. those seams... appears to be involved in this.

 

We may be seeing two issues here:

Baking is reversing the surface...

Except where some specific splines (creating overlapping decal seams) exist.

 

If it baking reversed everything then a workaround (and something that would lead to the ultimate fix) would be to simply invert the bump of whole image.

[ludo_si]

Thanks for your help. we can see that rendering with bump mapping is unusable.

[robcat2075]

The problem with those gifs is it all flickers by so fast we can't really study it.

[Rodney]

Thanks for your help. we can see that rendering with bump mapping is unusable.

 

Well, that's an oversimplification (i.e. not the case in all instances) but we have closed in on a significant problem area.

Some of the test meshes shown here have geometry that can be avoided altogether (i.e. unnecessary 3 and 5 point patches) and if avoided would produce accurate bump maps.

[robcat2075]

I recommend you make up a simple test case that clearly shows the problem and submit that to AMreports.

 

Bump mapping seems to work great , but not with baked maps.

[ludo_si]

Hi everyone.

By doing some testing I realized that the phenomenon seems to be found on other patches :

 

 

Hello, je suis dessus depuis plusieurs jours. Il y a vraiment un problème avec le rendu des bump.

J'ai absolument tout essayé pour ce qui est de la méthode de projection d'image.

qu'en penses tu?

[Rodney]

When filing a report you could link this topic and/or include this discussion (see attachment):

Problems_with_Baked_Decals.pdf

[ludo_si]

I recommend you make up a simple test case that clearly shows the problem and submit that to AMreports.

 

Bump mapping seems to work great , but not with baked maps.

I don't think that it's an oversimplification.

Patches 5 sides, I often and it is not easy to avoid. more Malo has shown that the problem may be on patch 4 points. and not only bake textures.

But you're right, we must talk to bugreport

 

When filing a report you could link this topic and/or include this discussion (see attachment):

yest thanks

[Malo]

Robcat, I modified the rapidity ... do not hesitate to say if it is too fast.

 

Ludo, je ne sais pas à quoi c'est du. C'est une piste à creuser.

[robcat2075]

I've started an AMReport: [bug]6246[/bug] Baked Bump Maps do not shade properly

[jakerupert]

Why is baking with tiles better than a continuous decal?

It's very important. With this you can use al software painting and sculpting. Because uv is not a problem, you can use paint per pixel in 3dcoat, 3d painter, and why not blender to do sclupt.

But baking and rendering should be correct. With thi we can work with all texture software.

 

That would open up great possibilities indeed!

Seems your many researches could lead to some practical use finally.

 

How about the hooks then.

Is it the same like with fivepointers?

[ludo_si]

Why is baking with tiles better than a continuous decal?

It's very important. With this you can use al software painting and sculpting. Because uv is not a problem, you can use paint per pixel in 3dcoat, 3d painter, and why not blender to do sclupt.

But baking and rendering should be correct. With thi we can work with all texture software.

 

That would open up great possibilities indeed!

Seems your many researches could lead to some practical use finally.

 

How about the hooks then.

Is it the same like with fivepointers?

It is important. Yes, this yourself and it would be possible to use all the softs sculptures because uv are more no problem. I already did the test and it works very well provided you have a very good rendering for the bump.

It work perfectly with color etc. I can do a example

[ludo_si]

Why is baking with tiles better than a continuous decal?

It's very important. With this you can use al software painting and sculpting. Because uv is not a problem, you can use paint per pixel in 3dcoat, 3d painter, and why not blender to do sclupt.

But baking and rendering should be correct. With thi we can work with all texture software.

 

That would open up great possibilities indeed!

Seems your many researches could lead to some practical use finally.

 

How about the hooks then.

Is it the same like with fivepointers?

Sometimes and on some 4 point tatch. Often near a 5 point patch

[Malo]

Just for information, these problem is not specific to baking.

My tests were only used as projection map in AM.

 

I have not managed to reproduce the bug in version 8.5

When importing a model(v8.5) in V.13, the "bump" map is converted to "bump legacy". What is the differences between this two "bump"?

 

 

the problem is also in the hooks.

[robcat2075]

When importing a model(v8.5) in V.13, the "bump" map is converted to "bump legacy". What is the differences between this two "bump"?

 

"Bump legacy" is what "bump" was before displacement mapping was introduced. Current "bump" is the same shading strategy that displacement mapping uses to shade its surfaces.

[Malo]

Robcat thank you for the explanation.

[ludo_si]

Robcat thank you for the explanation.

Thanks. I hope there is absolution for this bug