Glossy shader bakes different than render #40375

New Issue

Daniel Salazar · 2014-05-26T23:51:00+02:00

Daniel Salazar commented

2014-05-26 23:51:00 +02:00

System Information

openSUSE 12.3 64bits
NVIDIA 480GTX SC
AMD FX-8350

Blender Version

Broken: 0efc0d5
This broke after recent fixes for this bug #40322

Short description of error

See difference in glossy results. Baked vs Rendered

Exact steps for others to reproduce the error

Bake this file Bake_Debug1.blend
Compare with rendered output

Both Anisotropic Glossy and Regular glossy present this problem

**System Information** openSUSE 12.3 64bits NVIDIA 480GTX SC AMD FX-8350 **Blender Version** Broken: 0efc0d5 This broke after recent fixes for this bug #40322 **Short description of error** See difference in glossy results. Baked vs Rendered ![Glossy_Bake.png](https://archive.blender.org/developer/F91288/Glossy_Bake.png) **Exact steps for others to reproduce the error** Bake this file [Bake_Debug1.blend](https://archive.blender.org/developer/F91292/Bake_Debug1.blend) Compare with rendered output Both Anisotropic Glossy and Regular glossy present this problem

Daniel Salazar commented

2014-05-26 23:51:00 +02:00

Changed status to: 'Open'

Dalai Felinto was assigned by Daniel Salazar

2014-05-26 23:51:00 +02:00

Daniel Salazar commented

2014-05-26 23:51:00 +02:00

Added subscriber: @zanqdo

Dalai Felinto commented

2014-05-27 00:05:37 +02:00

The issue happens with glossy direct and indirect too.

Dalai Felinto commented

2014-05-27 00:23:27 +02:00

Simplified the report file to a plane glossy-bake.blend. Basically it seems like baking always consider the camera to be with rotation 0,0,0 and at the origin.

Simplified the report file to a plane [glossy-bake.blend](https://archive.blender.org/developer/F91299/glossy-bake.blend). Basically it seems like baking always consider the camera to be with rotation 0,0,0 and at the origin.

Brecht Van Lommel commented

2014-05-27 13:39:11 +02:00

Added subscriber: @brecht

Brecht Van Lommel commented

2014-05-27 13:39:11 +02:00

Even before that bugfix glossy was not the same as in final renders as far as I know, that bugfix can't have caused this problem. Glossy depends on the direction from which you're viewing the surface, and it's not obvious what that should be for baking.

Currently the viewing direction for each pixel is set to the normal, so at every pixel glossy is evaluated as if you're looking straight at it. Blender Internal works the same.

If you want to bake glossy so that it matches exactly what you see from the active camera, instead it could do: sd.I = normalize(camP - sd.P) for perspective and sd.I = -camD for orthographic which camP and camD as in camera_distance(..). Not sure about the math for panorama cameras, guess it can just do the same as perspective since the implementation is missing in camera_distance(..) as well still.

Even before that bugfix glossy was not the same as in final renders as far as I know, that bugfix can't have caused this problem. Glossy depends on the direction from which you're viewing the surface, and it's not obvious what that should be for baking. Currently the viewing direction for each pixel is set to the normal, so at every pixel glossy is evaluated as if you're looking straight at it. Blender Internal works the same. If you want to bake glossy so that it matches exactly what you see from the active camera, instead it could do: `sd.I = normalize(camP - sd.P)` for perspective and `sd.I = -camD` for orthographic which `camP` and `camD` as in `camera_distance(..)`. Not sure about the math for panorama cameras, guess it can just do the same as perspective since the implementation is missing in `camera_distance(..)` as well still.

Dalai Felinto commented

2014-05-27 15:08:29 +02:00

I think it's fine to bake as viewed by the camera. Eventually we may need an option to disable view-dependent effects, but for now I think D555 could go in.

I think it's fine to bake as viewed by the camera. Eventually we may need an option to disable view-dependent effects, but for now I think [D555](https://archive.blender.org/developer/D555) could go in.

blender-admin commented

2014-05-27 15:43:26 +02:00

This issue was referenced by 12abe94de8

This issue was referenced by 12abe94de827d9ae9c0dd6cc49bc6c3e377842ad

Dalai Felinto commented

2014-05-27 15:43:57 +02:00

Changed status from 'Open' to: 'Resolved'

Dalai Felinto closed this issue

2014-05-27 15:43:57 +02:00

Dalai Felinto commented

2014-05-27 15:43:57 +02:00

Closed by commit 12abe94de8.

Closed by commit 12abe94de8.

gandalf3 commented

2014-05-27 22:14:15 +02:00

Added subscribers: @dfelinto, @gandalf3

gandalf3 commented

2014-05-27 22:14:15 +02:00

It's nice to have both ways imo, I've been playing around with baking a bit, and found the view-independent glossy baking quite handy..
+1 to having an option to toggle this behavior as @dfelinto mentioned.

Just wanted to put in a vote for keeping the old behavior around too.

It's nice to have both ways imo, I've been playing around with baking a bit, and found the view-independent glossy baking quite handy.. +1 to having an option to toggle this behavior as @dfelinto mentioned. Just wanted to put in a vote for keeping the old behavior around too.

Daniel Salazar commented

2014-05-27 23:25:13 +02:00

Excellent! Yes being able to bake it from the active camera is huge :D

Daniel Salazar commented

2014-05-28 01:42:51 +02:00

Now it's all messed up in my original test file. Testing on planes is not always that useful ;)

Daniel Salazar commented

2014-05-28 01:43:07 +02:00

Changed status from 'Resolved' to: 'Open'

Daniel Salazar reopened this issue

2014-05-28 01:43:07 +02:00

Dalai Felinto commented

2014-05-28 03:54:45 +02:00

@zanqdo are you sure? from the camera point of view the results are matching (top bake, bottom render). And if you look from outside the camera point of view then it shouldn't not match since glossy is view dependent.

I do test with the reported files ;) planes are essential for fast debugging though.

@zanqdo are you sure? from the camera point of view the results are matching ![caterpillar.jpg](https://archive.blender.org/developer/F91660/caterpillar.jpg) (top bake, bottom render). And if you look from outside the camera point of view then it shouldn't not match since glossy is view dependent. I do test with the reported files ;) planes are essential for fast debugging though.

Daniel Salazar commented

2014-05-28 04:09:06 +02:00

Here's what I'm getting :o

Here's what I'm getting :o ![Glossy_BakeError.png](https://archive.blender.org/developer/F91665/Glossy_BakeError.png)

Dalai Felinto commented

2014-05-28 04:40:58 +02:00

@brecht any clues? I think we need to invert the direction based on the orientation to the camera. I tried some variations of dot checks to invert the ray direction (like below) but I'm not sure what the test should be. All I managed to get was to get some funky results.

if(dot(sd.I, sd.N) < 0.0f)
	sd.I = -sd.I;

@brecht any clues? I think we need to invert the direction based on the orientation to the camera. I tried some variations of dot checks to invert the ray direction (like below) but I'm not sure what the test should be. All I managed to get was to get some funky results. ``` if(dot(sd.I, sd.N) < 0.0f) sd.I = -sd.I; ```

Fazekas Laszlo commented

2014-05-28 07:48:02 +02:00

Added subscriber: @totoro-4

Fazekas Laszlo commented

2014-05-28 07:48:02 +02:00

The black parts are the problem on the texture? It seems those are the parts hidden from the camera POV. If the rays reaching these parts, maybe they are reflected into the inside of the object so they cannot reach the light source. @dfelino: what happens if you invert both the ray and the normal vector?

Brecht Van Lommel commented

2014-05-28 16:40:29 +02:00

In the screenshot shown by @zanqdo, as far as I can tell the baked result does actually match watch you see from the camera, it's just that the viewport render is from a different point of view. The problem is that it's black on the backside which doesn't look good.

I'd say that the fact that the backside is black is in a way correct. There's no way the glossy reflection will reach the camera, so there's no light on the backside. It's a situation that would never come up in regular rendering. The fact that glossy BSDFs do no fade to black smoothly at grazing angles makes it worse because you get this discontinuity. But that BSDF behaviour is by design.

But ok, we want something that looks better on the backside and that's tricky. I wonder if there is any baking software that attempts to handle this well?

The best I could come up with is to fade I to N when you get towards grazing angles, but that's a pretty big hack, though at least it looks similar then from the front and with no discontinuity on the side, just somewhat non-sensical glossy highlights on the side and back.

  sd.I = camera_direction_from_point(kg, sd.P);

  if(dot(sd.I, sd.N) < 0.0f)
      sd.I = sd.N;
  else
      sd.I = interp(sd.N, sd.I, sqrtf(dot(sd.N, sd.I)));

In the screenshot shown by @zanqdo, as far as I can tell the baked result does actually match watch you see from the camera, it's just that the viewport render is from a different point of view. The problem is that it's black on the backside which doesn't look good. I'd say that the fact that the backside is black is in a way correct. There's no way the glossy reflection will reach the camera, so there's no light on the backside. It's a situation that would never come up in regular rendering. The fact that glossy BSDFs do no fade to black smoothly at grazing angles makes it worse because you get this discontinuity. But that BSDF behaviour is by design. But ok, we want something that looks better on the backside and that's tricky. I wonder if there is any baking software that attempts to handle this well? The best I could come up with is to fade `I` to `N` when you get towards grazing angles, but that's a pretty big hack, though at least it looks similar then from the front and with no discontinuity on the side, just somewhat non-sensical glossy highlights on the side and back. ``` sd.I = camera_direction_from_point(kg, sd.P); ``` ``` if(dot(sd.I, sd.N) < 0.0f) sd.I = sd.N; else sd.I = interp(sd.N, sd.I, sqrtf(dot(sd.N, sd.I)));

Brecht Van Lommel commented

2014-05-28 16:41:17 +02:00

@totoro-4: if you invert the normal you're inside the mesh, where there is no light.

Fazekas Laszlo commented

2014-05-28 17:46:16 +02:00

@brecht : I thought the black is there because the rays are already go inside, that's why I recommended the flip for the normal. By the way, what is the color exactly at the border of the black parts? Is it an environment color? I don't understand why it is not on the black parts too.

Dalai Felinto commented

2014-05-28 17:52:51 +02:00

I just realized that even the viewport rendering doesn't change if I move the camera when not looking through the camera. So it's not like rendering is doing a different calculation.

@brecht this actually makes the result to be different even from the camera point of view. And the overall result (in the caterpillar) is awful :/

What about:
For combined we use sd.I = sd.N;
For glossy direct we use sd.I = camera_direction_from_point(kg, sd.P);

I just realized that even the viewport rendering doesn't change if I move the camera when not looking through the camera. So it's not like rendering is doing a different calculation. @brecht this actually makes the result to be different even from the camera point of view. And the overall result (in the caterpillar) is awful :/ What about: For combined we use sd.I = sd.N; For glossy direct we use sd.I = camera_direction_from_point(kg, sd.P);

Daniel Salazar commented

2014-05-28 18:02:17 +02:00

@dfelinto are you sure? If I understand you right, that doesn't make much sense :p Glossy is always dependent on viewpoint, even in the live preview :)

Dalai Felinto commented

2014-05-28 18:07:50 +02:00

I just realized that even the viewport rendering doesn't change if I move the camera when not looking through the camera. So it's not like rendering is doing a different calculation.

In other words, if I'm not looking through the camera and move the "Camera" object I see no difference in the render preview. @zanqdo ^^

> I just realized that even the viewport rendering doesn't change if I move the camera when not looking through the camera. So it's not like rendering is doing a different calculation. In other words, if I'm not looking through the camera and move the "Camera" object I see no difference in the render preview. @zanqdo ^^

Brecht Van Lommel commented

2014-05-28 18:16:24 +02:00

@totoro-4: for the glossy BSDF to do anything the normal N and view direction I need to be on the same side, if there is no light reflect and it gives black.

For a face that is facing away from the camera, you can either flip I to the front of the face, or N to the back of the face. In the former case you do what @dfelinto proposed. In the latter case you end up on the inside of the mesh, and any path to the light will be blocked.

Not sure what you mean by the color at the border.

@totoro-4: for the glossy BSDF to do anything the normal `N` and view direction `I` need to be on the same side, if there is no light reflect and it gives black. For a face that is facing away from the camera, you can either flip `I` to the front of the face, or `N` to the back of the face. In the former case you do what @dfelinto proposed. In the latter case you end up on the inside of the mesh, and any path to the light will be blocked. Not sure what you mean by the color at the border.

Fazekas Laszlo commented

2014-05-28 18:20:52 +02:00

Perhaps something like this?

Perhaps something like this? ![rays.png](https://archive.blender.org/developer/F91730/rays.png)

Dalai Felinto commented

2014-05-28 18:25:52 +02:00

@zanqdo translating what I proposed (as requested on irc ;):

For combined we could use sd.I = sd.N, which would produce the result you had when you opened this report. Basically it means the "view direction" that will be used is the faces' normals.

For glossy direct we could use sd.I = camera_direction_from_point(kg, sd.P), which produce the current result in master. Basically it means the "view direction" is correct (uses the active camera as reference), but produces dark results for faces facing away from the camera.

@zanqdo translating what I proposed (as requested on irc ;): For combined we could use sd.I = sd.N, which would produce the result you had when you opened this report. Basically it means the "view direction" that will be used is the faces' normals. For glossy direct we could use sd.I = camera_direction_from_point(kg, sd.P), which produce the current result in master. Basically it means the "view direction" is correct (uses the active camera as reference), but produces dark results for faces facing away from the camera.

Brecht Van Lommel commented

2014-05-28 18:32:02 +02:00

@dfelinto: I don't think it would be a good idea to give a different result for glossy and combined passes, I don't see how that really helps, why you would want it to be one way for combined and another way for glossy direct/indirect. Better make it an option then that affects both.

You can get closer to the camera view by tweaking the blending but then the discontinuity becomes more and more obvious, e.g.:

  sd.I = interp(sd.N, sd.I, powf(dot(sd.N, sd.I), 0.2f));

In the end it's not clear to me what the purpose of baking this glossy component is. If you want something that looks similar-ish from all sides then you can use sd.I = sd.N. If you need to bake it to look at the result from one side with maybe some minor camera movement then I guess you could use a fairly low blending factor.

@dfelinto: I don't think it would be a good idea to give a different result for glossy and combined passes, I don't see how that really helps, why you would want it to be one way for combined and another way for glossy direct/indirect. Better make it an option then that affects both. You can get closer to the camera view by tweaking the blending but then the discontinuity becomes more and more obvious, e.g.: ``` sd.I = interp(sd.N, sd.I, powf(dot(sd.N, sd.I), 0.2f)); ``` In the end it's not clear to me what the purpose of baking this glossy component is. If you want something that looks similar-ish from all sides then you can use `sd.I = sd.N`. If you need to bake it to look at the result from one side with maybe some minor camera movement then I guess you could use a fairly low blending factor.

Brecht Van Lommel commented

2014-05-28 18:34:36 +02:00

@totoro-4, I'm not sure what that drawing represents exactly, but it should probably include both a camera and light to see the vectors to evaluate the BSDF and understand why some areas are black or have discontinuities.

Fazekas Laszlo commented

2014-05-28 18:39:11 +02:00

@brecht : any camera movement ruins the illusion, it's like if you replace a mirror with a picture on the wall. Human eye is very sensitive to this, I think. So maybe you can simply leave out the hidden parts rendering. But if you render there something, it must be seamless.

Fazekas Laszlo commented

2014-05-28 18:58:32 +02:00

@brecht: my drawing was about continuing the rays on the hidden side: not reflect them but just continue in the original camera-point direction because it is exactly what happening at the border of the black parts. If you need a normal vector for this, let it be perpendicular (or near perpendicular towards the camera) to the original s.I vector then.

Brecht Van Lommel commented

2014-05-28 21:22:59 +02:00

@totoro-4: ok, I think what you propose is the same as @dfelinto then. There I is flipped to "continue" in the same direction. That mostly avoids the black, but you still get a discontinuity at grazing angles where the view direction gets suddenly flipped.

@totoro-4: ok, I think what you propose is the same as @dfelinto then. There `I` is flipped to "continue" in the same direction. That mostly avoids the black, but you still get a discontinuity at grazing angles where the view direction gets suddenly flipped.

Dalai Felinto commented

2014-05-28 23:55:51 +02:00

Tomorrow I will revert the fix, which means we will get sd.I = sd.N again. I will elaborate a bit more in the log. Thanks for all the tests though.

blender-admin commented

2014-05-29 06:19:12 +02:00

This issue was referenced by 3a3edc6c2d

This issue was referenced by 3a3edc6c2d2b137a0b267c0af5ad01c5f2349bb9

Dalai Felinto commented

2014-05-29 06:30:12 +02:00

Changed status from 'Open' to: 'Resolved'

Dalai Felinto closed this issue

2014-05-29 06:30:12 +02:00

Dalai Felinto commented

2014-05-29 06:30:12 +02:00

Closed by commit 3a3edc6c2d.

Closed by commit 3a3edc6c2d.

marc dion commented

2014-07-30 08:29:43 +02:00

Added subscriber: @MarcClintDion

marc dion commented

2014-07-30 08:29:43 +02:00

You asked on a BA thread about the view dependent baking for Glossy.

case 1: Obviously, for close up objects, view dependent is trouble since the view changes and the Glossy will look wrong.

case 2: For objects off in the distance, like ice covered mountains for example, the view angle relative to the mountains will not change noticeably when the view changes as a character moves around the scene. For side scrolling games there is no rotation of the view at all and this would be another good situation for view dependent Glossy, especially if there are dynamic GLSL lights to hid the fact that the baked highlights are not moving. They would add detail but the wrongness of them would be lost in the detail of the moving lights.

It would be nice to have the option. Especially if the option allows us to interpolate between the 2 methods so this factor can be manually adjusted for objects at various distances.

This way we could make far away objects have view dependent Glossy, and also objects that are near can have non-view dependent Glossy and objects in between could have a mix of the two.

You asked on a BA thread about the view dependent baking for Glossy. ***case 1***: Obviously, for close up objects, view dependent is trouble since the view changes and the Glossy will look wrong. ***case 2***: For objects off in the distance, like ice covered mountains for example, the view angle relative to the mountains will not change noticeably when the view changes as a character moves around the scene. For side scrolling games there is no rotation of the view at all and this would be another good situation for view dependent Glossy, especially if there are dynamic GLSL lights to hid the fact that the baked highlights are not moving. They would add detail but the wrongness of them would be lost in the detail of the moving lights. It would be nice to have the option. Especially if the option allows us to interpolate between the 2 methods so this factor can be manually adjusted for objects at various distances. This way we could make far away objects have view dependent Glossy, and also objects that are near can have non-view dependent Glossy and objects in between could have a mix of the two.

Daniel Salazar commented

2014-07-30 08:32:23 +02:00

Agreed, I wish we had this somehow :) It's just useful

Leon Cheung commented

2014-12-28 08:23:01 +01:00

Added subscriber: @ZhangYu

Leon Cheung commented

2014-12-28 16:50:31 +01:00

IMHO, some very possible usages of POV-based glossy baking that I can think of are:

Skybox, Envrionment map;
360d games, where camera position is fixed, but camera rotation is allowed. (like the classic game Beachhead);
Interactive street view experiment (like Google Maps), and panoramic view for VR usage;
Camera mapping animation with 3D composition aided.

etc.

IMHO, some very possible usages of POV-based glossy baking that I can think of are: 1. Skybox, Envrionment map; 2. 360d games, where camera position is fixed, but camera rotation is allowed. (like the classic game Beachhead); 3. Interactive street view experiment (like Google Maps), and panoramic view for VR usage; 4. Camera mapping animation with 3D composition aided. etc.

marc dion commented

2014-12-29 01:15:38 +01:00

I think part of the issue is feature bloat and the UI clutter that comes with this. Maybe this could be solved by not exposing this in the UI.

If there is no camera in the scene then the glossy highlights would bake semi-non directional as it is now. With a camera present, then it could bake with the camera as the view position.

I think part of the issue is feature bloat and the UI clutter that comes with this. Maybe this could be solved by not exposing this in the UI. If there is no camera in the scene then the glossy highlights would bake semi-non directional as it is now. With a camera present, then it could bake with the camera as the view position.

gandalf3 commented

2014-12-29 01:17:07 +01:00

@MarcClintDion I must be missing something.. This should only require one checkbox, right? How would that be bloated?

marc dion commented

2014-12-29 01:27:20 +01:00

One or two check-box's for 40 other small different features that people want would cause bloat, the UI already has problems with this. That's what tabs were meant to address.

When you add up all the options for all the various things that could potentially be added to Blender, you start to have a mess. It's not just this tool people want extra features for.

The problem is something I've seen mentioned by one of the main devs a few times over the past couple years, I thought I'd offer up an idea that would help avoid the problem for this case.

One or two check-box's for 40 other small different features that people want would cause bloat, the UI already has problems with this. That's what tabs were meant to address. When you add up all the options for all the various things that could potentially be added to Blender, you start to have a mess. It's not just this tool people want extra features for. The problem is something I've seen mentioned by one of the main devs a few times over the past couple years, I thought I'd offer up an idea that would help avoid the problem for this case.

Leon Cheung commented

2014-12-29 03:50:39 +01:00

Well, if that is not a option, the only way I can think of is to first hit F12, then use that rendered image as a paint brush texture, to paint (or re-project) it from camera view. But I really don't think this is good, because, first, there would be so much loss on details; second, it leaves all back sides black (even some side sides); last, since objects have to be painted one by one, not good for scenes with quite a bit of objects.

Alex Faiad commented

2017-08-14 04:46:18 +02:00

Added subscriber: @alexfaiad

Alex Faiad commented

2017-08-14 04:46:18 +02:00

Is there some way to add it back? Or a script we can use or anything? This is extremely important for baking stuff for games like Leon explained.
I don't agree with the "bloat" reasoning (a 3d package is complex and need to be able to do a lot), but assuming it's valid, artists should at least be able to get a script somewhere to enable it back.

Is there some way to add it back? Or a script we can use or anything? This is extremely important for baking stuff for games like Leon explained. I don't agree with the "bloat" reasoning (a 3d package is complex and need to be able to do a lot), but assuming it's valid, artists should at least be able to get a script somewhere to enable it back.

Faxem commented

2018-07-03 11:47:50 +02:00

Added subscriber: @Faxem

Faxem commented

2018-07-03 11:47:50 +02:00

Please add the feature back. There are many cases where the results are far superior to a normal-based camera vector, for example when you have a flat reflective surface and an environment map.

Note that reversing the incidence vector for backfaces will produce wonky results, because such rays won't emerge from a single origin. You need a virtual camera that is diametrically opposite the object, and get the incidence vector from that. Even better would be a drop-down where you could choose between using normals or one, two, six or 36 cameras.

Please add the feature back. There are many cases where the results are far superior to a normal-based camera vector, for example when you have a flat reflective surface and an environment map. Note that reversing the incidence vector for backfaces will produce wonky results, because such rays won't emerge from a single origin. You need a virtual camera that is diametrically opposite the object, and get the incidence vector from that. Even better would be a drop-down where you could choose between using normals or one, two, six or 36 cameras.

Bite commented

2022-02-21 08:21:52 +01:00

Added subscriber: @Bite

Bite commented

2022-02-21 08:21:52 +01:00

Is this feature supported in blender 3.0? or is there another way to bake glossy as viewed by the camera?

marc dion commented

2022-02-21 13:05:13 +01:00

Removed subscriber: @MarcClintDion

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

Glossy shader bakes different than render #40375