Baking doesn't work #33818

New Issue

Enrico Valenza · 2013-01-10T10:29:37+01:00

Enrico Valenza commented

2013-01-10 10:29:37 +01:00

%%%--- Operating System, Graphics card ---
Ubuntu 10.10 64 bit - Geforce GT 320M

- Blender version with error, and version that worked ---

r53674 but also older, since years starting with the 2.5 series; worked fine in 2.4 series.

- Short description of error ---

I attached a short timelapse recorded trying to bake displacement (and also Full render, that didn't work well neither) to show what I'm trying to say since a couple of years; I had also a displacement baking debugging section with Sergey some time ago, but in the end the bug still shows: in short, trying to bake I obtain randomly wasted, gray, white or black images but not the correct baking.

- Steps for others to reproduce the error (preferably based on attached .blend file) ---

Open the attached file and press the "bake" button. I attached the timelapse because several time I've been told that "everything works ok here", so maybe it's something related to my system only, dunno (actually seems I'm the only one having these problems with baking).

%%%

%%%--- Operating System, Graphics card --- Ubuntu 10.10 64 bit - Geforce GT 320M - Blender version with error, and version that worked --- r53674 but also older, since years starting with the 2.5 series; worked fine in 2.4 series. - Short description of error --- I attached a short timelapse recorded trying to bake displacement (and also Full render, that didn't work well neither) to show what I'm trying to say since a couple of years; I had also a displacement baking debugging section with Sergey some time ago, but in the end the bug still shows: in short, trying to bake I obtain randomly wasted, gray, white or black images but not the correct baking. - Steps for others to reproduce the error (preferably based on attached .blend file) --- Open the attached file and press the "bake" button. I attached the timelapse because several time I've been told that "everything works ok here", so maybe it's something related to my system only, dunno (actually seems I'm the only one having these problems with baking). %%%

Enrico Valenza commented

2013-01-10 10:29:37 +01:00

Changed status to: 'Open'

Tobias Oelgarte commented

2013-01-10 11:07:42 +01:00

%%%Starting from your example file: 8 bit target, distance set, normal in opposite direction.

The value range of the image is "-distance" to "distance" (mapped to 0 to 1). The distance matches the distance to one of the cubes. Floating point errors produce the dots. Normalization won't work, as long the distance is set (should be that way). But pixels further away then -distance (in negative direction) should be black.

This is indeed a bug!

If you set distance to 0, then the mapping is 0 to 1 (also for the image 0 to 1). That means: As long the normal is pointing away you will get only black, because negative values are clamped to 0 and anything is below 0. If the normal points downward, then you will get results, but the maximum distance (distance set to 0) will be 1, which is not enough to reach to the bottom plane. Activating "Normalized" will have no effect since some rays miss the bottom target (scale it a bit larger to avoid this), and will give infinity results.

Conclusion: If distance is set the values of the image (0 to 1) will be mapped from "-distance" to "distance". If -distance is exceeded the result will be white, but should be black. This is a bug. If distance is not set then the range is from 0 to 1 for both. Since negative values can't be stored in an 8 bit image it will be clipped. Normalization only works if all rays hit the target.%%%

%%%Starting from your example file: 8 bit target, distance set, normal in opposite direction. The value range of the image is "-distance" to "distance" (mapped to 0 to 1). The distance matches the distance to one of the cubes. Floating point errors produce the dots. Normalization won't work, as long the distance is set (should be that way). But pixels further away then -distance (in negative direction) should be black. This is indeed a bug! If you set distance to 0, then the mapping is 0 to 1 (also for the image 0 to 1). That means: As long the normal is pointing away you will get only black, because negative values are clamped to 0 and anything is below 0. If the normal points downward, then you will get results, but the maximum distance (distance set to 0) will be 1, which is not enough to reach to the bottom plane. Activating "Normalized" will have no effect since some rays miss the bottom target (scale it a bit larger to avoid this), and will give infinity results. Conclusion: If distance is set the values of the image (0 to 1) will be mapped from "-distance" to "distance". If -distance is exceeded the result will be white, but should be black. This is a bug. If distance is not set then the range is from 0 to 1 for both. Since negative values can't be stored in an 8 bit image it will be clipped. Normalization only works if all rays hit the target.%%%

Tobias Oelgarte commented

2013-01-10 11:11:58 +01:00

%%%PS: They should be black, since the ray hit something in negative direction, even so it was out of range for baking. Otherwise the baker can't decide if to use white or black.%%%

Sergey Sharybin commented

2013-01-10 11:44:42 +01:00

%%%Random dots are indeed caused by floating point precision. One of possible solution would be to add FLT_EPSILON to maximal distance. It'll solve issue in such obvious case but could still behave wrong in other cases.

I didn't understand Tobias's description. If ray doesn't hit anything, displacement is assumed to be zero, which would be mapped to 0.5 anyway.

So, if you'll increase max distance a bit, so there'll be no float point issues and bake to a float buffer, most of the area will have values of 0.5, which equals to no displacement at all. Values in dark area corresponding to bigger cube, will be -0.5 which equals to displacement of -1 (plane normal is looking in positive Z direction), values in black area corresponding to smaller cube will be -0.7, which equals to displacement of -1.2 which also seems to be matching your scene.

If you'll enable normalization, smaller cube will be the most black (as it corresponds to the most displacement by absolute value), bigger cube will be dark gray (a bit smaller displacement than caused by smaller cube). All the rest area will be half-gray (value of 0.5) since there's no displacement at all for that areas.

Enrico, when you're talking something doesn't work, please mention what's the expected for you behavior. Currently i can not see any bigger issues than floating point precision, which is not so trivial to solve.%%%

%%%Random dots are indeed caused by floating point precision. One of possible solution would be to add FLT_EPSILON to maximal distance. It'll solve issue in such obvious case but could still behave wrong in other cases. I didn't understand Tobias's description. If ray doesn't hit anything, displacement is assumed to be zero, which would be mapped to 0.5 anyway. So, if you'll increase max distance a bit, so there'll be no float point issues and bake to a float buffer, most of the area will have values of 0.5, which equals to no displacement at all. Values in dark area corresponding to bigger cube, will be -0.5 which equals to displacement of -1 (plane normal is looking in positive Z direction), values in black area corresponding to smaller cube will be -0.7, which equals to displacement of -1.2 which also seems to be matching your scene. If you'll enable normalization, smaller cube will be the most black (as it corresponds to the most displacement by absolute value), bigger cube will be dark gray (a bit smaller displacement than caused by smaller cube). All the rest area will be half-gray (value of 0.5) since there's no displacement at all for that areas. Enrico, when you're talking something doesn't work, please mention what's the expected for you behavior. Currently i can not see any bigger issues than floating point precision, which is not so trivial to solve.%%%

Tobias Oelgarte commented

2013-01-10 12:07:32 +01:00

%%%@Sergey: I mean rays that hit something but are out of range if you set the distance (d). Lets say you set d=1 and your object is 2 BE away in negative direction. Then a ray will hit the object (d=-2) and the result will be clamped (d=-1). The actual color value for -1 is black. But currently it gives gray, which is gives artifacts. I appended an example file in which i would expect to have half of the ramp in gray tones and anything else black. What i get is the ramp (gray to black and black to clamped black). But on the other side, the plane is gray.%%%

Sergey Sharybin commented

2013-01-10 12:22:55 +01:00

%%%Distance isn't used to clamp actual distance between current point and intersection, it defines how far away intersection is allowed to be. So if there is an intersection, but it's ore far away than distance, it wouldn't be detected and will make mesh have no displacement for correspondent point.

Clamping could be useful in some cases as well, but that's not how baker is designed to work and wouldn't consider this is a bug.%%%

%%%Distance isn't used to clamp actual distance between current point and intersection, it defines how far away intersection is allowed to be. So if there is an intersection, but it's ore far away than distance, it wouldn't be detected and will make mesh have no displacement for correspondent point. Clamping could be useful in some cases as well, but that's not how baker is designed to work and wouldn't consider this is a bug.%%%

Tobias Oelgarte commented

2013-01-10 13:01:11 +01:00

%%%But it also does clamp the values already for faces that are partially in range. This is very useful and often necessary for low color resolution bump maps, since it allows to set an absolute scaled distance for the bake. Without that the user looses the ability to define a range mapping without switching to float and processing the image manually and then to convert it back to 8 bit. That is a much more complicated approach. I also see no true benefit in the case that the default value (0.5) is used for all faces further away then the distance. If the intersection is further away, clamping the distance does not hurt and has practical use cases. But just setting a default value has no benefit at all.%%%

Enrico Valenza commented

2013-01-10 15:09:51 +01:00

%%%"Enrico, when you're talking something doesn't work, please mention what's the expected for you behavior. Currently i can not see any bigger issues than floating point precision, which is not so trivial to solve."

Sergey, the behaviour I expected was just to obtain a grey-scale displacement image map, what else?
Ok, let me explain what I did: I was looking at a video tutorial by Oliver Villar (this one: http://www.youtube.com/watch?v=VY9vHdwUo98), in this tutorial the author had just modelled a quick greeble, added a plane, unwrapped, assigned a blank image map and baked the displacement. In the video it worked perfectly at first try.
I did the same steps, but I just obtained (as you can see in the timelapse I attached) first a black image, then (by trying different settings of the distance value) a gray image, then different incorrect images and so; at the end I managed to obtain a quite good one by setting the distance value to 2.300 and the bias value to 0.100, any other value gives incorrect results. Now, why can't I obtain a simple result at first try as in the video tutorial?
%%%

%%%"Enrico, when you're talking something doesn't work, please mention what's the expected for you behavior. Currently i can not see any bigger issues than floating point precision, which is not so trivial to solve." Sergey, the behaviour I expected was just to obtain a grey-scale displacement image map, what else? Ok, let me explain what I did: I was looking at a video tutorial by Oliver Villar (this one: http://www.youtube.com/watch?v=VY9vHdwUo98), in this tutorial the author had just modelled a quick greeble, added a plane, unwrapped, assigned a blank image map and baked the displacement. In the video it worked perfectly at first try. I did the same steps, but I just obtained (as you can see in the timelapse I attached) first a black image, then (by trying different settings of the distance value) a gray image, then different incorrect images and so; at the end I managed to obtain a quite good one by setting the distance value to 2.300 and the bias value to 0.100, any other value gives incorrect results. Now, why can't I obtain a simple result at first try as in the video tutorial? %%%

Sergey Sharybin commented

2013-01-10 17:03:29 +01:00

%%%You do obtain grey-scale displacement, which is computed in exact the same way as baker was designed to work.

Oliver was just lucky enough that defautl parameters worked fine for him in terms they gave okish-look displacement map, But that's just because his scene was small enough and his displacements were smaller than 0.5 blender units, which fitted into visible color range in the image. Your scene is much bigger and displacement doesn't fit visible color range, so you need to do some manual tweaks to make things working.

In fact, you do have correct results in any case, your tricks just mapped displacement to visible space. And actually, that's not necesserily needed if you'll bake to float image -- it should be applied nicely in this case too.

But there's indeed one bad thing here -- normalization for displacement maps maps Distance (which you set in the UI) from range -Distance .. Distance to 0..1, but it'll do nothing if distance equals to zero. That's actually matter of some assumptions, but perhaps normalizing actual values of displacements to 0..1 will sense here.

P.S. You could obtain the same exact results as in tutorial you mentioned by scaling scene down. Nothing actually changed in this area since 2.64.%%%

%%%You do obtain grey-scale displacement, which is computed in exact the same way as baker was designed to work. Oliver was just lucky enough that defautl parameters worked fine for him in terms they gave okish-look displacement map, But that's just because his scene was small enough and his displacements were smaller than 0.5 blender units, which fitted into visible color range in the image. Your scene is much bigger and displacement doesn't fit visible color range, so you need to do some manual tweaks to make things working. In fact, you do have correct results in any case, your tricks just mapped displacement to visible space. And actually, that's not necesserily needed if you'll bake to float image -- it should be applied nicely in this case too. But there's indeed one bad thing here -- normalization for displacement maps maps Distance (which you set in the UI) from range -Distance .. Distance to 0..1, but it'll do nothing if distance equals to zero. That's actually matter of some assumptions, but perhaps normalizing actual values of displacements to 0..1 will sense here. P.S. You could obtain the same exact results as in tutorial you mentioned by scaling scene down. Nothing actually changed in this area since 2.64.%%%

Sergey Sharybin commented

2013-01-10 17:23:06 +01:00

%%%Actually, i'll check with Brecht if it's indeed makes sense to change behavior of Normalize option.%%%

Enrico Valenza commented

2013-01-11 11:27:45 +01:00

%%%Ok I see; btw I think it's a bit weird to have a displacement baking feature that works at first try only if you are lucky enough to model everything inside the color range...

And, just a last thing: by setting the distance value to 2.300 and the bias value to 0.100 I managed to obtain a displacement map, but I'm not sure it's a correct one. I'm referring to the contrast of the image: setting the displacement to a strength value of 1.000 doesn't give me back the same displacement, a strength of 4.000 does (so the baked image seems to have lighter contrasts).

Thanks for your time.%%%

%%%Ok I see; btw I think it's a bit weird to have a displacement baking feature that works at first try only if you are lucky enough to model everything inside the color range... And, just a last thing: by setting the distance value to 2.300 and the bias value to 0.100 I managed to obtain a displacement map, but I'm not sure it's a correct one. I'm referring to the contrast of the image: setting the displacement to a strength value of 1.000 doesn't give me back the same displacement, a strength of 4.000 does (so the baked image seems to have lighter contrasts). Thanks for your time.%%%

Sergey Sharybin commented

2013-01-11 11:48:19 +01:00

%%%It's not weird, it's what displacement map is. It's just values, not colors and if values are not in visible range it's not a bug at all (at least for float images). Baking will happen even if your scene is 30K large, just to see results you couldn't use display but need to either investigate values with mouse or normalize the map manually in compositor.

Setting maximal distance and enabling normalization will map actual displacement values to visible color range, but after this you'll need to alter strength of displacement when you'll use this texture.

I assume this is exact what you did -- baked with distance=2.3, bias=0.1 and normalization enabled. In this case you'll indeed need to increase strength. If you'll do the same bake, but disable normalization and bake to float image, displacement shall be the same with strength=1.%%%

%%%It's not weird, it's what displacement map is. It's just values, not colors and if values are not in visible range it's not a bug at all (at least for float images). Baking will happen even if your scene is 30K large, just to see results you couldn't use display but need to either investigate values with mouse or normalize the map manually in compositor. Setting maximal distance and enabling normalization will map actual displacement values to visible color range, but after this you'll need to alter strength of displacement when you'll use this texture. I assume this is exact what you did -- baked with distance=2.3, bias=0.1 and normalization enabled. In this case you'll indeed need to increase strength. If you'll do the same bake, but disable normalization and bake to float image, displacement shall be the same with strength=1.%%%

Tobias Oelgarte commented

2013-01-11 12:36:40 +01:00

%%%@Enrico: You should also ensure that the image/texture is displayed as "raw data". Otherwise you will have an optical distortion due to color management in the UV/Image editor. If it is displayed as "linear" (the default), then a value of 0.5 will be displayed as the RGB color (0.7, 0.7, 0.7) or something similar. To see the true value you need to check the image by pressing the mouse button. It shows the true (not color managed) value that is stored and used later on for displacement.%%%

Enrico Valenza commented

2013-01-11 16:28:11 +01:00

%%%@Tobias: yes, but I judged the baked image mainly by the effect it has on the displacement, not from what I see in the UV Editor. :)

@Sergey: I just tried to bake with distance=2.3, bias=0.1 and normalization disabled (and I always baked to an OpenEXR 32 bit image) and I obtained an almost totally black image; but just to be sure I assigned it to the displacement of a subdivided plane and there was no effect at all.%%%

%%%@Tobias: yes, but I judged the baked image mainly by the effect it has on the displacement, not from what I see in the UV Editor. :) @Sergey: I just tried to bake with distance=2.3, bias=0.1 and normalization disabled (and I always baked to an OpenEXR 32 bit image) and I obtained an almost totally black image; but just to be sure I assigned it to the displacement of a subdivided plane and there was no effect at all.%%%

Sergey Sharybin commented

2013-01-21 10:10:58 +01:00

%%%I've implement normalization of displacement map in cases maximal distance is set to 0 in svn rev53947.

I could see why displacement map doesn't work for you if you bake without normalization/flipping normal -- for some reason texture sampler will clamp negative values to zero, which eliminates displacement. Removing this clamp will make displacement applied correctly without additional settings in your particular case but it'll break lots of files. So either normalize displacement and set displacement strength afterwards or flip normal of object you're baking on first.

Could not see what else could be done here to make displacement baker working more expectable here, it's just not thing which you could press couple of buttons and have correct result. I'll try to find time next couple of days writing fuller explanation how it works in the wiki.

Thanks for the report, but considering it solved for now.%%%

%%%I've implement normalization of displacement map in cases maximal distance is set to 0 in svn rev53947. I could see why displacement map doesn't work for you if you bake without normalization/flipping normal -- for some reason texture sampler will clamp negative values to zero, which eliminates displacement. Removing this clamp will make displacement applied correctly without additional settings in your particular case but it'll break lots of files. So either normalize displacement and set displacement strength afterwards or flip normal of object you're baking on first. Could not see what else could be done here to make displacement baker working more expectable here, it's just not thing which you could press couple of buttons and have correct result. I'll try to find time next couple of days writing fuller explanation how it works in the wiki. Thanks for the report, but considering it solved for now.%%%

Sergey Sharybin commented

2013-01-21 10:11:00 +01:00

Changed status from 'Open' to: 'Resolved'

Sergey Sharybin closed this issue

2013-01-21 10:11:00 +01:00

Sign in to join this conversation.

3 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#33818

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Baking doesn't work #33818