This was never responded to and closed, but has been causing me problems for months. There is currently no way to disable shadows on scenegraph meshes either via the mesh asset or the material which is a problem when scenegraph entities are already so excessively costly in performance
Please select what you are reporting on:
Unreal Editor for Fortnite
What Type of Bug are you experiencing?
Verse
Steps to Reproduce
Try to spawn a mesh via scenegraph that is visible, it will be casting a a shadow which can be ugly and costs performance
Expected Result
There is no shadow when âCast Shadowsâ in the mesh is disabled for the material slot
Can you share your setup in the material to disable the shadows? I tested here and is working fine, idk if you are doing something different from meâŚ
The main thing is the inconsistency between systems ie bpp and static mesh and mesh_comp. We shouldnât need to change materials just to disable shadows on a mesh in sg its like taking 2 steps back from having a system that worked perfect to a new work around.
Still canât access static switch params via verse, so Iâll have to make a ton of MIs for this and this still doesnât remove the mesh from the shadow depth render Might as well keep the shadows as my concern is CPU performance rn
Static Switch Params are static because they only exist before compiling the shaders. (Same with anything that has âStaticâ in the name such as static bools)
Shaders are pure math on the gpu, only numbers (specifically, only floats), no bools, and not even integers exist without doing workarounds⌠(Plus considering different shader platforms and instruction libraries)
The Static Switch node is just a utility for UE to make more easy making multiple variants and toggling states/features of that material on different instances (all at compile time, none are possible at runtime).
For runtime, you use things such as 0.0 to 1.0 param, instead of static switch / static bools. This is normal and not a workaround, is just how GPUs work to compute the shader⌠Even epic does that on their own materials for example, common in all gamedev scenarios :ÂP (Any language that says it is a bool, is just a disguised 0-1 float. And you can do that in verse if you want)
About the shadow options (together with collision and other options on the LOD settings), it seems weird, it was supposed to work, idk why is not working.
But to be honest, considering all the engine tech, I would remove these settigns from that place and more to other places, maybe thatâs why they did not considered that when migrating meshes to Scene Graph yetâŚ
For example, the collision is server sided, only one lod can have its âmandatoryâ collision to be shared across all players, regardless if each player is seeing a different LOD type due to graphics settings for example. (Thatâs why the option is grayed out - It would usually be also modified on the âLOD for collisionâ setting on the other cattegoryâŚ)
Iâm talking about render cost not appearance. Using a mutable switch in the material is a visual workaround. It does not address the actual problem if Scene Graph meshes are entering the shadow depth pass and retaining the associated rendering cost.
Also no, a static switch and switch are not the same lol. A switch that can be changed at runtime is keeping the logic from the unused branch and much of it may still be evaluated, a static switch culls the unused branch at compile time.
I never mentioned âswitchâ node, I only mentioned âstatic switchâ and âstatic boolââŚ
I even read my message again to confirm that I had not made any mistakes. I know the difference obviously lol, thatâs exactly what I was explaining about the compile-only.
Then how does that change anything? Youâre saying âThis is normal and not a workaroundâ to just use a float at runtime inside the material to disable shading? This makes no sense unless all you care about is not seeing the shadow, the issue is that I donât want the SG meshes sent to the shadow depth render because thatâs what hits the CPU. I assumed you meant the float was driving a switch as my material is masked so a float alone wouldnât work, either way it makes no sense.
I said two related but isolated things from the topic past messages:
A) Explained why static switch/bools are not reflected in verse, how it works and what people usually use when needing âbool-likeâ behaviors in runtime. Never commented about the shadows drawing on any part of these explanations.
I only commented about âshadersâ (the GPU instructions API itself). Also only commented about this static switch/bools thing in materials because you commented about not being able to access them in verse, if was not for that, this entire âAâ explanation I would have not written at allâŚ
Then the other one:
B) About the shadows related settings on LOD settings, I commented that it was supposed to work and I was not sure why it does not. Never commented any workarounds or âsolutionsâ for that. â I also commented (Again, this is another point) about it being weird where the option is placed, which could be the reason why it is not exposed, telling that it maybe get more attention in the future when epic starts adding more scene graph features.
What happened is that you apparently mixed my two discussion points, thinking they were the same, besides not beingâŚ
Yes, I agree with you that using the ShadowPass node like I said on my first message may not be the best for performance, yes, I agree that the extra mesh settings (not only shadows but many more) should be exposed and available in verse, and yes, I agree that the current option not working is weird and pretty sure a bug (I even upvoted the post).
I never said âdo thisâ or âdonât do thisâ on any of the aspects, I just explained the things and commented about :Â/
I started this thread as a bug report about something affecting performance, you then start countersignaling with non-fixes. I want it to be clear to any devs reading this thread that there is currently no workaround.
Might as well keep the shadows as my concern is CPU performance rn