Point/Spot Lights have Harsh Edges in Blender 4.0 (constant inside their radius) #114241

Closed
opened 2023-10-29 05:21:38 +01:00 by Mahid Sheikh · 36 comments

System Information
Operating system: Linux-6.5.9-zen2-1-zen-x86_64-with-glibc2.38 64 Bits, WAYLAND UI
Graphics card: Mesa Intel(R) Graphics (ADL GT2) Intel 4.6 (Core Profile) Mesa 23.2.1-arch1.2

Blender Version
Broken: version: 4.0.0 Beta, branch: blender-v4.0-release, commit date: 2023-10-27 13:13, hash: b0a032e2eb0a

Caused by a4d792a3ad

Short description of error
Point lights have extremely harsh edges, even with high radii like 5 meters. This behavior is not seen in Blender 3.6.5.

Blender 3.6.5:
image

Blender 4.0:
image

This behavior becomes annoying in practical scenes, such as this one (also attached to this report as VT-28-10-2023.blend):
image

Exact steps for others to reproduce the error

  1. Create a new scene in Blender
  2. Add a point light
  3. Increase the radius of said point light to a high value like 5 meters
**System Information** Operating system: Linux-6.5.9-zen2-1-zen-x86_64-with-glibc2.38 64 Bits, WAYLAND UI Graphics card: Mesa Intel(R) Graphics (ADL GT2) Intel 4.6 (Core Profile) Mesa 23.2.1-arch1.2 **Blender Version** Broken: version: 4.0.0 Beta, branch: blender-v4.0-release, commit date: 2023-10-27 13:13, hash: `b0a032e2eb0a` Caused by a4d792a3adef2e91af440798fccf11fa91204642 **Short description of error** Point lights have extremely harsh edges, even with high radii like 5 meters. This behavior is not seen in Blender 3.6.5. Blender 3.6.5: ![image](/attachments/c6125615-9dba-4fd6-982c-c718b6b90515) Blender 4.0: ![image](/attachments/766778f1-8346-4490-bdab-295e106c087a) This behavior becomes annoying in practical scenes, such as this one (also attached to this report as `VT-28-10-2023.blend`): ![image](/attachments/6be957be-9dc0-4406-a027-023397b1b475) **Exact steps for others to reproduce the error** 1. Create a new scene in Blender 2. Add a point light 3. Increase the radius of said point light to a high value like 5 meters
Mahid Sheikh added the
Type
Report
Priority
Normal
Status
Needs Triage
labels 2023-10-29 05:21:39 +01:00
Author

So apparently this is intended behavior (#108506). While I see the reasons why, I can't seem to replicate the old falloff behavior unless I set the power to an extremely high value. I think there should be an option to have the old falloff behavior, unless that would cause other issues?

So apparently this is intended behavior (https://projects.blender.org/blender/blender/pulls/108506). While I see the reasons why, I can't seem to replicate the old falloff behavior unless I set the power to an extremely high value. I think there should be an option to have the old falloff behavior, unless that would cause other issues?
Contributor

So apparently this is intended behavior (#108506). While I see the reasons why, I can't seem to replicate the old falloff behavior unless I set the power to an extremely high value. I think there should be an option to have the old falloff behavior, unless that would cause other issues?

Your light has massive radius. The main issue here is that Blender doesn't render light's visible surface by default, which leads to confusion like yours. The radius parameter in the point light is not falloff (the distance of illumination). It's literally the radius of the sphere that emits the light. The issue is that you don't see surface of that sphere, where as with mesh light, you would.

To get closer to your original result, reduce the radius of your light significantly, from 5 meters to like 5 centimeters, and then bring the light source closer to the surface.

> So apparently this is intended behavior (https://projects.blender.org/blender/blender/pulls/108506). While I see the reasons why, I can't seem to replicate the old falloff behavior unless I set the power to an extremely high value. I think there should be an option to have the old falloff behavior, unless that would cause other issues? Your light has massive radius. The main issue here is that Blender doesn't render light's visible surface by default, which leads to confusion like yours. The radius parameter in the point light is not falloff (the distance of illumination). It's literally the radius of the sphere that emits the light. The issue is that you don't see surface of that sphere, where as with mesh light, you would. To get closer to your original result, reduce the radius of your light significantly, from 5 meters to like 5 centimeters, and then bring the light source closer to the surface.
Author

The problem is a 5 centimeter light also has much harsher shadows, which is not what I'd want.

Looking in some older scene files, there's major compatibility issues causes by the change in how point lights are treated. It would be nice to have an option to opt out of treating point lights as emissive spheres and return to the old behavior, especially for compatibility reasons

The problem is a 5 centimeter light also has much harsher shadows, which is not what I'd want. Looking in some older scene files, there's major compatibility issues causes by the change in how point lights are treated. It would be nice to have an option to opt out of treating point lights as emissive spheres and return to the old behavior, especially for compatibility reasons
Contributor

The problem is a 5 centimeter light also has much harsher shadows, which is not what I'd want.

Looking in some older scene files, there's major compatibility issues causes by the change in how point lights are treated. It would be nice to have an option to opt out of treating point lights as emissive spheres and return to the old behavior, especially for compatibility reasons

The 3.6 behavior was so incorrect that it's borderline a bug. Cycles is a PBR renderer, and in physically based rendering, there should always be a relation between light source size and shadow softness. I mean even modern game engines do that. You should never run into a scenario where you need to break this relation, even for artistic purposes.

> The problem is a 5 centimeter light also has much harsher shadows, which is not what I'd want. > > Looking in some older scene files, there's major compatibility issues causes by the change in how point lights are treated. It would be nice to have an option to opt out of treating point lights as emissive spheres and return to the old behavior, especially for compatibility reasons The 3.6 behavior was so incorrect that it's borderline a bug. Cycles is a PBR renderer, and in physically based rendering, there should always be a relation between light source size and shadow softness. I mean even modern game engines do that. You should never run into a scenario where you need to break this relation, even for artistic purposes.
Member

Could you explain why there is a need for the light to have such a big radius in your scenes?
(just trying to understand why it has been set up like this, since it does not really seem to be based on real light properties).

Other than that, pretty sure this will be closed (same as #111091).

Could you explain why there is a need for the light to have such a big radius in your scenes? (just trying to understand why it has been set up like this, since it does not really seem to be based on real light properties). Other than that, pretty sure this will be closed (same as #111091).
Philipp Oeser added
Status
Needs Information from User
and removed
Status
Needs Triage
labels 2023-10-30 13:58:13 +01:00

Could you explain why there is a need for the light to have such a big radius in your scenes?
(just trying to understand why it has been set up like this, since it does not really seem to be based on real light properties).

Other than that, pretty sure this will be closed (same as #111091).

From personal experience (and it seems this experience aligns with many others), it's pretty common to use large radius, dimmer point lights to add artificial artistic lighting to scenes. The same is true in games and other media. Due to this changed behavior, this would now be much more inconvenient to achieve, and all previous projects would no longer be compatible with newer versions without significant changes to the lighting.

From my perspective, this change makes complete sense from a pathtracing standpoint, the previous behavior doesn't make physical sense at all. That being said, this old behavior was significantly more artist friendly in a lot of ways, and it feels like an overall regression to simply remove it entirely. It would be amazing if this behavior could be toggled with a checkbox or something, but in its current state I fear it would only make things worse.

> Could you explain why there is a need for the light to have such a big radius in your scenes? > (just trying to understand why it has been set up like this, since it does not really seem to be based on real light properties). > > Other than that, pretty sure this will be closed (same as #111091). From personal experience (and it seems this experience aligns with many others), it's pretty common to use large radius, dimmer point lights to add artificial artistic lighting to scenes. The same is true in games and other media. Due to this changed behavior, this would now be much more inconvenient to achieve, and all previous projects would no longer be compatible with newer versions without significant changes to the lighting. From my perspective, this change makes complete sense from a pathtracing standpoint, the previous behavior doesn't make physical sense at all. _That being said_, this old behavior was significantly more artist friendly in a lot of ways, and it feels like an overall regression to simply remove it entirely. It would be amazing if this behavior could be toggled with a checkbox or something, but in its current state I fear it would only make things worse.
Author

Could you explain why there is a need for the light to have such a big radius in your scenes?

The scene I gave in the original issue was where I noticed the problem originally, so I'll use another scene I have to demonstrate.

In this scene below, we have a light that's supposed to act as environment light provided by the scene (off camera of course). Since this presumably comes from a large source of light, a large radius was assigned to said light.
image

However, if we open this same scene in Blender 4.0, that same light now no longer acts in the same way.
image

In addition, in the latter image, we also see the effects on negative lights, which now have a clearly defined border, and these are both small and quite close to the subject (hence why simply moving a light closer is not sufficient).
image

Now one might say "why not use an area light?". In some cases, yes an area light would be fine, but area lights are still at their core flat planes, which makes using them in certain circumstances much more annoying (say a lantern where you want to have soft shadows from for artistic reasons). In addition, that still doesn't address the fact that many old scenes are broken in Blender 4.0. Even if we factor that 4.0 is meant to be breaking, I don't think any user expects something as the point light to have a breaking change.

Cycles is a PBR renderer, and in physically based rendering, there should always be a relation between light source size and shadow softness. I mean even modern game engines do that. You should never run into a scenario where you need to break this relation, even for artistic purposes.

I'm not saying that light sources in Cycles need to break how shadows relate to size, I'm saying that it would be nice to have an option for point lights (and by extension spotlights) that allows Cycles to not treat them as a sphere.

> Could you explain why there is a need for the light to have such a big radius in your scenes? The scene I gave in the original issue was where I noticed the problem originally, so I'll use another scene I have to demonstrate. In this scene below, we have a light that's supposed to act as environment light provided by the scene (off camera of course). Since this presumably comes from a large source of light, a large radius was assigned to said light. ![image](/attachments/5f97f357-be1f-4680-bb79-7cab3bff09e0) However, if we open this same scene in Blender 4.0, that same light now no longer acts in the same way. ![image](/attachments/66dc34fb-e1a4-4e05-860f-ed84d6a2ed6a) In addition, in the latter image, we also see the effects on negative lights, which now have a clearly defined border, and these are both small and quite close to the subject (hence why simply moving a light closer is not sufficient). ![image](/attachments/d160dced-6f00-445d-9fbf-c3246340b1d6) Now one might say "why not use an area light?". In some cases, yes an area light would be fine, but area lights are still at their core flat planes, which makes using them in certain circumstances much more annoying (say a lantern where you want to have soft shadows from for artistic reasons). In addition, that still doesn't address the fact that many old scenes are broken in Blender 4.0. Even if we factor that 4.0 is meant to be breaking, I don't think any user expects something as the point light to have a breaking change. > Cycles is a PBR renderer, and in physically based rendering, there should always be a relation between light source size and shadow softness. I mean even modern game engines do that. You should never run into a scenario where you need to break this relation, even for artistic purposes. I'm not saying that light sources in Cycles need to break how shadows relate to size, I'm saying that it would be nice to have an option for point lights (and by extension spotlights) that allows Cycles to not treat them as a sphere.
1.1 MiB
1.4 MiB
1.4 MiB

Don't know how easy it would be to achieve, but having a "softness" slider would be the best of two world, so a slider going from the hard 4.0 light to the soft 3.6 light would be nice (and preferably also having the glossy reflection follow that instead of the disconnected behaviour in 3.6).

Don't know how easy it would be to achieve, but having a "softness" slider would be the best of two world, so a slider going from the hard 4.0 light to the soft 3.6 light would be nice (and preferably also having the glossy reflection follow that instead of the disconnected behaviour in 3.6).

When I consider it more, it does seem like a lot of the cases where a point light is used like this could be achieved pretty equally with other light sources. It really just makes it slightly more annoying depending on your scene.
I’m mostly worried about the loss of compatibility with older versions, which is why i feel having both options would be a necessary change.
I don’t see the behavior of lights as only motivated by physical behavior, but also artistic usability and consistency. I this case, the changed behavior only satisfies the first.

When I consider it more, it does seem like a lot of the cases where a point light is used like this could be achieved pretty equally with other light sources. It really just makes it slightly more annoying depending on your scene. I’m mostly worried about the **loss of compatibility** with older versions, which is why i feel having both options would be a necessary change. I don’t see the behavior of lights as only motivated by physical behavior, but also artistic usability and consistency. I this case, the changed behavior only satisfies the first.
Author

Here's another case where the old behavior also made sense for artistic reasons, and where simply making lights smaller (or using area lights for that matter) isn't an option:
image

Meanwhile here's the new behavior as it stands:
image

Everything essentially becomes overblown here, and the new falloff makes the background much less interesting.

Here's another case where the old behavior also made sense for artistic reasons, and where simply making lights smaller (or using area lights for that matter) isn't an option: ![image](/attachments/74b36812-ce31-4d50-9d3d-3ebb1193ff11) Meanwhile here's the new behavior as it stands: ![image](/attachments/dfe61bd7-0e51-4fcd-962a-e52eb3d4edcd) Everything essentially becomes overblown here, and the new falloff makes the background much less interesting.
1.4 MiB
1.3 MiB

Since this change also affects spot lamps, one common example would be a street lamp. This sort of setup is very commonly used and while most street lamps are small and produce harsh shadows, some have coating on the glass that act as diffuser making the shadows softer, as blender does not have a concept of diffusers increasing the light size is the only way to get softer shadows, resulting in this. In this example the spot lamp could be replaced by area lamp as they now have spread control, but they dont behave the same as a spot and I have generally found using spot lights is easier for cases like this.

image

Since this change also affects spot lamps, one common example would be a street lamp. This sort of setup is very commonly used and while most street lamps are small and produce harsh shadows, some have coating on the glass that act as diffuser making the shadows softer, as blender does not have a concept of diffusers increasing the light size is the only way to get softer shadows, resulting in this. In this example the spot lamp could be replaced by area lamp as they now have spread control, but they dont behave the same as a spot and I have generally found using spot lights is easier for cases like this. ![image](/attachments/dc8a1c57-3d4a-46b7-bdfe-71f1828e4bd6)
1.1 MiB

Got another example here. This is a wooden boat I made a while back where I comp in a flame on that chained ball and I used some point lights to exaggerate and help that flame a bit (while the white ball in the volume to the right is because of this change do ignore it for this example, it can be easily fixed in other ways).
The one on the left is 3.6 and looks good with no hard shadows because of that semibig and soft ball, whereas the 4.0 in the middle doesn't work with that hard cutoff and very ambienty light inside that radius. Of course this is not physically correct lighting, but I'm using that (and many other lights in the scene) in an artistic way to enhance features on this boat and the skeleton that's standing on it that would not look like this if I only lit it 100 physically correct with that flame that I later comped in.
lightvp.jpg
And while I'm not that bummed over this change I see why some people can be. I mean I can probably get something similar by cheating in other ways, but having this as an option or a slider to go between hard or soft lights would be nice :)

Got another example here. This is a wooden boat I made a while back where I comp in a flame on that chained ball and I used some point lights to exaggerate and help that flame a bit (while the white ball in the volume to the right is because of this change do ignore it for this example, it can be easily fixed in other ways). The one on the left is 3.6 and looks good with no hard shadows because of that semibig and soft ball, whereas the 4.0 in the middle doesn't work with that hard cutoff and very ambienty light inside that radius. Of course this is not physically correct lighting, but I'm using that (and many other lights in the scene) in an artistic way to enhance features on this boat and the skeleton that's standing on it that would not look like this if I only lit it 100 physically correct with that flame that I later comped in. ![lightvp.jpg](/attachments/0d6709b3-8acf-47a5-b662-bdb32ea9dec2) And while I'm not that bummed over this change I see why some people can be. I mean I can probably get something similar by cheating in other ways, but having this as an option or a slider to go between hard or soft lights would be nice :)

While I appreciate the new change, can see it's usefulness in certain circumstances, and understand that it is more "accurate"; it also completely eliminates a functionality and aesthetic that has been used and incorporated into projects and workflows for years (As demonstrated in this thread and the copious number of other bug reports citing this behaviour as undesirable); unilaterally demands that users spend extensive amounts of time updating any project prior to 4.0 that uses point and/or spot lights with no guarantee that we can achieve an identical effect, and forces users into a strictly photoreal rendering environment that goes directly counter to the entire ethos of Blender's flexibility and broad ranging use to this point. All for what, as far as I can tell, is a narrow minded belief that photorealism is inherently preferable and anyone not okay with that view does not hold a valid opinion and should be forced to reconfigure their workflows, styles and general relationship to creating in Blender to align to that view. I hope it goes without saying how utterly insulting that is to users who do not put photorealism on a holy pedestal.

The fact that this sort of change was pushed through without any consideration for the above is, at best, disappointing, and a spit in the face of every Blender artist that doesn't align to the narrow view of photorealistic superiority. Blender is a tool for creating art, among many other things, yes, but it is a tool for art, and this continued insistence that the only valid uses that should be supported are those judged by strictly photorealistic, reality based metrics is as disappointing as it is misguided. I applaud the efforts to push Blender's ability to pursue photorealism, but when it comes at the direct cost of tools and capabilities that have been present for years, without even a passing consideration to the users who use and rely on those tools and capabilities, it feels like a slap in the face for something that could have easily coexisted with existing tools.

I can only hope and ask that this decision be reconsidered, and the new point & spot light functionality are incorporated in a way that broadens Blender's usability instead of limiting it.

While I appreciate the new change, can see it's usefulness in certain circumstances, and understand that it is more "accurate"; it also completely eliminates a functionality and aesthetic that has been used and incorporated into projects and workflows for years (As demonstrated in this thread and the copious number of other bug reports citing this behaviour as undesirable); unilaterally demands that users spend extensive amounts of time updating any project prior to 4.0 that uses point and/or spot lights with no guarantee that we can achieve an identical effect, and forces users into a strictly photoreal rendering environment that goes directly counter to the entire ethos of Blender's flexibility and broad ranging use to this point. All for what, as far as I can tell, is a narrow minded belief that photorealism is inherently preferable and anyone not okay with that view does not hold a valid opinion and should be forced to reconfigure their workflows, styles and general relationship to creating in Blender to align to that view. I hope it goes without saying how utterly insulting that is to users who do not put photorealism on a holy pedestal. The fact that this sort of change was pushed through without any consideration for the above is, at best, disappointing, and a spit in the face of every Blender artist that doesn't align to the narrow view of photorealistic superiority. Blender is a tool for creating art, among many other things, yes, but it is a tool for art, and this continued insistence that the only valid uses that should be supported are those judged by strictly photorealistic, reality based metrics is as disappointing as it is misguided. I applaud the efforts to push Blender's ability to pursue photorealism, but when it comes at the direct cost of tools and capabilities that have been present for years, without even a passing consideration to the users who use and rely on those tools and capabilities, it feels like a slap in the face for something that could have easily coexisted with existing tools. I can only hope and ask that this decision be reconsidered, and the new point & spot light functionality are incorporated in a way that broadens Blender's usability instead of limiting it.
Member

I will pass this on to Cycles & Rendering devs for consideration

CC @brecht
CC @weizhen

I will pass this on to `Cycles & Rendering` devs for consideration CC @brecht CC @weizhen
Contributor

I really hope we won't go back to stone age of non physically based rendering it. People have been placing huge light sources intersecting geometry in their scene and abuse buggy behavior for "artistic" purposes. And now complain that the bug was fixed.

Just start doing the lighting the right way. It's not hard.

I'm not saying that light sources in Cycles need to break how shadows relate to size, I'm saying that it would be nice to have an option for point lights (and by extension spotlights) that allows Cycles to not treat them as a sphere.

Not treating point lights as spheres is exactly breaking how shadows relate to size. The point light, therefore infinitely small point in space could only ever have super sharp, infinitely small penumbra shadow.

I really hope we won't go back to stone age of non physically based rendering it. People have been placing huge light sources intersecting geometry in their scene and abuse buggy behavior for "artistic" purposes. And now complain that the bug was fixed. Just start doing the lighting the right way. It's not hard. > I'm not saying that light sources in Cycles need to break how shadows relate to size, I'm saying that it would be nice to have an option for point lights (and by extension spotlights) that allows Cycles to not treat them as a sphere. Not treating point lights as spheres is exactly breaking how shadows relate to size. The point light, therefore infinitely small point in space could only ever have super sharp, infinitely small penumbra shadow.
Author

I really hope we won't go back to stone age of non physically based rendering it.

We're not saying the new behavior should be removed (it makes sense why it exists), we're saying that either an option for the old behavior (that wouldn't be default) should be added or a slider for softness that would also return the old behavior as Gurra suggested.

People have been placing huge light sources intersecting geometry in their scene and abuse buggy behavior for "artistic" purposes. And now complain that the bug was fixed.

Just start doing the lighting the right way. It's not hard.

If by "the right way" you mean the photorealistic way, that's a pretty bold thing to claim. There are just as many non-photorealistic rendering artists in the Blender community are there photorealistic ones, so simply shunning non-photorealistic rendering as "wrong" is pretty narrow minded. If a feature is developed without consideration for those that don't do photorealistic rendering, then what's the point of advertising Blender as a powerful tool for the non-photorealistic artists out there?

> I really hope we won't go back to stone age of non physically based rendering it. We're not saying the new behavior **should be removed** (it makes sense why it exists), we're saying that either **an option for the old behavior (that wouldn't be default) should be added** or **a slider for softness that would also return the old behavior** as Gurra suggested. > People have been placing huge light sources intersecting geometry in their scene and abuse buggy behavior for "artistic" purposes. And now complain that the bug was fixed. > > Just start doing the lighting the right way. It's not hard. If by "the right way" you mean the photorealistic way, that's a pretty bold thing to claim. There are just as many non-photorealistic rendering artists in the Blender community are there photorealistic ones, so simply shunning non-photorealistic rendering as "wrong" is pretty narrow minded. If a feature is developed without consideration for those that don't do photorealistic rendering, then what's the point of advertising Blender as a powerful tool for the non-photorealistic artists out there?
Contributor

I really hope we won't go back to stone age of non physically based rendering it.

We're not saying the new behavior should be removed (it makes sense why it exists), we're saying that either an option for the old behavior (that wouldn't be default) should be added or a slider for softness that would also return the old behavior as Gurra suggested.

Cluttering UI with these kinds of buttons that intentionally break something is about the worst thing that can happen. It returns us back to really ugly days of renderers like Mental Ray or Brazil RS.

People have been placing huge light sources intersecting geometry in their scene and abuse buggy behavior for "artistic" purposes. And now complain that the bug was fixed.

Just start doing the lighting the right way. It's not hard.

If by "the right way" you mean the photorealistic way, that's a pretty bold thing to claim. There are just as many non-photorealistic rendering artists in the Blender community are there photorealistic ones, so simply shunning non-photorealistic rendering as "wrong" is pretty narrow minded. If a feature is developed without consideration for those that don't do photorealistic rendering, then what's the point of advertising Blender as a powerful tool for the non-photorealistic artists out there?

There are many other renderers used for NPR that don't have this kind of control. Even in modern game engines. There's nothing about abusing buggy point light behavior that's artistic. Even for NPR rendering, you should consider what it is that lights your scene. What kind of light source are you trying to illuminate your scene by.

If you need very soft shadows coming out of the window then simply consider using environment light for that. On your picture examples, you don't provide anything that can even showcase the problem given how messy your lighting is in the first place. You could achieve the random lighting on your example picture in many other ways that don't require separation of light size and shadow softness. You just got used to a bug and you are now unwilling to give up the buggy behavior.

> > I really hope we won't go back to stone age of non physically based rendering it. > > We're not saying the new behavior **should be removed** (it makes sense why it exists), we're saying that either **an option for the old behavior (that wouldn't be default) should be added** or **a slider for softness that would also return the old behavior** as Gurra suggested. Cluttering UI with these kinds of buttons that intentionally break something is about the worst thing that can happen. It returns us back to really ugly days of renderers like Mental Ray or Brazil RS. > > People have been placing huge light sources intersecting geometry in their scene and abuse buggy behavior for "artistic" purposes. And now complain that the bug was fixed. > > > > Just start doing the lighting the right way. It's not hard. > > If by "the right way" you mean the photorealistic way, that's a pretty bold thing to claim. There are just as many non-photorealistic rendering artists in the Blender community are there photorealistic ones, so simply shunning non-photorealistic rendering as "wrong" is pretty narrow minded. If a feature is developed without consideration for those that don't do photorealistic rendering, then what's the point of advertising Blender as a powerful tool for the non-photorealistic artists out there? There are many other renderers used for NPR that don't have this kind of control. Even in modern game engines. There's nothing about abusing buggy point light behavior that's artistic. Even for NPR rendering, you should consider what it is that lights your scene. What kind of light source are you trying to illuminate your scene by. If you need very soft shadows coming out of the window then simply consider using environment light for that. On your picture examples, you don't provide anything that can even showcase the problem given how messy your lighting is in the first place. You could achieve the random lighting on your example picture in many other ways that don't require separation of light size and shadow softness. You just got used to a bug and you are now unwilling to give up the buggy behavior.
Contributor

Since this change also affects spot lamps, one common example would be a street lamp. This sort of setup is very commonly used and while most street lamps are small and produce harsh shadows, some have coating on the glass that act as diffuser making the shadows softer, as blender does not have a concept of diffusers increasing the light size is the only way to get softer shadows, resulting in this. In this example the spot lamp could be replaced by area lamp as they now have spread control, but they dont behave the same as a spot and I have generally found using spot lights is easier for cases like this.

image

Here you would generally use Disc area lights with reduced spread value. But I agree that spot light should provide same shape options as area lights (the source shape should not be limited to just sphere):
image

> Since this change also affects spot lamps, one common example would be a street lamp. This sort of setup is very commonly used and while most street lamps are small and produce harsh shadows, some have coating on the glass that act as diffuser making the shadows softer, as blender does not have a concept of diffusers increasing the light size is the only way to get softer shadows, resulting in this. In this example the spot lamp could be replaced by area lamp as they now have spread control, but they dont behave the same as a spot and I have generally found using spot lights is easier for cases like this. > > ![image](/attachments/dc8a1c57-3d4a-46b7-bdfe-71f1828e4bd6) Here you would generally use Disc area lights with reduced spread value. But I agree that spot light should provide same shape options as area lights (the source shape should not be limited to just sphere): ![image](/attachments/23d8f371-9d2b-47cb-baa0-9e61da458570)
706 KiB
Brecht Van Lommel added
Status
Confirmed
Type
To Do
and removed
Status
Needs Info from Developers
Type
Report
labels 2023-11-01 18:01:07 +01:00

We can look into adding falloff options to get something similar to the previous behavior, either using nodes or a native option on the light. But this was an intentional change that we are not going to change in 4.0, falloff options would be for 4.1 or later.

We can look into adding falloff options to get something similar to the previous behavior, either using nodes or a native option on the light. But this was an intentional change that we are not going to change in 4.0, falloff options would be for 4.1 or later.

I really hope we won't go back to stone age of non physically based rendering it. People have been placing huge light sources intersecting geometry in their scene and abuse buggy behavior for "artistic" purposes. And now complain that the bug was fixed.

Just start doing the lighting the right way. It's not hard.

I'm not saying that light sources in Cycles need to break how shadows relate to size, I'm saying that it would be nice to have an option for point lights (and by extension spotlights) that allows Cycles to not treat them as a sphere.

Not treating point lights as spheres is exactly breaking how shadows relate to size. The point light, therefore infinitely small point in space could only ever have super sharp, infinitely small penumbra shadow.

I do not see where treating spotlights not as spheres would be going back to the stone age. As long as a spotlight exists in Blender, it still is this "stone age" you are talking about. Because in real life a light source does not simply shine in one direction with a certain angle.

In reality this is created by the shape of the surrounding lamp. And in real life, a small point light inside a lamp can create a spotlight shining in a certain direction with a certain angle and with a diameter much larger than the point light. But in Blender this surrounding lamp mesh now needs to cover up a whole sphere, which is not how the lamp needs to be designed in reality.

I admit though that the 4.0 spotlight is better at creating the cone of light according to the radius/diameter.

Just to make this clear: I totally agree with the new behavior making much more sense for Point lights, however Spot lights are somewhat a cheat to replicate how real spot lights work, without the need for a mirror and a focusing lens etc. to build it physically accurate, so it is completely different from the Point light.

> I really hope we won't go back to stone age of non physically based rendering it. People have been placing huge light sources intersecting geometry in their scene and abuse buggy behavior for "artistic" purposes. And now complain that the bug was fixed. > > Just start doing the lighting the right way. It's not hard. > > > I'm not saying that light sources in Cycles need to break how shadows relate to size, I'm saying that it would be nice to have an option for point lights (and by extension spotlights) that allows Cycles to not treat them as a sphere. > > Not treating point lights as spheres is exactly breaking how shadows relate to size. The point light, therefore infinitely small point in space could only ever have super sharp, infinitely small penumbra shadow. I do not see where treating spotlights *not* as spheres would be going back to the stone age. As long as a spotlight exists in Blender, it still is this "stone age" you are talking about. Because in real life a light source does not simply shine in one direction with a certain angle. In reality this is created by the shape of the surrounding lamp. And in real life, a small point light inside a lamp can create a spotlight shining in a certain direction with a certain angle and with a diameter much larger than the point light. But in Blender this surrounding lamp mesh now needs to cover up a whole sphere, which is not how the lamp needs to be designed in reality. I admit though that the 4.0 spotlight is better at creating the cone of light according to the radius/diameter. Just to make this clear: I totally agree with the new behavior making much more sense for Point lights, however Spot lights are somewhat a cheat to replicate how real spot lights work, without the need for a mirror and a focusing lens etc. to build it physically accurate, so it is completely different from the Point light.
Philipp Oeser changed title from Point Lights have Harsh Edges in Blender 4.0 to Point/Spot Lights have Harsh Edges in Blender 4.0 (constant inside their radius) 2023-11-20 13:40:33 +01:00

We can look into adding falloff options to get something similar to the previous behavior, either using nodes or a native option on the light. But this was an intentional change that we are not going to change in 4.0, falloff options would be for 4.1 or later.

Please do, it's really annoying how photorealism at all costs is being pushed so aggressively. There's nothing wrong with photorealism, but I beg you and the other developers to consider that it's not the only workflow, and chipping away at a non-photorealistic workflow is harmful to many Blender users. Thanks for your consideration!

> We can look into adding falloff options to get something similar to the previous behavior, either using nodes or a native option on the light. But this was an intentional change that we are not going to change in 4.0, falloff options would be for 4.1 or later. Please do, it's really annoying how photorealism at all costs is being pushed so aggressively. There's nothing wrong with photorealism, but I beg you and the other developers to consider that it's not the *only* workflow, and chipping away at a non-photorealistic workflow is harmful to many Blender users. Thanks for your consideration!

This is a volume cube with a spotlight in 3.6 version
image

Same but 4.0.1 version
image

This is a fake fix I did with a light path node, may be helpful, you wont get that harsh edge on any object.
image

This is a volume cube with a spotlight in 3.6 version ![image](/attachments/3462adc1-ef5c-449c-a836-d8fdeac6e17e) Same but 4.0.1 version ![image](/attachments/311dfcf9-a439-4bb2-a838-14464b5f71bf) This is a fake fix I did with a light path node, may be helpful, you wont get that harsh edge on any object. ![image](/attachments/beb0ab08-4b0d-4570-bf21-d04afdea7d50)
836 KiB
960 KiB
921 KiB

@Alejandro-Barkovsky So how can we 'fake' fix this with a light path node. I am a bit new to blender, and I don't have the experience on how to do it, Im trying to finish a project (tutorial) but Im having the issue with the spot light, and I haven't found anyone that knows how to fix it, except you. I would really appreciate your help, thanks.

@Alejandro-Barkovsky So how can we 'fake' fix this with a light path node. I am a bit new to blender, and I don't have the experience on how to do it, Im trying to finish a project (tutorial) but Im having the issue with the spot light, and I haven't found anyone that knows how to fix it, except you. I would really appreciate your help, thanks.
587 KiB

Unfortunately this is an expected behavior of Blender 4.0. We should have an option to disable the sphere representation of the light.

Unfortunately this is an expected behavior of Blender 4.0. We should have an option to disable the sphere representation of the light.

You blew it with your new light display system.
In a word ; I want to throw up. :(

You blew it with your new light display system. In a word ; I want to throw up. :(

Hell yeah, please fix that, i have some scene with this problem, im happy (not realy for you sorry) that im am not the only one with this problem. This new lighting system is good idea, but a least don't totaly replace the old One, i miss it :/

Hell yeah, please fix that, i have some scene with this problem, im happy (not realy for you sorry) that im am not the only one with this problem. This new lighting system is good idea, but a least don't totaly replace the old One, i miss it :/

If you look at the notes from the rendering meeting a week ago you'll see that "Brecht works on an option to get back the old, non physically based falloff for 4.1" :)

If you look at the notes from the [rendering meeting](https://devtalk.blender.org/t/2024-01-23-render-cycles-meeting/33059) a week ago you'll see that "Brecht works on an option to get back the old, non physically based falloff for 4.1" :)

That would be awesome !

That would be awesome !

How long we will have to wait untill blender 4.1 doe?

How long we will have to wait untill blender 4.1 doe?

@Alejandro-Barkovsky So how can we 'fake' fix this with a light path node. I am a bit new to blender, and I don't have the experience on how to do it, Im trying to finish a project (tutorial) but Im having the issue with the spot light, and I haven't found anyone that knows how to fix it, except you. I would really appreciate your help, thanks.

Sorry about the late response, play with those nodes i added below, as you can see there isnt harsh lights, play with the color ramp to soften the radius of your light. btw cool scene sir.

> @Alejandro-Barkovsky So how can we 'fake' fix this with a light path node. I am a bit new to blender, and I don't have the experience on how to do it, Im trying to finish a project (tutorial) but Im having the issue with the spot light, and I haven't found anyone that knows how to fix it, except you. I would really appreciate your help, thanks. Sorry about the late response, play with those nodes i added below, as you can see there isnt harsh lights, play with the color ramp to soften the radius of your light. btw cool scene sir.

@Alejandro-Barkovsky Thank you for the help, but Ive tried and couldnt get yet the result I wanted. I gess ill have to wait until blender 4.1 is out and they add the option to have the old light spot back

@Alejandro-Barkovsky Thank you for the help, but Ive tried and couldnt get yet the result I wanted. I gess ill have to wait until blender 4.1 is out and they add the option to have the old light spot back
Blender Bot added
Status
Resolved
and removed
Status
Confirmed
labels 2024-02-07 19:07:30 +01:00

I have good news and bad news on this topic.

The good news is that the issue has been resolved. The bad news is that we have to wait for version 4.2.

I found a workaround for the issue. This can help you solve it or at least manage it, as demonstrated in the video I created (link below).

[https://youtube.com/live/XoW3GxS7W2Y]

I have good news and bad news on this topic. The good news is that the issue has been resolved. The bad news is that we have to wait for version 4.2. I found a workaround for the issue. This can help you solve it or at least manage it, as demonstrated in the video I created (link below). [https://youtube.com/live/XoW3GxS7W2Y]
Author

The good news is that the issue has been resolved. The bad news is that we have to wait for version 4.2.

The PR was merged in the 4.1 release branch, so it's coming in 4.1

> The good news is that the issue has been resolved. The bad news is that we have to wait for version 4.2. The [PR was merged in the 4.1 release branch](https://projects.blender.org/blender/blender/pulls/117832), so it's coming in 4.1

I'm hoping for the stable version, but not in 4.1 alpha yet.
The option was added in 4.2 Alpha, as you see in this screenshot.

I'm hoping for the stable version, but not in 4.1 alpha yet. The option was added in 4.2 Alpha, as you see in this screenshot.

It is already in 4.1 beta.

It is already in 4.1 beta.

It is already in 4.1 beta.

Appreciate your work Brecht ❤

> It is already in 4.1 beta. Appreciate your work Brecht ❤
Sign in to join this conversation.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
17 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#114241
No description provided.