Per-pixel translucent lighting not using light falloff distance

Hello,

I’ve recently started using the new per-pixel translucent lighting engine in 4.8, and I believe I’ve discovered a bug. It looks as though the specular reflections are not considering the falloff distance of point lights. In my scene I have a water plane, which, as you can see in the image, is reflecting a red light. The only red light in my scene (and I verified it was caused by this light by changing the colour) is more than 20,000 units above the surface of the water - but only has a 1000 unit falloff radius.

This is very inconvenient, as fine control over the range of lights is absolutely critical for my use case. Am I just doing something wrong, or is this a bug that needs fixing?

EDIT: After a bit more testing, it seems this bug only occurs if a light is given a source radius. If the light is left as a regular point light, it seems to work as expected.

Hey Hoeloe,

What shader are you using for your water? Is it a default Material shader or one that you have made?

If it is not the default try utilizing one of the defaults and test to see whether it is the light or the material itself behaving strangely.

Thanks,

As far as I’m aware, none of the defaults make use of the per-pixel translucency shading. The shader itself is a slightly modified version of the Lake Water shader included in the water planes package. The only modifications I’ve made are to use per-pixel translucency with a depth fade node and fresnel. There is nothing particularly strange about the shader aside from using per-pixel lighting, and even if there were, it shouldn’t be performing any calculation on this light. I’m pretty certain the problem is with the per-pixel translucent lighting, since it only appears in the translucent specular reflection (i.e. a feature unique to this lighting model).

Interestingly, the problem seems to have arbitrarily solved itself. I’m not sure what the problem was originally, but I’ve just reset everything to how it was when I took that screenshot, and there’s no red specular component on the water any more. How odd.

EDIT: I’ll reopen this question if the problem reoccurs at any point.

Ok,

I have recreated something similar to what you have with the Lake shader a pint light and a simple plane. I am not getting the same result that you are. I am attaching my test project so you can go through and test your build against mine. I do not know the modifications that you made but as you said this is more of a lighting issue than a material one.

.
link text

It seems it’s an intermittent problem. I tried replacing the light and set up the scene exactly as it was when I took the screenshots with no problems. I’m not sure what was causing it, but it’s certainly not part of the shader, since I didn’t edit that. It seems to be one of those really difficult to fix bugs that only occurs some of the time for no readily apparent reason. I will let you know if it occurs again.

Since this is an experimental feature, there are some gotchas. If you hover over that tab that says Surface PerIxel, just the grey box with the text. There will be an information window out to the right. Down at the bottom it says: " requires r.ForwardLighting to be 1.

So in order to actually enable this feature, since there is no check box to toggle the feature on and off, is to bring up your command prompt inside of UE4 by hitting the `/~ key.

There type in r.ForwardLighting 1.

If is very important to have a space after the lighting and before the 1.

to turn this feature back off, if you switch the Lighting mode off, type this function in again except for instead of the 1 type a 0.

I already did that. The feature is absolutely working. The error I showed was the specular reflection picking up a light it shouldn’t have been. Had it not been working, that would not have appeared at all.

So I’m reopening this because I appear to be getting a similar and probably related problem. I now have a glass material with a dirt mask over it. The dirt mask affects the roughness, opacity, and base colour of the glass.

This screenshot shows the material from the same angle. On the left is the regular translucent “surface” shading model. On the right is the “per pixel” variant. The “per pixel” model does not respond to any lights in the scene, and remains black regardless of where I put the lights. Aside from the shading model, the material is identical in both screenshots.

Okay, I’ve just used the “r.ForwardLighting” command to check, and the console is reporting back that this value is “0”, despite me setting it both in the .ini file and the console.

EDIT: It seems that the issue was caused by the update to 4.8.2 reverting my .ini file changes. I’ve changed this back and the material works as it should now.

I use r.ForwardLighting=1 and Per-pixel translucent lighting to make my water material a little more shiny (catches highlights).

However, enabling ‘Per-pixel translucent lighting’ for my ocean water material prevents the water from receiving shadows.

Hello ash22,

If you would provide screenshots of your Ocean Water material. Also if you would provide screenshots of before and after enabling r.FowradLighting=1 and Per-PIxel translucent lighting and where your water is not receiving shadows.

See screenshots below.

The ocean material is based on the Water Plane - Translucent water Demo in the [Learn] section of the Epic Launcher.

Btw,

When Surface Translucency Volume is enabled Window->Stats says there are 16/16 texture samplers in use.

When Surface Per Pixel is enabled (missing translucent shadows) Window->Stats says there are 11/16 texture samplers in use.

So it appears the Surface Per Pixel Lighting mode is skipping
some default lighting procedure that would normally process shadow data
in non-PerPixel modes? (guessing)

ok, thanks.

Hey ash22,

I ran the same experiment as you and I was able to see the same results. I will be investigating this further to determine whether this is expected behavior with the (experimental) Surface PerPixel lighting mode for materials.

Understood.
Thanks , I’ll give it a try.

You said ‘a couple of workarounds’ …are there two optional workarounds?
I’m not sure about duplicating a large ocean (world displaced, not a ‘plane’) mesh for the shadow. It may be the only solution for now, but if there is a second workaround I’d be interested in knowing about it as a possible plan-b.

Hello ash22,

I believe you will be interested in this post from the release notes.

As it is still flagged as experimental there are still some features that are not supported with this Lighting mode. This is from our 4.8 release notes and the light mode does not supported shadows within our latest version of UE4.

There are a couple of workarounds that include putting a plane with the same material set to Volumetric light mode.

Thanks for reporting this to us, however, this is expected behavior with the SurfacePerPixelLighting.

The only other I can really think of is to not use the PerPixelLighting light mode. Maybe only have a plane where you want to see your shadows cast. If there are certain areas you do not wish a shadow to be cast then you could simply not have a plane there. These are the only viable workarounds I can even think of. You could perhaps have an almost glass like transparent material with the volume enabled under the waves. This might look a little funny though. You would have to experiment with that.

Ok, I guess the first workaround is the best option for now.
Thanks.

“There are a couple of workarounds that include putting a plane with the same material set to Volumetric light mode.”

I gave it a try but it didn’t work unfortunately.
I tried all the settings (Volumetric Dir, Volumetric Non Dir, SurfaceTransVol),
played with the mesh ordering in the BP and even toggled the main/custom [x] pass options on each mesh. There was no way I could make the two mesh material effects appear (blend) at the same time so it’s either one or the other.

Unless there’s something else I need to do, I’ll just have to wait and hope the perpixel+shadows experiment gets updated in the future.