How to make AAA graphics in Unity/Enlighten

If there were overlapping UV's Unreal would pick it up, give me a 30 minute lecture about why overlapping UV's are bad and start including the words MikkT / degenerate tangent basis and the shading would look an absolute mess.

I did actually have Unity generate the lightmap UV's too and it didn't help??! Ah well. I did modify the normal intensity on both, of course if I did it in Unity I also had to do it with Unreal..

One thing I did notice, directional light diffusion looks far better when baked. Non-static directional lighting doesn't look all that good in Unity.

Also I will point out, you can do direct comparisons where you try to make one screenshot look exactly like the other.. All that does is become a detriment to both screenshots, if you use the engines properly they look wildly different, even from a shader implementation standpoint.

 

The materials affect how the lighting is used, a pretty essential part of "how to make aaa graphics" in my opinion.. I agree with your opinions if you isolate lighting as the only thing the thread is trying to find a AAA workflow for, but I've been thinking of it more as "How to setup the rest of unity to get the best out of enlighten" and reading the original post again, even that might be too limiting.

AAA comes from all elements working harmoniously rather than isolating and polishing each individually IMO. The shaders affect the PBR grading which affects the textures, I don't know if Megascans use the same PBR grading as Unity but to get AAA it seems a useful thing to find out. I didn't even know that was a potential issue before this thread, which I joined as it seemed a great place to find out what I don't know and it's working great with the variety of things being covered

 

Is this fully baked in UE4? How can it get the normals to show like that? I know they had a magic directional light in UE3 that was semi-dynamic and would give a sharper edge to shadows that lightmapping would provide, but that doesn't explain the indirect parts.

What AA are you using in Unity. The new Temporal? It looks blurry, so try sharpening a little.

Also, this script might be worth a shot to sharpen the mipmaps. You have to attach it to a GO and click-drag all your textures, then right-click the component and click Adjust.

Code (csharp):

1. using UnityEngine;
2. using System.Collections;
3.  
4. public class MipMapBiasAdjusterS : MonoBehaviour {
5.  
6.    [Header("Settings")]
7.    [Tooltip("A positive bias makes a texture appear extra blurry, while a negative bias sharpens the texture. Note that using large negative bias can reduce performance, so it's not recommended to use more than -0.5 negative bias.)")]
8.    public float _target = -2f;
9.  
10.    [Header("References")]
11.    public Texture[] _texturesToAdjust;
12.  
13.    [ContextMenu("Adjust")]
14.    public void Adjust()
15.    {
16.        foreach (Texture tex in _texturesToAdjust)
17.        {
18.            tex.mipMapBias = _target;
19.        }
20.    }
21.  
22. }
23.  

 

I'm focussing on finding issues with lighting, not trying to win the screenshot of the year award ..! Also I'm not re-doing all of that, too much effort for no real reason. Deferring compression usually stops that from happening anyway without changing mips and with SD's you can have it generate mip data..

Yes it is fully baked..

Now the real question is the normal maps, I heard Unity was transitioning to to MikkT so it should be similar.. Has that not happened?

 

Looking at the Unity shots a few things pop out at me.

Comments on Untextured

Main problem:
There seems to be problems with light bleeding. You can see this on the near inset of the archway (left facing normals are bright). In both Unity shots the upper half of the inset is well lit and not properly occluded.

If you compare the archway inset (left facing normals) between Unity and Unreal it should be very clear - Unreal's has consistent occlusion.

Major Difference: Ambient Color / Occlusion
If both UE and Unreal are using the same ambient light colors, then Unreal is tinting the occlusion more by the ambient light color (as bounce light falls, ambient tint is used as replacement).

The Unity Progressive has the sharpest falloff/most intense occlusion, but all occlusion is pure black tint. If instead of black tint, this was recolored tints of orange then I believe the "lighting" in the Unity Progressive would look dramatic without being unnatural.

Perhaps a mixture of more exponential curve in the falloff (softer transition - with sharp extremes) and more color tinting in the occlusion would be a big improvement.

If the ambient color tint is the same in Unreal/Unity scenes - then Unreal is applying ambient color to occlusion, whereas Unity is not.

I also feel like Unreal is using an exponential curve for degree of occlusion whereas Unity seems to be using a more linear one. Although it could simply be that Unreal is re-tinting semi occluded areas with ambient color, so it appears to be a smoother transition.

Comments on Textured
You can see the problem of ambient tint in the Unity shots, the ceiling is nearly black in both the Progressive/Enlighten - whereas in Unreal it's tinted with the ambient orange.

Comments on Untextured:
In all honesty, the falloff from the enlighten is very similar to the unreal shot - if the same ambient tint was applied it would be quite close, although Unreal's nearly full occlusion is sharp and deep, whereas Enlightens is very soft. Enlightens corner occlusion is probably closer to real world, Unreal's is much more extreme, those edges are pure black.

Final thoughts:
I would be really interested to see what the intense occlusion of the progressive lightmap would look like with the occluded areas recolored with more ambient light. With that much sharpness, it might be very dramatic and kinda striking.

 

I've had a play this evening with these models, happy with the direction it's going in... but to take it to the next level, I'm not sure what to do..

This is what it started out like when I imported it:


And this is where I got to:

 

Just comparing progressive lightmapper and enlighten, enlighten appears better which is to be expected, except for those artifacts, which is pretty much a deal breaker! - I'm wondering if you used a stable version of unity that might disappear, I'm assuming you're on 5.6 but then I'm not sure if they would. Normally, those artifacts come up when I got 'keep quads' ticked.




Overall unreal engine wins hands down, it looks like a vray render. The bump shadows under the arch are lovely and the white version is orders of magnitude better than enlighten. There's also a warmth to unreal that unity lacks, also unity's AA doesn't help matters.

So I guess we have to conclude, it's not even close, if you're being ultra picky.

 

Can someone explain to me why you guys are comparing UE4 to Unity again?

 

In all honesty, I think that Enlighten's might be more accurate light.

I think Unreal is just retinting semi occluded areas with more ambient color.

It's got that nice soft orange trailing off into the very dark corners.

I really don't think that orange is bounce or anything, I think it's just degrees of the lack of bounce/direct. Could be wrong though.

 

Probably because that's the benchmark to judge lightmapping at its finest.

 

To see why so many artist flock to UE and not UT and see if it has a basis on the underlying lightmapping tool. Also help contrast what enlighten is doing (like normal contribution and AO computation). Constrastive comparison as always been a way to learn.

 

Both programs target the duplication of reality. Why aren't they compared to reality? If you compare the two, they should also be compared to their target to see if either result is nonsensical or not. Otherwise, there is only minimal value in the comparison and is subject to far too much personal taste to be considered serious.

 

Reality don't have normal map and technically don't have ambient light and ambient occlusion, + artistic tweak people do. Also reality don't allow you to remove material from surface because those are abstraction that don't exist in reality. Comparing abstraction to abstraction is easier than to reality, but cross checking with reality help, that's why there is photo of real life floating in the thread when appropriate.

 

I mean where do you even start with that (it's a lot to consider / write)? I've not just been assessing how pretty something is (even though it looks that way).. It's iteration speed / performance / ease of use / technological influence / shader disparency / scalability / troubleshooting and you need a reference point to even know if something is wrong (how else could you tell?). I fully trust that you can get AAA crushing scenes out of CryEngine and Unreal so again baseline..

There's too much focus on art as in (meshes / textures) when in reality most arch viz examples use nothing but white walls with flat constant vectors for nomals, maybe a texture for a wood floor with a constant vector for roughness input.. A lot of the time it doesn't go much further than scalar values for texture co-ordinate adjustment.

I'm going to do a write up on it, because of the comparison I've learnt enough to at a high level understand where I believe the biggest issues come from.

 

@ShadowK
so whats up with that orange in the unreal version - what's the source? Is it ambient light or is it indirect or ...?

I think that orange is a big amount of why the unreal version is so much more pleasing and I'm very curious.

 

It's indirect bounce and reflection probes..

 

zero ambient light in that scene? don't believe ;p

 

Lol, no there is a HDRI giving baked IBL lighting too although it's not the cause of the orange because it's err blue ..

 

So here's a pretty interesting comparison really...


Unreal: Light is being projected from doors

Spoiler

Unity Progressive: Light is being projected from camera

Spoiler

 

MY bet is that their default "white" light is actually warm and this appear when the light loose energy with bounces, which is how you do it by default in CG space.

 

Ok, that's a hell of a difference. Just a few of the main issues with the enlighten pic:

• No occlusion at the top of the near doorway, on the right.
  
• Can't decide between bright or dark down the side of the near door on the right (normal messed up?).
• Big difference between occlusion strength from the wall to the roof (Top left), also from wall to floor (bottom left).
• Almost total lack of occlusion on any of the geometry of the doorway at the far end.

@ShadowK is your geometry modular? I could never get a balanced occlusion on the inside edge between two separated objects, even if they were part of the same fbx file. Which is a huge issue in itself actually since a lot of people are going to want to set up a scene without turning their geometry into a single hull.

Enlighten aside for a moment, I have to say I was expecting better (i.e. lightmass quality) from the progressive lightmapper, but it looks quite similar to enlighten's result. I can only hope things dramatically improve before release.

Anyway, thanks for this, I think it's exactly what was needed (no more no less) for a comparison since the scene is simple enough, and results are clear enough, for anyone willing to be open-minded. And the lightmaps really are the point where the lighting should get judged.

 

Breakdown:

Let's start with the basics, I know a lot of you know this but I'll cover it anyway. Firstly, we're using physically based materials so we need to use "linear" colour space. If you don't know how PBR materials work here is a decent primer: https://www.marmoset.co/posts/physically-based-rendering-and-you-can-too/

Also a note on linear space: https://docs.unity3d.com/Manual/LinearLighting.html

For this test I used SD materials as they are already calibrated to the correct Albedo / Roughness / Metallic (etc.)

Reason I mention this is it'll be very difficult to get uniform lighting if you don't follow the practices and GI impact can also contribute to issues. Ok, so there are various types of global illumination, they aren't all componentised they can be mixed to a certain degree. Some of the main ones used are Raytracing, Photon Mapping and Radiance.

Enlighten uses Radiance, as discussed earlier it has specific advantages (relatively lightweight and pratical for real-time applications) although in some circumstances (as seen in cornell boxes) can have excessive diffuse transference. Think about the impact of that on your carefully calibrated textures..! I have a purple wall adjacent to a white wall in my house, there is a small (very small) amount of transference under heavy lighting situations but nothing like the cornell box examples.

Unless it's a heavy offline solution then realism in the super analytical sense isn't accessible, even with all the arch viz stuff.. But it doesn't mean with the right amount of fakery you can't come close. Of course the size and target for you game is going to dictate most of it.

Although as with everything else, there's various ways of doing GI.. SVOGI generally also uses several layers of Radiance but also has direct lighting sampled in a raytracing pass.

Sure, you might be falling asleep at this point but there is a point to it.. Physically accurate (somewhat) lighting, decent AO (as it's fed via textures and post now) and calibration is majorly important. Now, if you can spare it I always recommend Voxel based GI (like SVOGI / SVOTI).. On console it usually takes up around 4-5msec of rendering time and on PC (old GTX 780) you're probably looking between 1-3ms max.

Of course Unity has it's own solution which takes up far less rendering budget, but comes with UV maps (yay) and pre-computation (so not quite "real-time")..

The approach / actual implementation :

Again, depends on your game.. If you need semi-realtime lighting then of course you will have to use Enlighten, the progressive lightmapper (removing area lights) was actually faster (by far) than Enlighten, on average it took about a minute on 4 bounces and the highest settings (with area lights 23 minutes).

Ok, so the most important parts are reflection probes / various types of lights w/ soft shadows and your post stack. Which we'll want to include auto-exposure / tonemapping / AO / SSR / vignette and a splash of chromatic abberation and of course ambient occlusion.

First, angle your directional light until it sits for the best balance of shadows vs. light influence. If your scene automatically looks "washed out" you're pointing the DL too directly.

In reality relying on nothing but global illumination to fill out balanced lighting is somewhat of a misnoma, in real life there is a constant contribution and somewhat uniform brightness only affected by shadows and positioning of the sun (also we're not limited to 4 bounces in real life). Materials (surfaces) have some contribution towards this, but not by a massive amount.. In my examples I was testing out GI only, but you'd be better off carefully placing point likes (with the hex colour of the light matching the directional) to properly flood light.

HDRI via IBL (image based lighting) is a necessity for somewhat accurate counter balance colour like in the real world. When the sun isn't directly shining and doesn't have indirect bounces, there's still colour reflection from the skybox.

As already discussed AO is important but it's advised not to over do it, usually up the amount of samples and set it to around 0.25 (intensity) I also use it as ambient in deferred rendering.

You can set your rendering mode on your main camera and deferred is recommended for use with many lights. https://docs.unity3d.com/Manual/RenderTech-DeferredShading.html

With SSR the aim of the game is to increase the quality, use default settings unless something irks you.

Vignette should only be used to bring the outer fringes into alignment with the rest of the scene so use sparingly.

Chromatic abberation can add a silky soft smooth look to your scene, the rule of thumb is if you can tell it's on you've increased the intensity too high.

Bloom, cut it off before it gets too excessively "bloomy" or Zengarden will knock on your door.

Now we get to the really important stuff, tonemapping and auto-exposure. What I used to do with auto exposure is essentially just switch it off. I mean it shouldn't really have an actual impact right? Games have lived for years without such nonsense. Well it can actually help balance out a scene, mess around with the HV / EV whilst checking the histogram..

Although I like to keep it in check, so when you get to the point where you've got it so-so then clamp the values so they don't change much (but leave some to allow natural light balances as you would when walk through different lighting conditions). Again be careful about the length of the exposure as lighting could change dramatically to have negative effects.

Tonemapping and grading will make the biggest difference to your scene, this is where you should spend most of your time. ACES is good for more dramatic situations / stylised content whereas the aptly names neutral tonemapper is better for realistic content especially as you have far more control over its functions.

I can't just give exact settings because your game will of course vary, but mess around with the white in sliders etc. until you get a somewhat neutral balance of light. If it looks washed out don't worry about it, the likes of bloom will do that anyway and we'll correct it when grading.

As for the actual grader, for realistic content the aim is to try and balance out shadows / midtones and highlights / tint the scene to give again a more neutral and balanced lighting / colour space. It's actually good to reference the original materials you used because the point is to try and mimic its original colour space whilst taking into account the offset of HDRI influence.

Now the biggest issue (I still suffer from this) is correcting washout without overcontrasting the scene. I see this happen in a lot of games where they over endulge which leaves shadows too dark / offset colours and other issues. It is a necessity but use it sparingly.!

For the actual colour grading bit I recommend photoshop and amplify colour, it's faster and far more efficient.. Although you can use the logarithmic controls for things like slope (which is tonemapper adjustments really (UE uses slope and toe)).

Issues:

One of the biggest issues I found was balancing internal / external scenes. If you push the AO radius to try and mimic inscattered shadows (for things like tree's) you'll suffer too many artifacts. Also if you look outside trees aren't a brilliant blue, but you need to increase the amount of IBL for your interior scenes to balance.

There should be "ambient" shadows that comes from the skybox (which would resolve this and look far more realistic), you can somewhat get around this by auto exposure but it looses all use when you're inside a building for example and fake photons aren't directly starting you in the face.

Distance field ambient occlusion would also go someway towards solving this issue (CE / LY use large scale ambient AO via their voxelised solution, also the rendering by default could be better thought out. I understand it's relatively trivial to create what's essentially a "post process" volume (script for post changes and box trigger would do it) but y'know it's nice to have.

Make sure you have proper falloff values for point lights, these can be changed with shaders and I believe a search will provide you with a how to.

There wasn't enough contribution from bounce lighting like in lightmass via various systems (like IBL) (you can see lightmass flood to various parts of the mesh with colour variance).. Static skylights with HDRI cubemaps show direct correlation with lighting contributions and no just tweaking indirect intensity does not do anything to resolve it..

Also the lightmapper looks too much like Enlighten, not sure what solution they are trying to implement but a decent photon mapper would go a long way.

Meshes look "softer" in UE, I gather this mainly due to how it deals smoothing groups and normals, plus how lightmass distributes lighting / soft shadows..

Enlighten / progressive lightmapper left too many issues IE looked rather low resolution even on the highest settings. You can have lightmass look the exact same (on default preview settings it did).

Apart from that, it's cool making an uber realistic scene but you've got to get the rest of it to fit.. It takes a lot of work.! I'll leave materials / shaders with things like translucency and SSS for another date ..

Ok, unless there are any questions I am officially done

 

@Billy4184

The room (or box) was a single mesh with the archways and loosely speaking "door" being seperate meshes. I got too much light leaking having it modular.

 

Thanks for the write-up! You say on preview settings lightmass looked like the progressive lightmapper. Did you crank the progressive lightmapper as far as it could go in quality?

 

4 bounces, very high quality.. I sure did.!

 

So this lacks a lot of the fancy bells and whistles, but I think it demonstrates pretty good light and color.

I could not reproduce the color of the left wall (close to camera) in Shadow's UE shots - there was either an additional light - or some other trickery. (probably additional light used to create highlight around the arch).

If the orange light is bounce lighting coming from the direct light - and more removed from direct light becomes orange then finally black in highly occluded areas - then I don't think it's possible to create that stark white lighting on the left wall without additional lights or other trickery...


Here's another iteration with more extreme color differentiation for illustration. Still, that near left wall cannot be both as bright and as white as it is in ShadowK's UE pics without additional light.

 

If this has SSAO do you reckon you could post a pic with it off, to better judge the lightmapping? I feel like there's some low-frequency lighting information missing here - pretty much only right at the edges is there really visible lighting information.

If it's not using SSAO maybe increase the AO range?

 

You can test complex materials and models inside a cornell box.

 

And now you have successfully completed your walking simulator.

ShadowK I know you love challenges, your next challenge is to get a ball rolling in your scene and open the door at the far end of the corridor without it sticking out like a sore thumb.

Ready set go!!

 

OK here's my go at it. Not sure why the door parts are so messed up, I checked the UVs carefully and there's no overlapping/stretching.

• Precomputed realtime GI

• Realtime resolution: 4

• CPU usage: high

• No post

• 3 lightmaps (Doors, interior and exterior);

 

There was only one directional and skylight in that scene, I get the feeling UE is sampling the IBL (HDRI) image at multiple points hence the changes in colour reflection. I did match the rotation angles of the HDRI in both engines though..

@Billy4184

I had the same issues for some reason, I re-did the mesh and it was fine.

 

Sounds like it's tricky to get Blender to do good HDR lighting, and thought you might be interested in this...

 

Was there a wall behind camera or was skybox light coming in from behind camera?

It's simply not possible to produce the lighting shown without a whiteish light source from behind camera. Could have just been sky if there wasn't a wall behind camera to block it out.

That near left wall is too white. The light from the doors can't make that happen if it's a yellow/orange hue.

 

Sorry I didn't save the scene and it took forever to get the settings right (bake time, feh).

IIRC there was no SSAO, it was using tonemap but no other post. You may be right that the AO range was low - I was trying to sharpen the ao to look a little closer to the UE version. There's not enough control on how baked AO works.

 

Yes there was no blocking volume behind the camera (it's open).. Also (fortunatley) I saved a screenshot showing the effects of the skylight hemispheric transference, ambient shadows, distance field ambient occlusion and how you can futher affect occlusion tints.. Which dramatically helps when trying to blend scenes:

The skylight is somewhat exascerbated here (so you can tell what it's doing), but you can tell the effect of non uniform (or non-flat) lighting (but still consistant brightness) on the left side wall. Just to mention it wasn't baked either..

For me it's not so much about having the features, it's how they're implemented.. They have to make sense.

 

This.

I really think that Unity's lighting can put out very good results - but the level of guesswork combined with time cost per guess is too much.

• "Intensity" isn't convertable to real world units.
• Real time and baked "intensity" are scaled differently (dramatic difference)
• The interactions between baked and realtime elements are very hard to judge properly.

I think it's possible to reproduce the results of those UE shots (or come close enough that it doesn't matter), but the process is too painful, too random, and takes too long.

It's not like baked is the same basic lighting as realtime only higher definition - the output is entirely different. The result is that you need heavy modification to the lighting rig to switch.

Since you can't "see" changes in baked without waiting forever, the process of getting everything 'just right' is super painful since once you switched to a 'baked' rig, realtime changes won't be representative of the result.

Not sure if that makes sense, but if you waste enough time working with the system you'll definitely get what I mean. The intensity scales changing so sharply between baked and realtime is a real nightmare for workflow.

 

Definitely agree. One thing that annoys me is how there seems to be no way of increasing the occlusion intensity beyond a minimal value - surely it's just a case of multiplying the values that are already there ... ?

 

Very interesting thread. Here's mine.

Updated with reflections.

 

I think you've touched on some great points which most indies dabbling with uber realistic AAA graphics come across at some point. The most important thing is trying to get the game interacting with other objects in the game. That is difficult, even unreal with their combination of baked and realtime lighting, don't do convincingly. I've still yet to see an unreal paris like demo where you can bump into chair move them around and do other stuff - and have the shadows look convincing and keeping with the original scene.

Combining uber realistic baked lighting and realtime, is IMO too time consuming at the minute to be worth it.

Also, look at how much time you typically spend to get that 'look.' Take shadowK's example in unreal engine, it sure looks good but how long on average will a player spend in that scene, 5 minutes maybe at max, and what can the player do in that scene? Then he's off exploring another level in the game.

This is where the 'uncanny valley effect' comes heavily into play

Personally, now I'm much happier staying on the left side of the uncanny valley, the game is heavily stylized but at least, as indies we can fit in some really interesting gameplay and mechanics.

Let us not forget, that gameplay is what we're aiming for when making games.

In the meantime though, voxel based GI solutions offer a nice as damn it, approximation to super realistic graphics whilst still being interactable with other objects in the scene - sure performance drops, and you need a good graphics card, but I feel it is the way forward.

Unless of course otoy's brigade becomes a real option. That is most likely years/decades away. Perhaps even off loading the rendering to the cloud, but then you got an issue with streaming bandwidth etc.

 

Yeah, AAA does take a lot more time. Somewhere in this video it mentions each photogrammetry based prop (eg a rock) takes DICE about a week to develop.

If anyone watches through, let me know the time it's mentioned and I'll add the timestamp to the video player.

 

I believe the art-style sets expectations to the rest of the game. If the rest of the game can't keep up with the graphics, it breaks immersion.

For example, in a photo-realistic looking game, many things should follow realism too. I often see games that look kind of real, but feature simple artificial intelligence only, or nothing in the world can be interacted with. The problem for me is that you're in a world that looks close to real, but does not behave like it. This breaks immersion really fast for me.

The latest game where I experienced this issue is Mafia 3. The world looks real'ish, but the character AI behaves in no way how I would expect it to, which breaks immersion for me.

On the other hand, if games use rather stylized visuals, I don't expect that their in-game characters have to behave how they would in the real-world for example.

Picking an art-style does not seem to have an impact on art only, but on pretty much the entire game. Gamers probably start to complain about "stupid AI" or "non interactive objects" much earlier in a photo-realistic looking game than in a stylized one, which we can use to our advantage.

 

I think that this is a much much bigger problem than most people think. Every time I've increased the fidelity in my project a notch or two, the costs everywhere else increase. Each step comes at a giant price.

An increase in graphics polish needs to be accompanied with polish in every other system in the game. The GUI needs polish, the AI needs polish, the animation needs polish, the particle fx need polish, etc.

Once you actually get to animation, the interactive animation requires vast amounts of polish to meet any step increase in polished fidelity... meaning that hitting a guy with your sword needs tons of additional detail, more complex physics, better particle fx, and most often forgotten: better sound. Not to mention the actual animation themselves.

Each step up the graphics ladder raises peoples expectations, and that means craploads of extra work.

This is one of the things that even lower end AAA titles can miss the bar on. Blizzard is an example of a company that understands the importance of consistent levels of polish throughout the product. Every aspect of presentation in a blizzard title is top notch, even elements like sound, that some companies under value.

Not to mention, of course, actual game play that matches the same quality bar.

 

@frosted, besides Diablo 3 yeah? Gotta admit though, I did get my moneys worth out of it.

 

hahah, as much as I hate D3, I gotta admit - the presentation is polished to high hell. The gameplay is also, I just hate the way they polished it (dumbed down in the worst of ways).

It might have been a turd, but they polished the living s*** out of that turd

 

You forgot the question at the end where the person is shocked because all teh asset use in one level is contain in one slide. I would the return on investment seems worth it. Also Ethan carter the game did use photogrammetry and was just a bunch of indies.

 

Everyone nowadays focuses too much on the visuals but not enough in the dynamics of the worlds (except Nintendo).

 

I post a scene in a previous topic with similar subject, but it's more relevant here. So this is the video i made and it's using only the default stuff from Unity and their Post Process package. Day Time part is just precomputed GI and night time is all baked.

Something to note is that i found out recently that the AO was disable in the post process when i made the video...
Now if i were to add other effect such as HXVolumetricLight and some other it could look really decent i think.

Anyway i'm now working on a scene in UE4 using those same assets, it will be a different scene but will see how it turns out (might take a little while)

Bonus shameless plug: for anyone interested i have a HTML5 and desktop(look better) demo: http://julientonsuso.com/ModularFantasyTown/

 

@Elzean
Looks good dude. In terms of promotional material - I would definitely suggest rigging up some characters and having them walking around or whatnot. It will add a lot to the scene. Maybe a couple little vignette highlights, like a toony married couple having a silly argument or a vendor trying to catch a chicken running away.

There are a lot of competing assets that are pretty similar, so it might be hard to 'stand out' in that space. Giving it a little more life would be good (might also suggest some ambient town audio).

 

Yes that would be great, i saw the low poly packs doing that (and it's really hard to compete with what they offer), but characters and audio might be difficult for me those are not stuff i do much :/
May be in the future I could give a try to very simple human characters... still hoping that some will be interested XD (the strength of the pack is in it's modularity)

I believe the style is slightly different but yes there is similar stuff, on the other hand it means it could may be complement some existing packages.
I'm planning an update soon with more pieces

But about the topic overall in this case i end up happy with what Unity render and the lighting, sure it's not triple AAA far from it, may be with more work and with the help of some external assets... And i will see how much different it will look in UE4.

 

Just pick up some toon models from another asset store vendor.

Email them and tell them you want to use their stuff in your trailer, maybe you guys could work out a little 'cross promotion' agreement. Both you and the other guy benefit from that kind of arrangement, so definitely worth considering. Maybe they'll throw in an extra chicken model for free