Purely informative question about Unity (pre 3.0 era) and its Shadows

So this is a question I am just curious about. It doesn’t serve any problem-solving but it really irks me that I can’t recall the answer or find any information about it.

So I was just going through all of the explanations of the different render paths in Unity again and was wondering: What algorithm did Unity use before there was a deferred rendering path? My memory of the 2.0 times is a little foggy but I remember using the Pro demo version before I bought the Indie license later on and I think it was possible to use point lights with shadows. I cannot recall seting up any render path, though as I was very unaware of those at the time. I know deferred rendering was the new big thing in 3.0’s rendering features.
Forward rendering can only support shadows from directional lights. I am pretty sure I wasn’t using a directional light though as I was creating a somewhat dark, Silent Hill…ish environment.

Did Unity use a different rendering path back then or does my memory decieve me, here? :shock:

Unity introduced the concept of “Rendering Path” in version 3.0. Before v3.0, it didn’t have any Rendering Path like it does now. And yes, it absolutely supported Point Light shadows in version 2.

So I do remember that correctly.
Do you know what rendering method Unity used in the 2.x era, then?

That’s not the case, actually. It wasn’t true back when forward rendering was the only path, and it’s not true now, although it does require a bit of fiddling with shaders now.

–Eric

Could you plase elaborate a little further on this?
The Unity manual states that forward rendering supports “1 Directional Light”. And the Unity editor states the same when activating shadows for any other light than a directional in forward rendering.

If you use forward rendering you have to add shader compile directives to enable shadows with point/spot lights. Surface shaders use the pragma directive fullforwardshadows, on cg shaders it’s some lengthy ridiculous name (yeah Aras, silly name), I don’t remember exactly the name. :roll_eyes:

Ah okay - thanks. That clears some things up but raises a few more questions. :slight_smile:

For these questions please keep in mind that I am an artist and haven’t yet written any shaders myself (other than copy/paste work from the Wiki). I have mostly passive scripting knowledge (I know some theory but don’t script much myself) and don’t really know anything about shader programming.

Why has Unity reduced the shadows to one directional light in forward rendering, then?
In my mind I figured it that way: In 2.x Unity used to use forward rendering as the only possible way. So the built in shaders all supported shadows by default but do not any more. Does this mean …

  1. deferred lighting does not need special shader directives for shadows?
  2. Unity 2.x dropped the shader directives for realtime shadows for performance reasons from the standard shaders?
  3. forward rendering is pretty much obsolete for scenes with more than one realtime shadow today?

Also is that the reason dual lightmaps in forward rendering warns you about the need for special shaders?

Sorry for all those questions. I am really interested in all this but somehow that question created more confusion in my mind than I expected.

Because having multiple pixel lights in a forward rendering path is really costly. Forward rendering path only make senses if your game doesn’t do any lighting or have 1-2 lights but nothing more. When you need multiple real-time lights deferred shading/lighting makes more sense. There’s few pro/cons for each rendering path (try to look for them in the Unity documentation).
1 - Nop, it works out of the box.
2 - Yes. (even if they don’t tell anyone publicly). ^^
3 - It depends, if your game it’s an outdoor game or a game that showcase few dynamic lights, it will run faster than deferred shading/lighting.

Btw, Unity uses deferred lighting (which is a variation of deferred shading).

So I wasn’t that far off. Thank you.
I’ve also read the explanation on the three rendering pipelines - that brought up the initial question in the first place. :smile:
What’s the difference between deferred lighting and deferred shading, then?

May I also ask for the performance difference in dual lightmaps and directional lightmaps?
Or are these two just a different approach with the goal of using normals in conjuncion with lightmaps?
I understand how dual lightmaps work and that they were used exclusively before directional lightmaps were introduced as a means of blending between lightmapped scenes and realtime shadows with normalmaps in the near clipping range.
I also know that for example Mirror’s Edge used directional lightmapping very extensively. Unfortunately even the in-depth documentation for lightmapping does not sem to contain any information about directional lightmaps (single- and dualmaps only).
What benefits and drawbacks does directional lightmapping bring, then?

The normalmap fidelity seems nicer with directional lightmapping. I asume that comes at the cost of not having realtime shadows from the baked lights any more - not even in the range close to the camera, correct?
The file size does not seem to be that different since just like dual lightmaps there need to be two lightmaps in the scene. Just that one’s for the direction and the other one’s for the shadows. Correct?

Sorry for the late reply, I was out! :roll_eyes:

Deferred shading requires two passes only but eat more bandwith. Deferred lighting requires three passes but needs less bandwith.

1 Directional Lightmaps will be faster if you don’t have any real time light casting shadows. But yeah, lighting would be baked.
2 Dual-Lightmapping give you the advantage of having near-to-the-camera dynamic lighting and shadows. Directional lightmaps will give you more speed cause light information is encoded in maps (which helps to produce faster specular and bump maps).
3 Yes.
4 Unfortunatelly Yes! :frowning: But there’s a hellish amount of videos and documentation freely on the web (do some research on youtute, you’ll find out a lot). :slight_smile:
5 Speed, it will look the same as with real-time lights the only drawback is that your lighting won’t move (as they are baked).
6 Normalmap will look the same it’s just the way Unity feeds normal/specular shaders with lighting information. (For dual-lightmaps Unity will feed with real-time light data. For directional lightmaps Unity feeds with the directional lightmaps).
7 Yes, the file-size for directional lightmaps can even be smaller cause lighting information doesn’t need to be that big (even for larger levels). Once you have the directional lightmaps you can scale them down (lower than your lightmaps).

Cool. Thank you very much :slight_smile: