Converting from 2.6 to 3.0, first impressions.

Graphics Shaders & Materials
1

So lately we decided to upgrade to Unity 3 and I started converting our project.

Except for the fact that all of our custom shaders were broken (need to rewrite them with Surface Shader, which overall is a much easier way to write shaders without weird bugs) the conversion was smooth.

But there are couple of weird things that I want to share with you.
First off, the very well advertised deferred rendering engine. Let the numbers speak for themselves:

On my 9600GT:
Forward rendering - 80 fps
Deferred rendering - 35 fps

The models have about 8 pixel lights shining on them , which is enough in our case.
I cannot see any benefit of deferred rendering so far, considering that I am losing my anti aliasing as well.

So for now I decided that we’ll stick with Forward Rendering, as it is so much faster.
The problem here is that it seems that Unity team decided to pretty much shrink the support for it.
You can have only 1 directional light casting shadows in the entire scene. Want to have spotlights with shadows? Point lights? Tough luck.

Another problem are the shadows themselves.
Unity 2.6 had problems with shadows and 3.0 does 2 things better in this regard:
The shadows do seem to work a lot faster on my hardware and have less jitter.

But if you look at the shadows up close, this is what you get:

Now the shadow distance, number of cascades and resolution all have little effect to remedy this situation. All I was able to do is to get things look worse by trying every possible combination of options.

And while the shadows DO look softer and clearer from some distance (a big improvement), the close up just looks sub par.
The shadows look exactly the same in both deferred rendering and forward rendering modes.

So, we’ve got Beast, we’ve got deferred rendering but we still can’t get shadows to look good in 2011.

If anyone from unity team is reading this, do you guys think you could throw in a couple of more samples into the shadows for close up cases?
It is very disappointing that we still can’t get good looking realtime shadows.

So I have mixed feelings. I am happy about the better performance, new surface shaders and little cool tweaks. But I am not happy about how limited forward rendering is and how shadows are still being a problem.

Gennadiy

2

To make things even worse, they have decided to drop spotlight/omni shadow support for orthographic cameras entirely! No R3.0 for me…

3

Another limitation is that dual light maps are not supported in forward rendering mode.

Hopefully we can remedy that by writing our own shaders.

But what are the benefits of dual light maps anyway?

4

So I played more with dual lightmaps. It looks like it’s a very cool concept.

Why not supporting it in forward rendering? Now we’ll have to figure this stuff out using our custom shaders.

5

Personally i liked the new colours and the animations in the editor.

I hope that there were new ones and i don’t appear silly by now.

6

We’re not really concerned about the UI, even though I have to say that 3.0 feels a LOT more competent than 2.6. The UI is just a lot better, especially the asset management, huge improvement.

What we’re concerned with is shaders / lighting / rendering and how we move forward now. It seems like deferred rendering really drops the performance quite a bit for not a lot of gain and it does seem like deferred rendering is being forced upon you if you do want to use Beast for Lightmapping. Our benchmark is very much like what we did at Blizzard: The game should run at 60fps on 3 year old machines.

We’ll keep you guys updated on our progress. Once we get some final assets done and some time to tweak things, we’ll post an updated version of Warsoup using Unity 3.0.

7

For not a lot of gain?
Hehe I think your environment is just hell a lot too simple to justify deferred then :slight_smile:

Deferred has a hefty overhead, thats true (it renders multiple buffers each frame for the different information of importance, light, shadow, normal, depth) which just costs performance.
This has nothing to do with Unity, any engine has to take this hit.
Thats they reason why any AA+ used engine has in reality 3-7 render paths under the hood, because they would otherwise scale as craptastic as Leadwerks engine or be as troublesome as UDK which with every second iteration drops backward support (since june 2010 its SM3+ only and things like this)

But due to the way it works, it takes a massively lower hit from more and more dynamic lights and shadow casting. on forward, each dynamic light means one extra draw call for each affected object. Dynamic shadow means one extra drawcall for each affected object. Each reflecting surface basically doubles the drawcalls of the “nonreflected” environment.
Gives you an idea how fast 400 drawcalls exceeds what even a GTX 260 can render and thats already significantly over the average user.

stuff like the Dark Street scene shown on videos is totally undoable with forward as even a GTX 480 would have some serious problems.
With deferred on the other hand, you don’t need such a monster. By using dual lightmapping and lower shadow ranges and tweaking quality it can even run on an 8000 series nvidia card, a card that would otherwise have to disable reflection and would suffer from ugly artifacts due to missing dynamic shadows.

8

*Dreamora crits thomasmahler for over 9000 damage.

:stuck_out_tongue:

9

I understand what dreamora is saying, but at the same time. If forward rendering actually offers the best performance for thomas’s and GennadiyKorol’s project then shouldn’t they be able to use it with the same features and limitations as in 2.6?

Has anyone in the Unity team commented on this? Is this a bug? Was it necessary to nerf the forward rendering for deferred to work?

10

Yeah I noticed the performance drop too.

Then why remove shadows from point lights in forward rendering. If someone has a scene thats too simple for deferred, but want real time shadows from point lights, then they really have no choice but to use deferred. Therefore defeats the purpose.

Personally I wish they left forward rendering the way it was, as a fall back for situations that deferred rendering isnt optimum for.

11

Then it’s not the point in Unity’s favor, is it?
The scene you mentioned has crazy amount of lights, so it makes sense to use deferred rendering with it.

But for our project, if I could only use the dual light maps (and reduce shadow distance) with all the goodies in forward rendering, I could achieve 100 fps on my GPU, while with deferred I get about 40. This while achieving the exact same look.

In our scene, we’ve got 1 directional light for the main sun light. We’ll have fill point lights here and there + the effect lights (which are temporary).
I can live with the price of another draw call for those areas. And as empirical performance tests show is still more than 2 times faster than that of deferred rendering.

Another HUGE problem with deferred rendering is the lack of anti-aliasing. For our game we want the CGI-film kind of look. Achieving that without anti-aliasing is definitely a lot harder.

While again, in forward rendering mode the anti-aliasing is there.

I had hopes that I could write my own shaders for light maps (to remedy the lack of dual light maps in forward rendering mode) but I don’t see how this is possible without touching the engine’s code. I don’t know how to achieve blending between realtime shadows and lightmaps otherwise.

So we are forced to use deferred rendering if we want to achieve good look with the light maps.

So the reality of it is: we invested quite a lot into our licenses now and are taking the risk by building our game on Unity (which as for today has no title featuring the visual fidelity we’re shooting for on its folio list).
And now we are forced to pick the path which will lead to much worse performance and no anti-aliasing for indeed no added benefit in our case.
Not cool.

12

You can always stick with 2.6.

13

Great suggestion. So now we will just have to miss out on all of the great features of 3.0, such as beast, occlusion culling and many other improvements (for which we upgraded in the first place) because of bad management decisions at Unity HQ?

Is there a technical reason for which the forward rendering can not have dual light maps? Or spot light shadows?

I do want to have working normal maps on my lightmapped geometry in forward rendering mode. Why can’t I?

14

I think what Gennadiy is trying to say is that it’s quite a bit upsetting that forward rendering does have much better performance but is basically being arbitrarily crippled now. We want to make sure that Warsoup runs on 3 year old machines (so that we can reach as many people as possible) - and that’s going to be much harder if we’ll go for deferred rendering.

Warsoup is probably going to be one of the prettiest games being created using Unity and there’s a very good chance that we could get better performance if we could stick with forward rendering and we’re not sure whether or not deferred rendering is doing anything for us at the moment.

Arguing that our scene isn’t detailed enough doesn’t make any sense - Our art direction doesn’t need a hundred lights in the scene. With baked GI and some dynamic lights, we’re already looking way better than anything I’ve seen here (including that Night Scene, which shows off the features of deferred rendering, but it’s just not very well art directed) and having it run at 80fps with forward rendering or 35fps with deferred rendering actually does make a huge difference.

15

Totally agree on this. Chosing a rendering path is very project specific, even more so considering Unity is not just targeting game-developers. Just for backwards compatability sake alone, R3 really should be on par with R2 in this regard.

What’s even more worrying is that Unity HQ somehow decided it’s ok to cripple the forward renderer that concerns Pro (paid!) features. I think backwards compatability/long time support is one of the most important things that can be found on a pro-developers checklist…

16

This is definitely perplexing.

Is this limitation a design choice, technical limitation, oversight, or bug?

17

I don’t see it as crippling

Its not like point based shadows were hard to impossible to setup without having the ring bias from hell mess it.

Also forward rendering is used on what, slow end cards?
As if they could handle point lights with shadow calculation on a reasonable performance. 100 unit shadows on such a box? haha nope, definitely not. there might be cases where point light shadow under the resulting quality level is not totally useless.
But those cases are rare, the majority has definitely relied on dynamic shadows from the sun.

The only thing I am not as happy about is that the shadow is restricted to a single directional

18

Aras would have to chime in for the definitive answer, but AFAIK it’s by design to simplify the shader pipeline. But it’s kind of silly to think that this might be an oversight on our part. There is no way a feature like this wasn’t well thought out with all the advantages/disadvantages weighed… especially when Aras is involved :wink:

19

It’s a design decision, read some of Aras’s posts here:
http://forum.unity3d.com/viewtopic.php?p=349686

20

Update:

I played more with quality settings and reducing everything (did you know that antialiasing still eats performance in deferred mode, even though it doesn’t work there?).

Partly the overhead was coming from us using 3 cameras (because we need 3 different layers).

I just merged all the cameras to 1, and the performance increased to 70 fps in deferred mode.
Looks like it’s keeping much more data per camera, which used more memory / bandwidth on the gpu and slowed things down.

Now I need to figure out how to make the weapon not go through walls and stuff. Having it in a separate layer was easy.

With the same settings, forward dendering is giving me 120 fps :smile: But if we manage to make this one here work at 60 fps on my machine in deferred mode, I’d be happy.

But then, we would still able to push more polygons/quality in forward mode…