LogIn3d artist Alireza Khajehali talked his approach to vegetation, photogrammetry and perfect rendering for games.
3d artist Alireza Khajehali talked his approach to vegetation, photogrammetry and perfect rendering for games.
Foliage
I think scale, optimization and color palette form a very important triangle when working with foliage. Doing each of them can be relatively easier and less challenging than maintaining a balance between the three.I think that’s where all the challenge is. If any one of the corners isn’t very well taken care of, the work wont pay off i.e you have a very nice looking tree with great textures but it’s not as optimized as it should be, which makes it near to useless. Talented vegetation artists who can nail every aspect of an asset are really a scarce resource in this industry. People such as Tom Deerberg are very good example to follow. Deconstruct their work, inpect all the details and see how it’s done.
The scale is very important. I haven’t really noticed it where someone makes their foliage smaller than it should be, but I very often see foliage being bigger than the correct size. Scaling up the vegetation assets in engine is one way to fill the screen with less instances, but on the other hand it can easily breaks the immersion. For example, you very often walk by some bushes in games and see leaves being too big compared to player head or hands. So it’s very important to keep all the scales in check and well balanced before exporting the assets to game engine so you wouldn’t need to scale them up later. If bush/tree needs to be bigger, I prefer to add more leaves/branches to it in the modeling software instead of scaling it up as a whole in game engine.
Playing some high end titles such as Crysis 3 and Star Wars Battlefront, I learned a lot of things regarding foliage. For instance, one of the things I learned is that we should create large cards, larger than what people typically tend to create. And so having large cards that extend more means you can have less cards which greatly reduces the tri count. You can even assemble several large cards to resemble one huge card. I actually managed to cut my redwood tree Tri count from ~12,000 Tris down to ~4300 Tris with doing just that.
The rectangle in the middle is 180cm high, about a man’s height for scale reference. Notice the vertex colors, Black: Fixed, Blue: 50% movement, Red: 100% movement. And here’s how the vertex colors control the wind amount in engine:
Note: I use a custom wind function but for the sake of cleaner demonstration I used the SimpleGrassWind function.
When it comes to materials, color palette is what makes the texturing pay off! Colors should be selected very wisely in order for the asset to sit well on the environment. Trunk base color in relation to the ground material, leaves color, leaves backside color, SSS color and intensity, world space color variation, per instance variations, etc. are very important. So, simply plugging the texture maps to input slots….. is forbidden.
Photogrammetry
I don’t personally do photogrammetry (just clarifying for readers) that’s very time consuming process for me. But I use Megascans, thanks to Quixel for having done all the scanning already and putting it all out almost for free (only $29/Mo for a decent subscription).
Since scanning a surface gives you more close to real life values, using scanned materials is the best route to take if you’re aiming for realism and in my case, I’m always obsessed with achieving realism and that’s the main reason I’m using Megascans besides saving time. You might think using Megascans means cheating or doing zero artistic work Resist! I’ve heard that many many times from different people. The truth is by using Megascans you’re only saving the time you’d spend on the photogrammetry process. But it still takes a lot of artistic effort to put together an environment for games using Megascans.
In my personal opinion Megascans and Art Direction are two opposing issues. For example Art Director wants to apply his own vision so what happens is a good chunck of Megascan assets end up being heavily modified. That’s what I do 99% of the time working with them. You see me building a project entirely with Megascans but you can’t find something in my work that you can just go and grab from the Megascans library. In some instances I’ve created brand new assets by mashing Megascans assets together. Here’s an overgrown rock I’ve created, it initially looked like the one above it.
So if you’re using Megascans for your projects, don’t be afraid to make some changes. Besides that, in case of foliage the issue is that leaves and foliage slightly change hue from one location to another depending on the type of weather and the amount of sun light the leaves receive so when you use atlases from different locations and want to put them together in one location you need to adjust the hue on both to match each other closer otherwise they look not so well. It can be doing changes to Albedo or creating a uber shader that allows you to extensively customize the colors and other properties of the material. I prefer to do both.
When manipulating the assets i.e changing colors, luminosity etc. the lighting has to be as neutral as possible. What I usually do it to keep the directional light intensity at ~5, load a pure white texture in skylight with intensity of 0.18, create a closed area with BaseColor being 0.18. This prevents the eyes from being distracted and let’s you focus on the assets more easily.
Using Megascans
All assets are fine for real time use. For meshes LOD0 is usually around 7000 Tris and that can be quite high for in game usage so you can probably discard LOD0,1etc. and use the other low polier LODs. For materials one thing you can do is to optimize them before importing in game engine by channel packing the textures. But atlases do require some more work before you can use them. Not that they are not usable as they are, but if you want to keep it all optimized there’s some manual work to it. Atlases contain content that were available at the scanning time and whatever you need aren’t necessarily put on that one atlas for you, so you need to crop many atlases from here and there and make your own. For example there is an atlas containing fern leaves, then there is another atlas containing clovers. You can easily downsize the clovers and put it somewhere on the fern atlas. Doing this many times over you end up saving a lot of memory. Another reason you’d want to modify atlases is that you might not need everything an atlas contains, you might just want that tiny leaf on the whole atlas, so you’d crop that and drop it on an existing atlas you are using.
And like I said, when you’re building trees, the leaves cards should be really big containing branches, smaller branches, and finally leaves. Now that the number of cards is massively reduced, we’re able to spend more and more tris on minimizing overdraw as overdraw or transparency costs more than shadowing more tris.
Another thing to do is to implement switches for effects inside the material for effects such as color variation calculations, detail texturing, etc. so by applying a different material instance to LODs of the main mesh, these effects can be switched off which makes the LODs have much less shader complexity apart from having much less tri count.
Implementing Megascans elements
I import the materials as usual, no particular setup except that I multiply AO on Albedo before importing it, that’s because UE4 does not produce micro AO in direct light. I have thoroughly explained this with images in this post.
For meshes it’s very straight forward. I import them in 3Ds MAX, correct the scale, group them, add to “level of detail” so the lods will work and then export them out as .FBX, ready to be imported in UE4 without any issues. Once in engine, I use Grass Tool for the procedural distribution of what I shouldn’t place by hand such as grass, and then I use foliage paint tool for larger assets such as bushes and trees. When I get near points of interest I tend to place them individually by hand to have maximum control over placement, rotation and scale.
Choosing the right meshes and materials needs a good amount of experience. I used to do a lot of back and fourth but I can now easily visualize what elements I need to put together so I grab the right assets and make the right changes to them. Still sometimes I need to go back and fourth until I get the desired look, that’s an inevitable process for an artist. It’s the same as keep painting a portrait with different colors until you’re happy. I call it “The Bob Rossing process”.
Lighting and rendering
For lighting I use a dynamic directional light, dynamic skylight, I use a cubemap in PPV and turn on LPVs. From there it’s all about doing all the trickery in the world to create a convincing lighting. Worth mentioning I try to get what I want without post processing, and once I’ve got it, I use subtle post processing to fine tune my final results. It’s just my preference.
UE4 lighting has a few issues that I really hope for Epic to look into them.
1. Directional light (sun) does not support physical unit (Lux). So most of the time we’re casting an unknown amount of light on our game worlds. Physically Based Materials were introduced to be able to achieve more true to life surface definitions, and to see the surfaces the same way you see them in real life, you also need Physically Based Lights because light sources in real life, from tiny ceiling lights to Sun, don’t have random values. I really hope Epic will try to properly implement Lux for Directional Light and also do a few updates to Skylight as well.
2. SSS isn’t weighted correctly. What happens in real life (and also happens in other game engines) is that once an intense amount of directional light hits a surface, SSS starts to show it’s effect. i.e you put a flashlight behind your hand in both real life and UE4 and the hand will turn red, the problem is, in UE4 you don’t need the flashlight behind your hand for the hand to have the red tone. Sparse ambient light (skylight) is leaving the same effect as dense directional light (sun, spot and point lights) where the correct behavior would be for skylight to have a fraction of it’s current influence on SSS. Notice in the picture below, this is a sphere with grey base color and green SSS color, however, when adding a Skylight all you see is the SSS color instead of seeing the grey base color with very very subtle green hue.
(Image by Deathrey)
3. AO is one of the biggest pieces of the puzzle. Even the best assets wouldn’t look good without a nice ambient occlusion. For small scale AO UE4 uses SSAO which isn’t the best solution available today. It provides minimum satisfaction for both interior and outdoor. To get an acceptable amount of AO on meshes such as grass or trees you’d need to crank up the SSAO intensity to somewhere around 0.8 to 0.9, which on the other hand leaves bad results on some other assets. Crytek’s SSDO actually does a very nice job at producing small scale AO compared to SSAO. But it seems to be an unrealistic expectation from Epic. On the other hand Nvidia’s HBAO+ provides much much more accurate and consistent results and is already there on Nvidia’s UE4 branch waiting for Epic to simply merge and maintain it.
4. Large scale AO is as much important as small scale AO, if not more. DFAO produces artifacts known as dark spots. Checking “Generate Distance Field as if Two Sided” solves the issue for most assets, but not on big meshes i.e trees or large rocks. The workaround has always been reducing the DFAO intensity to make the artifacts less visible. But strangely enough I found out when using a cubemap in PPV most DFAO artifacts or over occlusion go away. You no longer need to decrease DFAO intensity in order to make those artifacts less visible.
Note: Loading a cubemap in Skylight doesn’t have the same effect as loading it in the PPV.
Again, on the other hand, Nvidia’s VXAO provides superior results compared to DFAO, is already working in Nvidia’s UE4 branch and is waiting for Epic to merge and maintain it.
Cryengine’s Heightmap based AO:
Based on the results I think Epic should really consider merging HBAO+ and VXAO to let the artists take their work to the next level (which is the norm in other engines).
Anyways, let’s not forget with UE 4.15 default tonemapper is changed to Filmic Tonemapper. When using this tonemapper you experience some unpleasant high contrast and saturation on colors compared to what you had before. This also results in dark levels clipping a lot. While this is more film like, it’s not like real life at all.
Here’s a comparison between Original, Hable and ACES (filmic) tonemapper. You notice ACES is the unrealistic one.
If you want to help that you need to simply reduce the Slope value in PPV from 0.88 to somthing like 0.73 to bring the saturation down and reduce the clipping, making it look more like pre-4.15 picture.
For taking screenshots, if it’s something I want to zoom on I use Cine Cam with default settings and only adjusting the focus distance. I do detail mapping on my assets so when taking close up shots it’s the detail mapping you’re seeing and not some 8k material. Then I use PrintScreen that gives pure 1:1 results. Hide the windows taskbar and fullscreen the UE4 editor, press G on the keyboard to turn off icons and press Ctrl+Shift+T to hide the toolbar before hitting PrintScreen. Also important to turn wind off on foliage before taking screenshots. When they are in movement TAA leaves some nasty artifacts on them, and when taking a screenshot, the picture becomes too noisy so just make sure nothing is moving.
Special thanks to you and Quixel,