Speed up UE4 lightmap build times by 500%

For medium sized scenes, where you may have more render threads than objects in the scene, the trick to fast lightmap renders is to keep the lightmap resolutions even. But I’ve recently discovered the missing elements in my scenes that speed up my renders by 500%!

Let’s say for example you have a total of 24 cores to render your lightmap with and your scene is only 24 objects, as 23 of your objects are finished, the remaning cores are unfortunately not going to help out your remaining 1 objects, they will do absolutely nothing. Thus whether you have 4 cores or a million cores is not going to matter, if your entire build is stuck waiting around for this one remaining object.

One solution to the above problem is to break up your scenes into more objects, then as threads are completing their job they can pick up new objects to work on. However there are some cases where you just don’t want to break up your scene too much (for example for batching performance reasons). In that case one solution (or so I thought) was to cap lightmap resolutions.

If the entire scene is made up off 64 pixel lightmaps except for 1 object that has a huge 4096, then the entire lightmap render will have to wait around for that 1 map, since lightmap resolution is the main indication of how long an objects lightmap will take to render. With that said however, there was one problem.

Despite having capped all my lightmap resolutions to 1024, my lightmap built had to wait 20 minutes because of this one object: the floor of my scene. But why? The floor had a 1024 lightmap just as the other objects, what I didn’t take into consideration was unmapped texels!

Unmapped Texels: The Secret to Even Lightmap Build Times

As it turns out, as something like a floor is easy to UV map, the lightmap UV for the floor covered pretty much the entire 1024 lightmap (with it’s padding, only 3% was so called unmapped texels). The other objects however was significally more difficult to UV map due to the complexity of their shape (let’s say a sofa with cushions, for example), despite a carefully laid out UV, a whopping half of the pixels of that 1024 lightmap UV was actually empty space inbetween objects (to avoid mip map bleeding). Therefore all thought the resulting lightmap size was the same, there was significally more actual pixels rendered for the floor due to it’s lack of wasted gaps in the UV layout.

Therefore the floor took 3 times longer to build the lightmap for.

Since the “wasted” UV space of the complicated models are desired, the solution is simply to take the unmapped texels procentage into consideration when assigning lightmap budgets. So if you want the floors lightmap build to render as fast as that of the sofa, you could set the sofa to twice the resolution, or split the floor up into smaller peices.

Lightmaps for LOD’s in UE4

One of the confusing and undocumented parts of UE4 is how it handles lightmaps on items with LOD’s. Many ‘Answers’ has been that they don’t (that each LOD simply assumes similar UV layout and thus re-uses the lightmaps) but that’s simply not true. Just check your baked lightmaps yourself and you will see that UE4 generated a lightmap for each of your LOD’s.

Unfortunately there is no custom lightmap settings for each LOD. In my quick test it appeared that LOD1 was 66% size and LOD2 was 33% size, but is that perhaps depending on other factors, such as the distance values you set for each LOD transition? Who knows!

This confusion is highly annoying, because a lot of studios have a fixed asset pipeline where the artist needs to create a couple of LOD’s even if they feel the difference is small. For example imagine that you modelled a mint-condition carboard box, you find that the difference between the polycount in LOD0, LOD1 & LOD2 is negetable, then the extra lightmap space required for these might be way more expensive than what little performance you gain from saving a few polygons.

It’s funny how in modern games we can be so relaxed with polycounts since our graphics cards are getting so good with handling polygons, yet your lighting artist still have to make enourmous quality sacrifices to keep his lightmap resolutions down. Yet Epic doesn’t care about documenting or explaning much of what’s going on with the lightmaps, let alone add features such as custom LOD light map resolutions or the option to re-use lightmaps across LOD-levels.

For now my recommendation is probably to keep using LOD’s but only to a reasonable level. (If you’re using baked lighting) Don’t go thinking you’re making huge savings making 4 LOD’s for your hard-surface assets, because you may actually be adding performance cost than saving.

Bake Normal Maps 3ds Max to UE4 with XNormal

A lot of game developers gets frustrated because UE4’s documentation regarding making normal map just doesn’t work! Following their steps kind of works, but faces that should be flat just becomes weird when the lighting hits certain angles.

Here is the missing important step that Epic forgets to mention in the documentation: ‘Computer Binormals in the Pixel Shader’.

  1. Open up the oh-so wonderful XNormal.
  2. Click the strangely hidden settings button that looks like a plug.
  3. Click the ‘Tangent Basis Calculator’-tab.
  4. Select Mikk-Tspace in the white area.
  5. Click configure.
  6. Check the checkbox for ‘Computer Binormals in the Pixel Shader’.
  7. Re-render your normal maps.

3ds Max Camera Coordinates & Rotation to UE4

Today I wanted to match a camera between my 3ds Max scene and UE4, I found some plug-ins and stuff but really I just wanted to copy-paste the values rather. In case anyone wants to do something similar, I’ll save you 10 mins by posting my findings.

UE4 Camera Location:

X = 3ds Max X
Y = – 3ds Max Y
Z = 3ds Max Z

UE4 Camera Rotation:
X = 3ds Max Y
Y = 3ds Max X – 90
Z =  (3ds Max Z – 270) * -1


Amazing UE4 VFX from China (with Tutorial!)

During a recent binge-watching of Youtube I found a VFX reel that absolutely blew my mind. Far from anything I’ve ever seen in realtime VFX’s I was worried my brain might have short-circuited a fuse in amazement. With the unnamed Chinese artist shrouded in mystery I decided I must look deeper, to my surprise found an amazingly detailed 3 hour video-tutorial, available only for those with a little Chinese know-how.

Since my days of working with Unreal Engine 3, I was blown away when I discovered what an amazing improvement Unreal Engine 4 is. Everything from blueprints, constructor scripts, deferred lighting to PBR workflow made me feel like it was a brand new engine, until I opened up Unreal’s particle editor, Cascade…

Unlike my previous amazement, Cascade was the exact same mess I remembered doing my first Unreal VFX 10 years ago! The new black color-scheme did little to hide the fact that it’s the exact same tool with the same bugs still present. I was considering buying stocks in Apple, until I realized I’ve not traveled back in time, I’m still actually in 2016. Epic just hasn’t made much improvement to their particle editor.

What HAS happened however in the last 10 years is the vast improvement from the artists using the tool. I could show no better example of this than this VFX reel I found on Youtube, demonstrating some of the best realtime VFX’s I’ve ever seen.

Although I can pause this video at any time and reverse-engineer how a particular element was most likely made, if I attempt to do so at full-speed my mind just explodes of over-stimulation. I realized I MUST know more about these effects and its genius artist. With the uploader silent and anonymous I didn’t have my hopes high, but to my surprise my Chinese friend managed to dig up a 3 hour video-tutorial! It’s ridiculously difficult to find and requires a bit of knowledge how to log into Chinese services, hence I decided to share this knowledge for all to enjoy. Click to check it out!

Is UE4 Distributed Rendering Worth It?

There are countless tutorials how to set up UE4 (Unreal Engine 4) to distrubute lightmaps tasks across a network, but I wasn’t interested in the ‘how’. I wanted to know if it’s even worth all the hassles associated with DR (Distributed Rendering). My curiosity got the best of me so I dove in to find out!

After a life of experiments with buggy DR’s my question was “should I even bother?”. The time I’ve previously spent troubleshooting mysteriously idle render machines has by a hundred-fold exceeded the time I’ve gained from its marginally faster renders.

My results have been disappointing regardless of software (primarily I’ve used Mental Ray and V-Ray) yet one little fact made me wish to give UE4’s DR a try. Despite having frequently complained about poor documentation for the Unreal Engine, I must admit I’ve never once been disappointing with the software. Despite DR probably being a low priority feature, I had a feeling Epic might leave me jaw-dropped impressed as usual. I was not wrong.  Click to see the results of my Swarm/Lightmass Distributed Rendering.

High-Res UE4 Screenshots without Crash

One of the great things about GPU rendering is how insanely fast you can render high resolution. While rendering things like lightmaps with GI is still time-consuming and resource-hungry, the actual 3d rendering is near resolution-independent. Do you want to render at 4 times your usual resolution for a print? As long as you have an extra spare couple of seconds, you’re in luck!

Unlike most engines, in UE4 (Unreal Engine 4) taking a high-res screenshots needs neither custom code, plug-ins or even memorizing command-line syntax. Simply use Epic’s provided ‘High Resolution Screenshots Tool’.

There is only one little problem…

Althought the tool is programmed flawlessly (as is the case with all of Epic’s tools), you may run into a problem from another source. With hardware accelerated 3d being primarily developed for realtime graphics, your graphics card assumes you desire to run a smooth frame-rate. When your ridiculously detailed screenshot is taking forever to render, your graphics card assumes a bug and terminate the process.

Although 2 seconds may be an eternity in a world of 60 fps gaming, it’s nothing for rendering still images. Coming from CPU offline rendering where a single image render can be an overnight process, 2 or even 100 seconds is less than it takes me to go fill my cup of water.

Luckily I found there is a way to tell your well-meaning computer to take a chill-pill. To bump up its default panic mode threshold of 2 seconds into whatever value you desire. After setting mine to a glorious 40 seconds, I can now save screenshots at an arousing 15360 by 8640 pixels (including buffer visualization targets). I find this to be the ultimate resolution as it down-samples perfectly into 8k (my ideal editing resolution). So what’s the secret to taking high resolution screenshot without crashing? Click to find out!