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.
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’.
Open up the oh-so wonderful XNormal.
Click the strangely hidden settings button that looks like a plug.
Click the ‘Tangent Basis Calculator’-tab.
Select Mikk-Tspace in the white area.
Check the checkbox for ‘Computer Binormals in the Pixel Shader’.
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
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!
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.
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!