cycles bake NormalMap problem #42015

New Issue

trew trew · 2014-09-29T20:45:24+02:00

trew trew commented

2014-09-29 20:45:24 +02:00

System Information
linux
gtx 560ti

Blender Version
Broken: ( 2.72 date 2014/09/29), see splash screen
Worked: (optional)

Short description of error
blender baking the normal map but not good.

Exact steps for others to reproduce the error
cube >> add multires (level 6) and displace modifiers >> add same object for boolean >> make tex and bake it.

cycles_bake_error.blend

when i apply the modifiers i get this result, That is still wrong.

**System Information** linux gtx 560ti **Blender Version** Broken: ( 2.72 date 2014/09/29), see splash screen Worked: (optional) **Short description of error** blender baking the normal map but not good. **Exact steps for others to reproduce the error** cube >> add multires (level 6) and displace modifiers >> add same object for boolean >> make tex and bake it. ![cycles_bake_problem1.jpg](https://archive.blender.org/developer/F113611/cycles_bake_problem1.jpg) [cycles_bake_error.blend](https://archive.blender.org/developer/F113613/cycles_bake_error.blend) ![cycles_bake_problem.jpg](https://archive.blender.org/developer/F113614/cycles_bake_problem.jpg) when i apply the modifiers i get this result, That is still wrong. ![cycles_bake_problem_after_apply_modifiers.jpg](https://archive.blender.org/developer/F113617/cycles_bake_problem_after_apply_modifiers.jpg)

trew trew commented

2014-09-29 20:45:24 +02:00

Changed status to: 'Open'

Dalai Felinto was assigned by trew trew

2014-09-29 20:45:24 +02:00

trew trew commented

2014-09-29 20:45:24 +02:00

Added subscriber: @b_d

Dalai Felinto commented

2014-09-30 01:01:18 +02:00

The attached file doesn't reproduce the problem, I get a fine bake from it (just open the file and press bake). Do I need to change anything in the file to reproduce the problem?

trew trew commented

2014-09-30 11:32:25 +02:00

no

Ray molenkamp commented

2014-10-04 07:44:24 +02:00

Added subscriber: @LazyDodo

Ray molenkamp commented

2014-10-04 07:44:24 +02:00

I can reproduce on both cpu and gpu, it doesn't seem isolated to normal maps, all bake types seem affected by this.

The boolean operation seems to mess things up

The sample file has the following modifiers applied

1 Multires
2 Displacement
3 Boolean

When you switch the order of the boolean and the displacement the issues go away

I can reproduce on both cpu and gpu, it doesn't seem isolated to normal maps, all bake types seem affected by this. The boolean operation seems to mess things up The sample file has the following modifiers applied 1 Multires 2 Displacement 3 Boolean When you switch the order of the boolean and the displacement the issues go away

Vilem Duha commented

2015-03-08 20:11:29 +01:00

Added subscriber: @VilemDuha

Vilem Duha commented

2015-03-08 20:11:29 +01:00

confirmed by me too, I just wanted to report the same bug - boolean on the highpoly object for baking messes up the order of faces somehow...real weird stuff going on!
attaching a file too.bakebug_boolean.blend
open and hit bake to see.

confirmed by me too, I just wanted to report the same bug - boolean on the highpoly object for baking messes up the order of faces somehow...real weird stuff going on! attaching a file too.[bakebug_boolean.blend](https://archive.blender.org/developer/F148033/bakebug_boolean.blend) open and hit bake to see.

Julian Eisel commented

2015-03-09 00:03:31 +01:00

Added subscribers: @dfelinto, @JulianEisel

Julian Eisel commented

2015-03-09 00:03:31 +01:00

Humm, not sure if that's the desired result: :P @dfelinto, do you think you can look into this in the near future?

Humm, not sure if that's the desired result: ![baking_bug.jpg](https://archive.blender.org/developer/F148060/baking_bug.jpg) :P @dfelinto, do you think you can look into this in the near future?

marc dion commented

2015-03-10 11:10:17 +01:00

Added subscriber: @MarcClintDion

marc dion commented

2015-03-10 11:10:17 +01:00

I have two very different results depending on the build I use.

With 2.73a(Official I believe?) the normal map is completely ruined at every point.

With last weeks build(2.73.9, hash:ed5df50 the results are not as bad. The bottom face has concentric ring artifacts which look like those pixels are very low resolution. There is one face that rendered without obvious error.

The remaining faces all have vertical line artifacts and they also look like they are very low resolution. When only looking at the artifacts, it's as if the texture is small like 64x64 pixels(guestimated, not measured :)

I disabled the Displacement modifier leaving only the Multi-res and the Boolean and now the baked map render looks fine but that may be due to the missing Displacement not being there to exaggerate the errors. I feel like the errors are still here but are hidden by poor geometry layout that the Boolean operation tends to cause.

Also, baking using only the Multi-res and Displace works fine so long as the Boolean is omitted.

Applying the Multi-res modifier and then baking results in only the artifacts showing up. Weird? I would have expected this from a bake that doesn't use Selected to Active? I should probably redo this one.

The following is the Boolean baked by itself. There are visible artifacts around the intersection and they appear to be light tearing and not geometry weirdness that one would expect from uneven geometry created by Boolean operations but it's hard to say for sure. I feel like these look like bad UV's and not so much normals which show up from poor geometry layout, ie:no proper boundaries like control loops or inset..

It's seems to be caused by the Boolean Modifier but exaggerated by the previous two modifiers.

Applying the Boolean before the bake results in a clean bake except that the mesh is distorted because the Modifier was Applied down the Stack instead of in order, which is expected.

This does not seem like a problem with the renderer. It looks like the modifier code itself is broken. Maybe it's not passing UV info properly so the baked coordinates are torn across one another so far as the renderer is concerned. Just a guess there, the artifacts don't look like torn UV's to me. Perhaps really high-res torn UV's look like this...

(Possibly related to the repair work Campbell has been doing on Custom Layer doo-hickies???) https://developer.blender.org/T43680 There is another similar patch he posted and this problem may need similar treatment.

I have two very different results depending on the build I use. With 2.73a(Official I believe?) the normal map is completely ruined at every point. ![2.73a.png](https://archive.blender.org/developer/F149467/2.73a.png) With last weeks build(2.73.9, hash:ed5df50 the results are not as bad. The bottom face has concentric ring artifacts which look like those pixels are very low resolution. There is one face that rendered without obvious error. The remaining faces all have vertical line artifacts and they also look like they are very low resolution. When only looking at the artifacts, it's as if the texture is small like 64x64 pixels(guestimated, not measured :) ![2.73.9.png](https://archive.blender.org/developer/F149469/2.73.9.png) I disabled the Displacement modifier leaving only the Multi-res and the Boolean and now the baked map render looks fine but that may be due to the missing Displacement not being there to exaggerate the errors. I feel like the errors are still here but are hidden by poor geometry layout that the Boolean operation tends to cause. ![noDisplace.png](https://archive.blender.org/developer/F149471/noDisplace.png) Also, baking using only the Multi-res and Displace works fine so long as the Boolean is omitted. ![noBoolean.png](https://archive.blender.org/developer/F149474/noBoolean.png) Applying the Multi-res modifier and then baking results in only the artifacts showing up. Weird? I would have expected this from a bake that doesn't use Selected to Active? I should probably redo this one. ![multi-res_applied.png](https://archive.blender.org/developer/F149478/multi-res_applied.png) The following is the Boolean baked by itself. There are visible artifacts around the intersection and they appear to be light tearing and not geometry weirdness that one would expect from uneven geometry created by Boolean operations but it's hard to say for sure. I feel like these look like bad UV's and not so much normals which show up from poor geometry layout, ie:no proper boundaries like control loops or inset.. ![boolean.png](https://archive.blender.org/developer/F149480/boolean.png) It's seems to be caused by the Boolean Modifier but exaggerated by the previous two modifiers. Applying the Boolean before the bake results in a clean bake except that the mesh is distorted because the Modifier was Applied down the Stack instead of in order, which is expected. This does not seem like a problem with the renderer. It looks like the modifier code itself is broken. Maybe it's not passing UV info properly so the baked coordinates are torn across one another so far as the renderer is concerned. Just a guess there, the artifacts don't look like torn UV's to me. Perhaps really high-res torn UV's look like this... ![booleanApplied.png](https://archive.blender.org/developer/F149483/booleanApplied.png) (Possibly related to the repair work Campbell has been doing on Custom Layer doo-hickies???) https://developer.blender.org/T43680 There is another similar patch he posted and this problem may need similar treatment.

Julian Eisel commented

2015-04-14 22:09:45 +02:00

@dfelinto, any chance you can look into this now after Multiview is merged?

Vilem Duha commented

2015-04-22 16:16:39 +02:00

Actually not sure If this was clear - this bug should be renamed, it simply messes up order of faces not only for normalmap baking, but also for combined and probably others.

Vilem Duha commented

2015-07-03 22:54:29 +02:00

Just to make clear how serious this problem is, I upload a file:
bakebug_boolean.blend

In this file, every time you hit bake, the result will be different - because the order of the faces of the highpoly model gets somehow randomly messed up...

I guess the fix could potentially be simple - it must be some mixed order of the faces being passed to bake...

Just to make clear how serious this problem is, I upload a file: [bakebug_boolean.blend](https://archive.blender.org/developer/F200233/bakebug_boolean.blend) In this file, every time you hit bake, the result will be different - because the order of the faces of the highpoly model gets somehow randomly messed up... I guess the fix could potentially be simple - it must be some mixed order of the faces being passed to bake...

Vilem Duha commented

2015-07-04 00:23:17 +02:00

did some investigation, and I am quite sure that what I wrote was what is happening.

If I can, as a python coder, dare to assume where this happens, what seemed to me weird is that:

at line 496 of bake_api.c -
mesh_calc_tri_tessface gets called to initialize tris, after that mesh gets conversion to CDDM
CDDM is used to build the BVH and all after, however in the end, the indices are somehow used with the original tris_high array?

just something I thought about helplessly staring at the code last few hours...

did some investigation, and I am quite sure that what I wrote was what is happening. If I can, as a python coder, dare to assume where this happens, what seemed to me weird is that: at line 496 of bake_api.c - mesh_calc_tri_tessface gets called to initialize tris, after that mesh gets conversion to CDDM CDDM is used to build the BVH and all after, however in the end, the indices are somehow used with the original tris_high array? just something I thought about helplessly staring at the code last few hours...

Vilem Duha commented

2015-07-07 15:37:16 +02:00

So, new findings after discussion with Dalai :

this bug has to do with boolean modifier, which always outputs a different order of faces (through bmesh).

so the process is - bake api gets CDDM face indices and writes them into the image/pixarray. Then cycles gets another result from boolean, but uses the bake - API delivered indices,

So, new findings after discussion with Dalai : this bug has to do with boolean modifier, which always outputs a different order of faces (through bmesh). so the process is - bake api gets CDDM face indices and writes them into the image/pixarray. Then cycles gets another result from boolean, but uses the bake - API delivered indices,

Dalai Felinto was unassigned by Campbell Barton

2015-07-07 15:51:04 +02:00

Sergey Sharybin was assigned by Campbell Barton

2015-07-07 15:51:04 +02:00

Sergey Sharybin removed their assignment 2015-08-27 12:32:04 +02:00

Dalai Felinto was assigned by Sergey Sharybin

2015-08-27 12:32:04 +02:00

Sergey Sharybin commented

2015-08-27 12:32:04 +02:00

Added subscriber: @Sergey

Sergey Sharybin commented

2015-08-27 12:32:04 +02:00

Not really sure why it was re-assigned to me, this is more like bake api issue.

It's in practice possible that modifier wouldn't have determenistic order of faces and think it is p to the bake api to be robust enough to support this. One of possible ways solving this is to apply modifiers onto the objects copied to a separate Main. This will ensure the same exact data is used by both blender and cycles sides.

Since this is more a design re-consideration it's not strictly a bug, just a limitation of current system. But i'll let @dfelinto to make a final decision here.

Not really sure why it was re-assigned to me, this is more like bake api issue. It's in practice possible that modifier wouldn't have determenistic order of faces and think it is p to the bake api to be robust enough to support this. One of possible ways solving this is to apply modifiers onto the objects copied to a separate Main. This will ensure the same exact data is used by both blender and cycles sides. Since this is more a design re-consideration it's not strictly a bug, just a limitation of current system. But i'll let @dfelinto to make a final decision here.

Brecht Van Lommel commented

2016-02-13 23:09:18 +01:00

Added subscriber: @brecht

Brecht Van Lommel commented

2016-02-13 23:09:18 +01:00

Changed status from 'Open' to: 'Archived'

Brecht Van Lommel closed this issue

2016-02-13 23:09:18 +01:00

Brecht Van Lommel commented

2016-02-13 23:09:18 +01:00

In my opinion the modifier should be totally deterministic, face order matters, for example for particle hair attached to faces or drawing of transparent meshes in the viewport. Also just for debugging or automated testing any non-deterministic behavior makes things harder.

There may be other causes, but it seems the carve boolean code is using lots of unordered_map and unordered_set with pointers as keys, and then iterating over them, which is certainly non-deterministic. Fixing that seems like it would require deep changes to the carve code though, and hopefully we get better bmesh booleans at some point. Let's move this to the to do list.

In my opinion the modifier should be totally deterministic, face order matters, for example for particle hair attached to faces or drawing of transparent meshes in the viewport. Also just for debugging or automated testing any non-deterministic behavior makes things harder. There may be other causes, but it seems the carve boolean code is using lots of `unordered_map` and `unordered_set` with pointers as keys, and then iterating over them, which is certainly non-deterministic. Fixing that seems like it would require deep changes to the carve code though, and hopefully we get better bmesh booleans at some point. Let's move this to the to do list.

Dalai Felinto commented

2016-02-15 14:17:46 +01:00

Added to http://wiki.blender.org/index.php/Dev:Source/Development/Todo/Render#Baking

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

cycles bake NormalMap problem #42015