Why does Unity look "flat"?

I gotta ask because this is something that's bugged me for years, it looks like somebody messed up the projection matrices math and never did anything about it?

 

HDRP or builtin?

 

I switched back to built-in due to messing around with terrain system. Them screenies I took in the arch viz thread looked fine though right?

 

Yeah. But with builtin, the Physical Camera is available. You should try it out.

 

I tried the Physical camera and it still looks the same, I did notice you can change the projection matrices so I might have a stint at that.. The only logical reason I can come up with is there's a fundamental flaw in some of the rendering basics..!

 

I would imagine that the reason you feel this way is due to the lighting and default fov, because that can change the situation quite a bit in terms of perception.

Can you not make the same untextured and unlit scene for both Unity and UE4 without any post at all? Just mobile unlit style so we can see if it's just you.

 

No probs, I did a basic cube and sphere screeny from both of them and then did a speedtree example of both (where I noticed it most).. Only thing I left on both was temporal AA.

Unity:



Unreal:



Unity:



Unreal:



Screenshot of Unity looking weird as (flat) (This has a FULL post processing stack on it):

 

Er no. You left on ambient occlusion and IBL with grading and tonemapping in UE4 along with antialiasing, and UE4 has a more interesting IBL with cloud texture to sample from.

Pretty clear a lot of post is going on still. Nobody on any forum will ever think you ever remotely compared the same situation. Basically you turned pretty much nothing off on the UE4 one.

vs


Basically your flatness Unity side is because:

1. your skybox stinks (there isn't one)
2. need way more post, including AO
3. HD does AO properly and contact shadows so it's best to use that, but if not, then pay attention to giving Unity the same skybox, ACES, AO as UE4 to get them looking similar.

 

Oh c'mon hippo you've seen the screenshots I've done, I know how to set up a scene and it ain't got jack to do with post processing.. It's nothing to do with lighting or shading, it's the geometry dimension in 3D world view..

Here's a basic scene set up with everything including the kitchen sink set up and it still looks flat (Unity)..



Also edit: Updated the sphere example.. Just to not get lambasted here you are.! Also another edit re-uploaded the tree example.. There are like four places you can set up post processing, they are ALL disabled.!!

 

If you compare the spheres, it seems that the shading is different (just the surface). Dont know what Unity in this scene use. Blinn or phong shading? In unreal the sphere surface doesnt looks that hard, where the sunny side and the shadow side meets.

 

Unity does indeed look flat if you simply place a cube and two spheres on the scene.

When you bake it, add a propper skybox and use the Post Processing Stack correctly, it's a totally different story.

Also, yes - Unreal is easier when it comes to graphics. In Unity, you have to download the Post Processing Stack and mess around with it but honestly it'll take you like 2 minutes to download. Baking is also important.

If you want to see my lighting settings, Post Processing Stack settings, etc, you can message me.




https://imgur.com/a/SUp1247

 

Yep, used Unity since around 4.1X.. Yours still looks flat, especially around the sphere's.. I'm not talking shading or lighting I'm taking depth perception.

Maybe I need new glasses I dunno, anyway it's not the first time I've asked in the last half decade and it seems it'll remain a mystery.

 

What do you mean by "Flat" then? If I didn't include Unity's interface and said that I made that in Unreal, everyone would believe lol

 

To me at least objects appear like they're in a slightly orthographic projection and I've only ever noticed it from Unity.. It's worse with some objects than others, I have literally tore the think apart from grass roots and never really got to the bottom of it..

Never bothered to write my own rendering solution from the ground up though.. Seems like a waste of time.

 

Unity uses a vertical FOV with a default of 90 degrees for the scene view and 60 for the default game view camera.

Unreal uses a horizontal FOV with a default of 90 degrees for the default game view camera. I'm not sure about the scene view, but I think it's around 120.

This is probably the difference you are seeing. If you match the resolution and horizontal FOV between the two engines they will render unlit objects identically. Everything else comes down to post process and lighting calculations.

 

I already know that and I'd be happy if that was the issue, but it's not it looks the same irrelevant of FOV..

 

I thought by this stage I might understand exactly what you mean by flat, but I really dont.

 

I suppose we could try a totally different approach.

Do any of the fancy Unity demos of recent years look flat or not flat to you? eg any of the Adam ones, Book of The Dead, older stuff like Blacksmith or the Courtyard GI demo?

 

Just looked at book of the dead again, this main issue it's not always apparent.. We're absolutely fine until we hit the forest scene at 0:55 seconds then BAM.! Tree's look like they're 2D sprites.

I've never seen it outside of Unity, ever.!

I'll just say though, I'm not doing this to cause a ruckus. In 2013 I released a beta of an RPG and I got this feedback from a couple of testers.. As soon as I noticed I've not been able to unsee it.!

It was on my to fix list and I honestly wondered if others had come across it and was like yeah, I did X/Y/Z..!

 

Then I think what you're seeing is a combination of Unreal's better baked lighting and AO systems (which don't require post process), and the default tonemapper which takes some work to fully disable.

Otherwise @hippocoder 's early response seems accurate.

 

The original image uploaded was quite a bit more post on the Unreal side as you can tell from the cropped screenshot being different to the new screenshot that was edited. Regarding AO, if I am not mistaken HDRP doesn't use a post process for AO either (but this is builtin).

 

So what? I missed one of the infinite combinations in Unreal, one isn't forgiving are they?.. It doesn't matter if you use Octane, Enlighten or PLM, it doesn't matter if there's a full post processing stack or none.

It doesn't matter if you use third party post processing (like HBAO), it doesn't matter if you change the FOV, use the physical camera, use HDRP, it doesn't matter if you bring the standard shaders inline with Epic's implementation and it certainly doesn't matter if me, you or somebody else makes the scene..

I can go on for a long while here, the end result is it always looks slightly flat. Maybe I am being overanalytical about this, staring at a screen for ages can make you slightly OCD sure.. Something ain't right though and the only way to get past this is for me to dig deep into the rendering (not the first time) it seems.

It was you that brought UE into this by requesting a comparison ..

Glad things are more accessible nowadays.

 

I certainly dont think you are being overanalytical, otherwise you would have analysed what you are seeing and come up with solid, concrete explanations. I also think you'd be far less inclined to reject what everyone else is telling you, and less inclined to make assumptions about projection matrix mistakes.

I'm not used to talking about this subject in technical detail, which is part of the reason I am in this thread, I was hoping to learn something. But certainly the way I tend to look at the broad issue of depth perception, especially as it applies to 2D non-stereo displays, is that there are many things that combine to give either good or wrong sense of depth, very much including shading and lighting. At least dont rule them out until you've done a test that actually gives proper clues about the phenomenon you are seeing. I know you've done various tests and comparisons, but I dont think they've really lead anywhere useful yet.

 

Well one usually talks about depth it's usually along the lines of tessellation / self shadowed parallax occlusion mapping / shadows or little touch up's whether basic screenspace AO or a proper solution like mesh generated distance field AO.

Although if you've ever built a renderer (even at a basic level) bar all the fancy stuff, it shouldn't look like there's a lack of depth perception if the basic stuff is right.

This is a picture from a super basic framework I made in like 2011, all it has is basic projection matrices done right and a standard GLSL phong material.. This doesn't look "flat" to me..

The basis of it literally follows the following: http://www.opengl-tutorial.org/begi...rices/#the-model-view-and-projection-matrices



Then over the last SEVEN years I tried porting or adapting a lot of stuff (whilst learning a lot from Unreal TBH when that came out) into Unity and with the recent addition of HDRP I managed to do even more (even if it was buggy).. Which results in the following..

Again IMO doesn't look flat in the slightest:



Issue with the above is I've changed so many things, I couldn't tell you what the actual issue is.. It's a shame it doesn't work all that well / performantly..

 

Even if you disable all PostFXs, and don't generate SDF for your meshes, Unreal is still very dependent on this algorithm since they began development of Fortnite a few years ago. They have plans to create Dynamic GI out of this, maybe this is why they don't care about existing GI tech:

https://docs.unrealengine.com/en-us/Engine/Rendering/LightingAndShadows/MeshDistanceFields

 

@BxBL-GS

Yeah but AFAIK it's not on by default right? You can tell when DFAO is on, well firstly because you have to enable it and secondly enable it on your meshes.. Then when it's on everything looks rather dark until you tweak it.

DFGI got for me most part canned..

.........................................

Anyway @sledgeman I could be wrong about a couple of assumptions (apologies for being a little "hard headed"), I didn't really have time to deep dive into this but now I've spent a full night dedicated to it I have more answers.. For a start I actually recon it could be the standard / HD / shadow shader at fault, I did try others like Uber but that's based off the standard.

So I wrote some..

First is a shader that's completely borked (just for reference), it was made to take any shading / shadow information and essentially bin it..

Here's the results, I'd be suprised if you could tell it's not a plane..



Extremely basic shader w/ altered shadow bias..



I also noticed there's variable points of light defraction and off colour lighting happening in UE which you don't seem to get in Unity, there was a massive thread on this (AAA enlighten) when we first noticed it:

I think I should try octane and see the results..

 

Perspective is fine. I rebuild our offices in 3D very accurately and made a VR app. When you where positioned correctly and took off the Device there was no difference, everything was at the correct spot.
We made tests with touch controllers and when tracking was set up correctly it was extremely accurate. You could place controllers on tables and you could touch the wall or floor with it.

Edit: Here is a quick comparison. The only reason Unity might look flat is shading, light and shadows.


Also I rebuild another location and when you where sitting on the bench you could feel every detail and the edges where exactly there where you expected them.

You have to make a real comparison with same FOV settings, ideally using a quadratic resolution.
This looks like a nice comparison and I see no much difference:

 

It's pointless comparing Unreal to Unity, they do a lot of things different or can be at least done different.. Like distant field ambient occlusion, normal maps are done in tangent space (by default, yes I know HDRP) the CSM options alone vary greatly from modifying the distribution components to enabling ray traced distance field shadows..

They use Photon mapping which clearly produces different results (we banged on about that one for a while) to anything using irradiance.. Also again forgetting HDRP for a minute Unreal by default uses inverse square falloff. Finally I'll mention Epic constantly mess around with the rendering engine and add new features on EVERY release cycle, so what exactly are we comparing against what here?

What some seem to do is try to match two scenes as closely as possible which doesn't showcase the strengths of either engine, it's silly.. Unity is more of a "framework" made into whatever one can dream of.

Fact of the matter is unless you have access to both you can't tell whether or not it's the projection matrices or shading, the logical assumption that it's something to do with lighting / shadows / shaders etc. which is most likely the case. I also said it's more apparent in some cases than others.

The only REAL way to find out would be change shaders / default lighting and see if it makes the difference needed.. OR you can wait for HDRP and try it with a third party shadow solution, that should at least give the answers one is looking for without overinvesting in effort.

I'm not asking this because one can't find an answer to the solution. End of the day they're all built on DX / GL and it's a matter of finding out what needs changing, it is just sometimes quicker to get feedback..

 

Although comparisons certainly have their limits when people are arguing over things like 'which engine is better', they are actually very sensible when faced with people speculating that the projection matrix is wrong in Unity, etc, or when faced with ambiguous use of language which leaves people unclear as to which phenomenon is being identified and complained about. Anyway, I am done here since you dont seem that interested in answering your own question and this is turning into an even bigger waste of time than I thought it might.

 

OK maybe one last comment from me.

You said you find something wrong with the results Unity provides, that it looks too flat to you. For the purposes of testing this theory in general, rather than identifying exactly what you are on about, any version of UE or another engine would do.

 

It takes TIME to find out exactly what's going on, not a quick two minute back and forth on a thread where people are guessing just as much as I am.. Without the legwork it's unproven eitherway, you may look at engine X and decide it's not without knowing why AGAIN without the legwork..

I have been messing around with HDRP recently and for the most part things have been absolutley fine, it's been brought into this decades rendering pipeline techniques.. I still need to do more testing though simple as that..

I'm done too, whenever this gets mentioned (like it has done over the last couple of years) it always devolves into the same crap..

 

It's nothing to do with the thread devolving, or the question being hard or time-consuming to answer. Its more to do with phrasing the question in terms of something being wrong with Unity. It takes time to get all the ingredients of a scene right, which is what such threads are often really about, not shortcomings in the engine per-se. By contrast, discovering what is wrong with a scene or indeed an engine doesnt necessarily take long at all, especially for people trained to look in the obvious places, who are likely to have a good hunch that can be explored quickly. That doesnt happen when the response to such hunches seems always negative, and is obfuscated with talk of 'too much changed in the scene, or between engine versions, or this comparison is meaningless, or i changed too much at once and didnt notice what I changed that made the difference'.

 

Anyway I'm sorry, I guess I just get frustrated when I see perfectly good responses and clues being rejected for reasons that dont make all that much sense to me.

Anyway I just remembered something vaguely relevant to the subject of 'looking flat' but my dinner is ready so I will have to go on about it later.

 

Now you're starting to ask the right questions though, you don't usually accumulate 4,500 posts in the space of a month so I have used Unity a fair amount over the X years.. Reason I mention it is because there's only a finite amount of things that can affect this..

Shaders are one of them, I've used Alloy, LUX, Marmoset, custom made and of course Unity's standard shader.. Results were mostly the same.! So for now at least I'm putting them to one side (although I am definatley not writing it off)..

We have post effects, sure another potential issue especially around AO.. I've used HBAO, Aieth's Scion, SE post effects to name a few.. Again used many implementations so I'm putting it to one side (for now, again I'm not writing anything off even if it looks like it).

Camera settings, I assume (mostly incorrectly) being around here for a long time it goes without saying I've messed around with FOV / Shadow settings / light settings etc. Yeah, I'm not saying I don't make mistakes some times which can contribute, but I've used many formats / scene setups over the years (and displayed many photo's on this forum) of the results..

Shadow shaders, now this really could be an issue.. For all the settings I've messed with I have never tried a third party solution neither did I finish off my own shaders.. As I said earlier a decent phong shader not in use with CSM's should still "look" like a 3D object IF it's at the right angle, although tree's etc. curved and spherical / cylindrical items tend to need more shading detail to avoid lack of depth perception (hence the other picture I posted)..

It's really just a matter of going through it and eliminating the potential issues one by one.. There are some methods in my madness.. If nothing sticks then it's my original guess..!

 

It's not your original guess unless that specific cause is positively confirmed, doing it by a process of elimination can only take you so far and is useful but not completely safe because other things could still have be overlooked or erroneously excluded.

Anyway the thing I was going to mention earlier but ran out of time for is deliberately not something seen in any of the images posted so far, but it does relate to a strong contender for things 'looking flat', especially as you sometimes seem to be referring to specific single objects in a scene, rather than a lack of depth in the scene as a whole. Volumetric rendering of 3D fluid sims is my main thing, and examples of these systems and other volumetric systems such as fog often point out that without self-shadowing, the volume may seem rather flat. And there is a reasonably cheap technique for achieving that in a volume that isnt perfect but gets good enough results for a range of scenarios and certainly makes a difference to depth perception. Now when it comes to meshes the tech is obviously a little different and things like AO also probably count as being somewhat in this same domain, but especially when I look at certain tree images that you thought were too flat, I'm pretty confident that this is a big part of the story here, just like other people already said.

 

I gotta ask at this point, are you just here to argue with everything I say?

So let me clarify, you're saying it's AO? Even though I specfically just said I'd tried multiple AO products to no avail? Also switched off AO in some examples and went through graphical demo's to double check behaviour between my posts and someone elses examples?

Well, I didn't find a time saving cheat but I'm sure when it becomes necessary I'll figure it out..

 

No, and I would hope the substance of what I am arguing about makes it quite clear that I am interested in the actual topic, and the best approaches to analysing it. Anyway I ran out of things to say, not going round in circles about AO again since others are better qualified to talk about that subject properly, and my point about self-shadowing in volumetric systems was really just to point out another example of something being described as looking too flat, and how that is overcome to some extent.

 

Well I figured out what it is anyway...

Unreal..:



Something I made in Unity years back:


It's SPEEDTREE..!

Well mainly, the rest was down to shadows (which was fine in HDRP bar shadows but got there messing around with bias for the most part).. Not exactly sure what's irk'ing me so much about ST (also for so long) now I know I'll definatley find out.. It's not Unity (well mainly).. ..!

 

Apologies if this has been mentioned before, I just skimmed the thread, but if the lack of shading on round objects in direct cast shadows bothers you, have you tried what happens when you manually modify the skybox or reflection probe to have a stronger light gradient from one side to the other, so that the indirectly lit object's curvature gets more emphasized through shading? It might be speed trees that show this issue most clearly because they don't get light-baked properly or their shader has a more limited IBL support? But that's a wild guess on my part, I never used ST.

 

If you look at the Unreal example the stones on the floor is direct cast but still retains ample amount of shading, probably because they are rocks with a lot of sharp edges and there's enough of a lighting angle for shadow contrast.. The tree's are just bounce lighting from Lightmass. I honestly don't believe Enlighten helps in scenario's where there's minimal shading contast because the indirect lighting appears to be a direct colour bounce..

I noticed this originally when pushing indirect lighting to extreme (as a test), if you have a yellow(ish) directional pushed it mainly looks yellow and strips the shading variants.. Plus everything in Unreal is pushed to 11 by default so that's why in some scenario's at least it's less noticeable and it's post stack has less "washout", the annoying thing with that is trying to undo it as you have zero control over it.. I mean you can offset with IBL (skylight) but trying to balance the two is a real pain, shadows look oddly dark or everything looks too bright??..

So I do prefer having a blank canvas to paint with, although sometimes it is hard to tell why something looks the way it does.. You generally accept it and move on to more important bits, although I know what to do.. Mult AO / NM's maybe parallax the tree bark if it's not too heavy and go custom on it, I can add shading variants for a more "distinct" look..

Finally I need to sort out or find a better shadow solution..

 

I don't think it's just shaders, all games and cg movie with heavy visual compensate with placing fake light everywhere, that some scene don't need them (like that room above) is just specific and rare case. Hell even pixar didn't have bounce light through GI until very recently. And they have light that ONLY affect certain objects (eyes) and not others.

What's lacking in these scene isn't shader, it's a proper light rig, aka set of light, to sculpt light, it seems like you are only using natural light, it won't work, photorealism is a style, it is fake. In star citizen, they had a small segment about how they did light rigs, it's full of fake floating light everywhere. Even movies had them!


For your TOD you will need to have many light rig, based on weather and time condition) to interpolate across. Seems to me the problem is art directions not technical aspect.

 

Some test of unreal (left) vs unity (right)


You can tell the projection matrices is wrong with unity

 

@neoshaman

I do understand about light fakery, look at the arch viz example I posted there's contrasting blended spotlights which wouldn't exist in real life, there is no actual light there ..

Playing devils advocate here, the shading is COMPLETELY different between those two.. I showed an example of a non shaded err shader.. You couldn't even tell it's a 3D object, so how would you know it's a projection matrices without at least coming anywhere ballpark in the shading department??

You could LUT most of that information in..

 

I still only understand parts of what you guys are saying. How about you do a Unity vs Unreal comparison of a scene without light sources other than the skybox,environmental light settings and all kinds of AO and baking?
If it's an issue of of the indirect lighting aspects of the engines then I don't see how messing with the screenspace shadow solution is gonna fix it, because I thought that essentially just "turns off" the per pixel lighting influence of light sources within the shadowed areas and doesn't affect the shading within the shadowed area really. But I might be wrong...

 

That's what you do the whole time, I only wanted to prove that the perspective/Matrice isn't the issue.

This is a real world image and it looks like a game. Sometimes there just is not enough contrast. When you don't like that you need to add light and shadows.



Or here, this is an image even though it looks like unlit mode:

 

I was asked to, therefore I did.. I'm not disagreeing with you on the whole lighting / shading thing, I posted my own tests above with lack of shading information.. Does anyone read me posts? !

Here's what I said originally "it looks like somebody messed up the projection matrices", I didn't say IT WAS the projection matrices and unless you can view the code you can't "prove" it's not .. Making theoretical arguments are cool, they are helpful and will push you "potentially" in the right direction although it might not either..

I've noticed what the issue is for me personally, so I will go ahead and sort it.. Just on a side note, it's hard to compare two engines that go about shading / lighting differently.. IMO it's better to focus on the actual issue with the engine itself.

 

Because most of it can be changed after the fact, you can change shadow colours / crush shadows / enhance midtones and highlights / add more contrast / saturation / gain / white balance etc... It's well known that post processing can cause "washout" especially bloom, then you add in a LUT / tonemapping to correct the issues. As long as there's underlaying information from the likes of cascade shadow maps in an approximate fashion you can correct it to give more shading detail..

Diffuse bounce lighting and IBL is supposed to affect shadow maps, because if you have a bright tree for example with completely dark shadows it would look odd no? I mean that's not how it works in real life.

What you can't do is modify something that doesn't exist or correct a fundamental flaw you don't have access to (not saying again this is an issue, just spelling out the obvious)..

 

I comparing it to reality and see no real difference. Anyway the definition of "It", the problem you described was the main problem in this thread as some as me just didn't see a real issue. Your posts just read like it is someone elses fault, e.g. now "it's SpeedTree" or "It's not Unity (well mainly)".
I read your post and I only wanted to showcase that there are real world examples to that problem.

 

I have a lifehack now. If the picture doesn't look good - just blame the messed up matrices.

"-Alice, our levels looks like crap!
- Oh, it's the messed up matrices, don't bother. Just change the engine to the one with better matrices."

"-Bob, your textures are plain wrong!
- Nah, it's the matrices, my textures are epic."

"-Steve, the lighting setup is horrible, go fix it!
- Are you serious? How can I work with these matrices?! Look at them, they are all messed up!"

On the serious side - matrix math (linear algebra) is so plain simple and mature that some of the steps are even implemented right on hardware (e.g. perspective divide). You either get it right, or it looks completely wrong, there's nothing in between (no subtle things like only SpeedTree being flat).

As for the part about "unless you can view the code you can't "prove" it's not" - digging into graphics doesn't require looking at the engine source, all that required is a native graphics profiler. @ShadowK would you mind building two simple APKs for android using Unity and Unreal? Even the first one with two spheres will do. I will be able to look at the graphics pipeline and tell the major differences between the two at the hardware level. It has to be mobile in my case because I only have proficiency in that area. If you will build it, please make a debuggable version. Thanks