Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Is unlit shader the same as surface shader with shadows disabled?

Discussion in 'Shaders' started by BIGTIMEMASTER, Sep 19, 2019.

  1. BIGTIMEMASTER

    BIGTIMEMASTER

    Joined:
    Jun 1, 2017
    Posts:
    5,181
    You got the theory and practice of occlusion culling. This means that if a thing is not visible on camera space, you don't call it to be rendered.

    DOes this extend to shadow casting and lighting calculations? For instance, I have two characters. One has a legacy unlit shader, and the other has standard pbr, but with only an emmisive map and shadows disabled. So it can look the same even if no lights in the scene.

    What is the difference behind the scenes? Is there any significant change? I wiill test for myself, but with limited knowledge I can still easily miss important details. So if oyu know anything about this, I appreciate you helping me understand. Thanks!
     
  2. bgolus

    bgolus

    Joined:
    Dec 7, 2012
    Posts:
    12,329
    The difference is standard PBR shader is still doing all of the lighting calculations, even if the final result is just black.

    A surface shader is just as expensive with no lights as it is with a single non-shadow casting directional light.
     
    BIGTIMEMASTER likes this.
  3. BIGTIMEMASTER

    BIGTIMEMASTER

    Joined:
    Jun 1, 2017
    Posts:
    5,181
    thanks @bgolus that is what i expected but its hard to find high level about this stuff. It's all down in the details, which makes hard for beginner.

    so then the cost of lighting calculations is on a shader by shader basis then? Meaning, if i have one object in a scene and its using surface shader, it draws the cost of lighting calculations. If I have 50, that's gonna be more. And the cost of that shader is just specific to what it's doing, right?

    Then if I have no surface shaders in a scene and no lighting + no global illum or anything liek that, the cost of lighting calculations should be zero?
     
  4. BIGTIMEMASTER

    BIGTIMEMASTER

    Joined:
    Jun 1, 2017
    Posts:
    5,181
    That's not exactly right, becuase i believe two objects using the same shader draw the same cost, right. One can be instanced from the other? That's dealing with loading the object, but then if there is any further calculations being made on any of the instances, like shadows or a collider or something, that is extra work for the, gpu I'd guess? If it's a thing being rendered.
     
  5. bgolus

    bgolus

    Joined:
    Dec 7, 2012
    Posts:
    12,329
    Rendering costs are a really, really complex topic.

    Most of the lighting cost is in the shader itself. For the Standard shader it's almost entirely how many pixels an object covers on screen. There's CPU time for assignment of lighting information that can also be avoided with an unit shader (to an extent, Unity seems to do some of it on unlit shaders too if there are lights in the scene), but usually most of the CPU cost is in the drawing of a new thing, regardless of what shader it uses. Apart from real time GI, Unity's lighting system has to be fast enough to run on old mobile devices, so on modern devices the amount of CPU time that takes is so small to almost be unmeasurable for a scene with 50 objects in it. So basically don't even worry about that.

    Shadows add an additional cost when doing lighting. Again mostly on the GPU, plus the added CPU cost of rendering "more things" in the form of rendering each shadow casting mesh again (or sometimes 5 more times) to generate the camera depth texture and cascaded shadow map.

    Additional lights cost extra with the built in forward rendering path as each light renders the object again (potentially multiple times if the lights are shadow casting), costing more CPU and GPU time.

    But, again, the major costs are the time it takes the CPU to tell the GPU to rendering, and for the GPU to do the rendering. Culling is used to avoid having to tell the GPU to render something it can't see, as is occlusion. Though the cost of occlusion can sometimes be higher than the costs to just render it in the first place, so you have to be mindful of that.


    When it comes to instancing, or drawing two objects with the same shader. Each object still costs the same on the GPU as if they were rendered alone. Instanced objects are actually often more expensive to render on the GPU than non-instanced. The cost savings here are often almost entirely on the CPU as there are higher costs for issuing multiple individual draw calls vs saying "draw 100 of this one object" (usually), and changing the shader between draw calls makes the successive draw calls more expensive than if the shader didn't change.


    The simplest way to think about rendering costs are:
    On the CPU side: how many things are active in the scene that can be rendered, and how many are actually being rendered.
    On the GPU side: how complex are your shaders, how many vertices do your models have, and how much of the screen do they cover (how many pixels of that shader are being rendered).

    That's really the biggest things to think about.



    Colliders are 100% CPU side, and has nothing to do with the GPU.
     
    BIGTIMEMASTER likes this.
  6. BIGTIMEMASTER

    BIGTIMEMASTER

    Joined:
    Jun 1, 2017
    Posts:
    5,181
    thanks. you are the man.

    yeah i just trying to get big picture right now, otherwise a lot of this stuff just don't make sense to me otherwise. I have to understand top down. Can't do bottom up.

    Anyway, thanks so much i keep this in back of my mind as I doing some catlike coding tutorials for shaders. They also do a good job at explain complex stuff simply so hopefully that's gonna get me where i need to be.