Interesting to see the extreme amount of draw calls or the ridiculous level of detail work involved. Or the fact that a lot of the terms and processes involved are not that different from what we do in Unity, only on a much larger scale.
I can’t even grasp how it’s possible to make such a detailed breakdown. And all the interactive examples embedded directly into the article are fantastic.
Man, I love Rockstar and their approach towards realism and not the “let’s pile every post processing effect on top of each other” realism that most other modern games lean towards. The world of GTA 5 feels so “right”.
Nice post. Most of the techniques he shown are already known from years, to deal with large worlds/LOD’s. Unfortunately, you need to make your own engine also, as almost none of current engines have such “improvments” for specific things. If I remember exactly some cube map tricks/lods stuff was in GW1 from ages.
Overall GTA5 is a total engine, almost perfect:) Also the art team did and outstanding job here, considering all engine features and of course optimizations.
I feel like it’s Rockstar’s approach to realism that sets them apart from the competition. Where other developers will focus on trying to get something to look as realistic as possible, Rockstar tries to make something feel as realistic as possible and in the end that’s what gives me, at least, the most immersion.
Just look at the way lightning behaves in GTA 5 or the atmospheric scattering or any effect really. It so closely mimics real life, and even though the effect itself may not look exactly photorealistic, it looks a hell lot better than using photo-sourced textures and forgetting about how that specific phenomenon would behave in real life.
It reminds me of Pete Draper and his books, Deconstructing the Elements, for 3ds Max. For every tutorial he would start with page after page on how important it was to break down and really study the the real life phenomenon you were trying to replicate in 3d so that when you actually started you knew all the intricacies you needed to create for it to look believable.
Some of the best artists around begin with mimicking real life then push/pull to hit the desired point where the visuals deliver the intended feeling/emotion.
Another reference - not related to gta or rockstar - http://www.neilblevins.com/cg_education/cg_education.htm
Another great resource regarding real vs CG vs getting the right look and feeling is The Making of Finding Nemo.
Lately I’ve been trying to focus on post-effects and the proper order.
According to this article in GTA V the AA is placed near the end after the tone-mapping and bloom, while I’ve read that AA is normally placed near the beginning. If you run the Unity corridor example Unity Asset Store - The Best Assets for Game Making , they place the AA at the beginning.
The other issue I can’t quite figure out, is how some games can use deferred rendering with no HW AA, and still look great. In GTA V, it looks almost perfect. The Unity corridor example uses the Unity AA effect, but the results are still not very good. Is it that the Unity AA effect is not that good, or what is the reason for this?
I think it’s very much a personal choice how you arrange your post effects. Once you learn what each of them does you can sort of imagine how changing the order of them will affect your final image.
In the manual for Paroxe’s Ultimate bloom this order is listed:
SSR
SSAO
DoF
Motion Blur
Bloom
Tonemapping
LUT/color grading
Antialiasing
The lack of proper AA is the most common criticism towards Unity. Temporal antialiasing is in development according to the roadmap: https://unity3d.com/unity/roadmap
In the meantime there’s this, which in my opinion looks a lot better than the AA effect used in the corridor example: https://github.com/Chman/SMAA-Unity
The AA effect used in the corridor example is very blurry so a lot of people prefer having no AA as opposed to using that one.
Ok thanks for the info. I also did find putting the Unity AA at the end of the effects pipeline produced the best results.
I’ll have to look into the SMAA link you posted. The current aliasing in deferred is horrendous for some meshes and is the primary reason why I’ve decided to go avoid deferred and go with forward rendering.
use of stencil buffer in deferred to mark out objects for further processing or rendering
reversed z for superior long draw distances
additively (built up over time) rendered cubemaps sliced per face and in several passes per face
various other tricks
I can see a lot here that could potentially improve the situation with unity, in particular with how bad Unity is with the depth buffer. It’s really difficult to get a great distribution in Unity. Rust had to resort to hacking near/far depending if something was close or not. The cascaded shadow maps don’t appear to suffer as badly as the ones in Unity either.
Was pretty shocked to see 4k draw calls on a humble PS3.
After reading this I came to wonder: why don’t open world games split the render frames for distant objects?
Like, up close objects could be rendered at 60 FPS, but then the terrain is rendered every other frame alternating with updating skyboxes and reflections.
@Not_Sure I know Blockscape does it this way (not AAA, but open world game with high draw distances, up to 3.6km, I think). Not Unity game, but it was written using C#.
A better way to load balance is to do things like rendering lower resolution and lower lod, but the lod thing would have to be carefully done to avoid visual artefacts.
In general it’s better to do little optimisations to keep fps up across all elements that make up the frame, rather than a few things, because a typical frame gets pressured in different ways. Halo 5 does this to just about everything.
Wish Unity’s baked lightmaps <> realtime was in better shape. We’d probably want to have the shadow distance about 10 units at most and bake the rest.
This is actually the first time I have ever seen the number of draw calls stated anywhere for a console game. I have been trying to get an idea of what the typical draw call count is for a PC/console game. This is actually shocking because I thought it would be somewhere around 1000 - 1500.
4k? Is that really correct?
Draw calls in actual professional games are generally a hell of a lot cheaper than Unity’s ‘implementation’. But Unity’s identified this and is apparently doing some work on reducing the cost of a draw call.
Not to mention instancing is on the way (I cannot freaking wait).
It is only 4k on platform that has fat trimmed compared to full-blown operating system. Would’ve been much more shocking to see 40 million draw calls. On other hand, due to its use of C#, unity will have chain of middlemen between your code and actual draw call.
I think you’re missing the point I was making Also, C# hasn’t got anything to do with Unity’s internal code for draw calls (which is being improved as I type this).
You’re also missing the point that in addition to draw calls, the PS3 has to calculate the game. And GTA 5 is no small game. This leaves practically no time left for any draw calls, and illustrates a vast amount of improvement is needed with Unity optimisation.
Rendering APIs on consoles are smaller and requires less traversal, your are closer to the hardware, no fat OS in the middle and a bunch other optimizations. That’s why you can get 4000 drawcalls in such a complex game. Although, I agree with most of you, Unity still needs more optimization works.
Also, C# hasn’t got anything to do with Unity’s internal code for draw calls (which is being improved as I type this).