Weird Difference Between SM5 and SM6?

Hey y’all! For context, my game has lighting which is entirely shader-based; no actual lights are placed in the scene, Lumen is not on, and everything shown comes from an Unlit master material. This is all visuals created with nodes in the material editor that are just plugged into the emissive channel! This is because the airplane environment has simple enough lighting for simply “faking” it to be a huge save on performance, file size, etc.

When I was testing how this airplane environment looked between SM5 and SM6, I noticed the following differences.

SM6:

SM5:

The bottom one is SM5. Notice how the shadowing on the wall has been changed, and the shadowing on the ceiling has disappeared altogether! For both of these fake shadowing effects, I used a Texture Sample of a chunk of shadow that I then tiled repeatedly by using the WorldPosition node for their UVs.

What about that is breaking when switching down to SM5? I haven’t been able to find something like that mentioned anywhere on the internet when comparing differences between 5 and 6.

Here is the node setup for one of these shadow effects, for extra context on what particularly here could be incompatible with SM5:

Any thoughts or feedback would be appreciated, even if you’re not entirely sure why this is happening. Thanks!

1 Like

The shader code change between 5 and 6 is pretty radical, not only in terms of sheer volume of instructions. It’s not really surprising the scenes look different.

If you tried this experiment in UE4, I think you would only see the emissive areas and nothing else. But because Lumen is used, the emissive is contributing to the lighting, and you are using the light pipeline.

Lumen isn’t used here either, my apologies for not clarifying that. But that’s such a huge compliment that it looks like Lumen regardless! xD

All of the materials shown here are Unlit, and I use a bunch of logic to fake it looking like real lighting even though it’s purely emissive color with no post-processing or anything. This is why I believe that my issue comes purely from my material logic, wether it’s one of the nodes working differently in SM5, texture sample UVs behaving differently, or maybe even Primitive Data variables behaving differently since I use those in some places. My struggle is just not knowing those specific differences between the shader models.

1 Like

I take that back, then. It looks pretty good :smiley:

Sorry, I don’t have any further info…

1 Like

All good!

1 Like

So, I figured this one out myself not long after, but I thought I’d update the thread just in case someone comes along who needs a niche solution like this!

It was something to do with the WrapFloat3 node; as you can see in my screenshot, I plugged in a Wrap vector that had zero for X and Z, and in SM6 this just lead to the X and Z axis being unaffected. However in SM5, this resulted in the X and Z inputs turning into 0, causing my UVs to appear infinitely stretched along those axes. Breaking out the vector and just doing WrapFloat on Y and then recombining the vector fixed the issue.

This makes me think that division by 0 is handled differently between SM6 and SM5, but I wasn’t able to recreate the issue more simply in a separate material. Perhaps I’m not recreating it correctly, or maybe there was some difference in “compressing” the shader math given the amount of instructions in my master material, or some secret third option. Either way, there y’all go!

1 Like