Spot light no longer projecting an image texture in Blender 3 #93565

Closed
opened 2021-12-02 12:15:01 +01:00 by Vladimir · 33 comments

System Information
Operating system: Linux-5.15.5-2-MANJARO-x86_64-with-glibc2.33 64 Bits
Graphics card: Mesa DRI Intel(R) HD Graphics 4600 (HSW GT2) Intel Open Source Technology Center 4.5 (Core Profile) Mesa 21.2.5

Blender Version
Broken: 3.1
Worked: 2.93.6
Caused by cb334428b0

Short description of error

Spot light no longer projecting an image texture in Blender 3. When I switch light from spot light to Point light then it working. But in Blender 2.93 both lights working well.

Blender 3. Point light
Projector1.png

Blender 3. Spot light
Projector2.png

Blender 2.9 Spot light
Projector3.png

Exact steps for others to reproduce the error

Download and open the example file: Projector.blend

**System Information** Operating system: Linux-5.15.5-2-MANJARO-x86_64-with-glibc2.33 64 Bits Graphics card: Mesa DRI Intel(R) HD Graphics 4600 (HSW GT2) Intel Open Source Technology Center 4.5 (Core Profile) Mesa 21.2.5 **Blender Version** Broken: 3.1 Worked: 2.93.6 Caused by cb334428b0 **Short description of error** Spot light no longer projecting an image texture in Blender 3. When I switch light from spot light to Point light then it working. But in Blender 2.93 both lights working well. Blender 3. Point light ![Projector1.png](https://archive.blender.org/developer/F12678893/Projector1.png) Blender 3. Spot light ![Projector2.png](https://archive.blender.org/developer/F12678897/Projector2.png) Blender 2.9 Spot light ![Projector3.png](https://archive.blender.org/developer/F12678901/Projector3.png) **Exact steps for others to reproduce the error** Download and open the example file: [Projector.blend](https://archive.blender.org/developer/F12678927/Projector.blend)
Author

Added subscriber: @Wovchick

Added subscriber: @Wovchick

#95392 was marked as duplicate of this issue

#95392 was marked as duplicate of this issue

#95375 was marked as duplicate of this issue

#95375 was marked as duplicate of this issue

#95150 was marked as duplicate of this issue

#95150 was marked as duplicate of this issue

#93676 was marked as duplicate of this issue

#93676 was marked as duplicate of this issue

Changed status from 'Needs Triage' to: 'Confirmed'

Changed status from 'Needs Triage' to: 'Confirmed'
Member

Added subscriber: @PratikPB2123

Added subscriber: @PratikPB2123

Added subscribers: @sherholz, @brecht, @ThomasDinges

Added subscribers: @sherholz, @brecht, @ThomasDinges

Issue introduced by cb334428b0 @sherholz @brecht Can you please take a look?

Issue introduced by cb334428b0 @sherholz @brecht Can you please take a look?

Hi Thomas,

The problem is related to the fix of the spotlight.
Previously the spotlight with a radius was represented by an oriented disk (always oriented towards the illuminated point).
Now the spotlight is a disk with a normal oriented to the direction of the spotlight (fixed normal).

The problem seems to be that the shader graph uses the normal - which is now fixed to the spotlight direction - for the uv calculation.
Is there a reason why the texture projection is not using the uv space of the light source?

Hi Thomas, The problem is related to the fix of the spotlight. Previously the spotlight with a radius was represented by an oriented disk (always oriented towards the illuminated point). Now the spotlight is a disk with a normal oriented to the direction of the spotlight (fixed normal). The problem seems to be that the shader graph uses the normal - which is now fixed to the spotlight direction - for the uv calculation. Is there a reason why the texture projection is not using the uv space of the light source?

Hi Sebastian,
do you have an example, how it should be done now in the shader graph? Changing to the UV Output does not solve it for me. :)

By the way: the provided setup can be simplified for easier debugging, just connect the Texture Coordinate directly to the Image Texture, leaving the nodes in between out.

Hi Sebastian, do you have an example, how it should be done now in the shader graph? Changing to the UV Output does not solve it for me. :) By the way: the provided setup can be simplified for easier debugging, just connect the Texture Coordinate directly to the Image Texture, leaving the nodes in between out.

Added subscriber: @Nurb2Kea

Added subscriber: @Nurb2Kea

System Information
Operating system: macOS-12.0.1-x86_64-i386-64bit 64 Bits
Graphics card: AMD Radeon Pro 5700 XT OpenGL Engine ATI Technologies Inc. 4.1 ATI-4.7.29

Blender Version
Broken: version: 3.1.0 Alpha, branch: master, commit date: 2021-12-03 22:24, hash: d5920744f4 ((last 3 versions and still continuing)
Worked: (version: 3.0.0 stable, branch: master, commit date: 2021-12-02 18:35, hash: f1cca30557

Short description of error
Light 'normal' texture coordinates in nodes for spotlight not working anymore like it does in blender 3.00 as expected.
You have to switch to reflection in texture coordinates of the light nodes to get a projection from the light.
(Not sure but was it always possible to archive this with the other lights too?)

Exact steps for others to reproduce the error
Open attached file in blender 3.0.0 stable and switch to rendered viewport. (you'll see window shades shadows).

Then open the same blend file in any blender version 3.1, and you see that it's not working anymore, unless you switch the texture coordinates of the light to Reflection.
(And then you can't change the lights z rotation under item-panel to change angle/direction of the shades light projection. )

But the main problem is the texture coordinates for the lights aren't working as in blender 3.0.0 stable anymore

Thanks in advance

untitled.blend

System Information Operating system: macOS-12.0.1-x86_64-i386-64bit 64 Bits Graphics card: AMD Radeon Pro 5700 XT OpenGL Engine ATI Technologies Inc. 4.1 ATI-4.7.29 Blender Version Broken: version: 3.1.0 Alpha, branch: master, commit date: 2021-12-03 22:24, hash: d5920744f4 ((last 3 versions and still continuing) Worked: (version: 3.0.0 stable, branch: master, commit date: 2021-12-02 18:35, hash: f1cca3055776 Short description of error Light 'normal' texture coordinates in nodes for spotlight not working anymore like it does in blender 3.00 as expected. You have to switch to reflection in texture coordinates of the light nodes to get a projection from the light. (Not sure but was it always possible to archive this with the other lights too?) Exact steps for others to reproduce the error Open attached file in blender 3.0.0 stable and switch to rendered viewport. (you'll see window shades shadows). Then open the same blend file in any blender version 3.1, and you see that it's not working anymore, unless you switch the texture coordinates of the light to Reflection. (And then you can't change the lights z rotation under item-panel to change angle/direction of the shades light projection. ) But the main problem is the texture coordinates for the lights aren't working as in blender 3.0.0 stable anymore Thanks in advance [untitled.blend](https://archive.blender.org/developer/F12704578/untitled.blend)

Hi Thomas and Guido,

I looked at the problem and I can replicate it.

The questions which come to my mind are:

  • what is the intended behavior of the Texture->normal attribute.
Or being more specific what is the normal of a sphere, spot, area/rect light.
  • what is the intended way of texturing these light sources.

For the first.
Geometrically speaking, the normal of a sphere is always facing the observer,
the normal of the area light is orthogonal to the area surface and since the spotlight - at least now - is represented by a disk with a fixed orientation, the normal is also fixed and orthogonal to the disk.

Previously the normal value for the spotlight was set to the incoming direction.

@brecht : Should this be the intended behavior? By doing so it would not be possible to texture an area light.

This brings us to second.
What should be the universal way to texture virtual light sources?
Since the previous way only worked for spheres and spotlights, would it be preferable to look for a generic way?

I tried a similar approach as mentioned by Guido. When taking the Geometry Node and using the incoming attribute, the projection works again.
Unfortunately, the incoming direction is defined in the global coordinate system and not the local one of the light source.
As a result, the projection does not consider transforms (e.g., rotations of the light source).

I could revert the changes to the spotlight so that it reacts similar as before, but is this actually the intended behavior, or do we need a general solution that also works for area lights (e.g., adding a local incoming attribute) ?

Hi Thomas and Guido, I looked at the problem and I can replicate it. The questions which come to my mind are: - what is the intended behavior of the Texture->normal attribute. ``` Or being more specific what is the normal of a sphere, spot, area/rect light. ``` - what is the intended way of texturing these light sources. For the first. Geometrically speaking, the normal of a sphere is always facing the observer, the normal of the area light is orthogonal to the area surface and since the spotlight - at least now - is represented by a disk with a fixed orientation, the normal is also fixed and orthogonal to the disk. Previously the normal value for the spotlight was set to the incoming direction. @brecht : Should this be the intended behavior? By doing so it would not be possible to texture an area light. This brings us to second. What should be the universal way to texture virtual light sources? Since the previous way only worked for spheres and spotlights, would it be preferable to look for a generic way? I tried a similar approach as mentioned by Guido. When taking the Geometry Node and using the incoming attribute, the projection works again. Unfortunately, the incoming direction is defined in the global coordinate system and not the local one of the light source. As a result, the projection does not consider transforms (e.g., rotations of the light source). I could revert the changes to the spotlight so that it reacts similar as before, but is this actually the intended behavior, or do we need a general solution that also works for area lights (e.g., adding a local incoming attribute) ?

To be honest, if you can make it work for all lights and that it works with transforms than it's fine to me.
That's how I learned it since 25 years ago. You have the textured light that can be moved, rotated, etc. including rotating z axis of the light to not have to move the light itself.

That was the trick for years to not have to build a shadow scene for the shadows coming through a window...for example.

Also I'm not restricted to spotlights. But that was the only one & you can focus the textured light so the shadows are blurry or sharp on the ground.
So you are the ones to choose the right way for the future + mabe keeping abilities.
If you decide another way that fit's better with light linking, I'm more than fine with it.

To be honest, if you can make it work for all lights and that it works with transforms than it's fine to me. That's how I learned it since 25 years ago. You have the textured light that can be moved, rotated, etc. including rotating z axis of the light to not have to move the light itself. That was the trick for years to not have to build a shadow scene for the shadows coming through a window...for example. Also I'm not restricted to spotlights. But that was the only one & you can focus the textured light so the shadows are blurry or sharp on the ground. So you are the ones to choose the right way for the future + mabe keeping abilities. If you decide another way that fit's better with light linking, I'm more than fine with it.

I think the best solution may be to make Texture Coordinate > UV do something useful for every light. Currently it's only useful for meshes / hair, since it's based on looking up a UV attribute.

Texture Coordinate > Normal I think makes sense to be the actual normal. A local incoming attribute is probably a bit obscure to guess for users.

I think the best solution may be to make Texture Coordinate > UV do something useful for every light. Currently it's only useful for meshes / hair, since it's based on looking up a UV attribute. Texture Coordinate > Normal I think makes sense to be the actual normal. A local incoming attribute is probably a bit obscure to guess for users.
Member

Added subscriber: @deadpin

Added subscriber: @deadpin

I discussed this further with @sherholz, we'll restore the old behavior so that the normal keeps working for texture coordinates, preserving compatibility. Making UV return something useful for lights can be done on top of that.

I discussed this further with @sherholz, we'll restore the old behavior so that the normal keeps working for texture coordinates, preserving compatibility. Making UV return something useful for lights can be done on top of that.

Marking as high priority so we remember to do this before 3.1 is released.

Marking as high priority so we remember to do this before 3.1 is released.

Sounds good to me, since light linking is coming and could maybe managed at the same time.
THX

Sounds good to me, since light linking is coming and could maybe managed at the same time. THX
Contributor

Added subscriber: @Raimund58

Added subscriber: @Raimund58

Just a short update.

I think I will find some time over the holidays to work on the fix,
so there should be a MR at the beginning of the year ready.

Just a short update. I think I will find some time over the holidays to work on the fix, so there should be a MR at the beginning of the year ready.
Member

Added subscribers: @MarcoHoo-3, @Alaska

Added subscribers: @MarcoHoo-3, @Alaska
Member

Added subscriber: @zanqdo

Added subscriber: @zanqdo
Member

As a workaround I found switching spotlights to Reflection coordinate instead of Normal works in 3.0 and 3.1

As a workaround I found switching spotlights to Reflection coordinate instead of Normal works in 3.0 and 3.1

Works only with still but when having an already set animation of the coordinates of the light, you can do it all over again...

Works only with still but when having an already set animation of the coordinates of the light, you can do it all over again...
Member

Added subscriber: @user1

Added subscriber: @user1
Member

I stand corrected, It's not 100% the same at high angles :(

Will wait for the normal fix

I stand corrected, It's not 100% the same at high angles :( Will wait for the normal fix

Hi,
I just submitted a patch to revert the normal behavior to the old one.
https://developer.blender.org/D13991

Hi, I just submitted a patch to revert the normal behavior to the old one. https://developer.blender.org/D13991

This issue was referenced by 01f1b51a2e

This issue was referenced by 01f1b51a2e75e7cd0ece3ecb622a3df907af726e

Can confirm it working on Build: version: 3.0.1, branch: master, commit date: 2022-01-25 17:19, hash: dc2d180181

Not sure when it get's ported to 3.1 - 3.2 !?

Screen Shot 2022-02-03 at 1.08.37 pm.jpg

Can confirm it working on Build: version: 3.0.1, branch: master, commit date: 2022-01-25 17:19, hash: `dc2d180181` Not sure when it get's ported to 3.1 - 3.2 !? ![Screen Shot 2022-02-03 at 1.08.37 pm.jpg](https://archive.blender.org/developer/F12843574/Screen_Shot_2022-02-03_at_1.08.37_pm.jpg)

Changed status from 'Confirmed' to: 'Resolved'

Changed status from 'Confirmed' to: 'Resolved'
Brecht Van Lommel self-assigned this 2022-02-03 14:51:21 +01:00

This issue was referenced by None@62824

This issue was referenced by None@62824
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
11 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#93565
No description provided.