Sponsored By

My Library of Free GameDev Resources, Tutorials, and More

Details on the GitHub repository where I keep a variety of free game development resources: assets, UE4 content, git and OS scripts, experiments, UE4 C++ code, sample World Machine files/output, etc. So: here's all that and why/what it is.

Trent Polack, Blogger

May 7, 2018

6 Min Read
Game Developer logo in a gray background | Game Developer

This article was originally posted on the Joy Machine blog maybe check it out too!

Some Things Should Just Be Free

For a long while now, I’ve been maintaining Joy Machine’s GitHub repository (MIT license) for a variety of free game development resources (for general usage, not just Unreal Engine 4 content). This includes links to good research papers and tutorials (which I need to be better about finishing — much less updating), articles, scripts, useful git configs, and other such randomness.

Specifically for Unreal Engine 4, however, I also have included a variety of content (and some C++ code of… borderline usefulness) straight from my work on Steel Hunters. This, obviously, doesn’t even come close to everything I’ve created for SH, but these are assets that I feel are so generally useful that I don’t see a point in keeping them for myself. I figure, someday, I’ll actually get financing for the full production of Steel Hunters and I want to contribute what I can to anyone that can benefit from some of the work I’ve done along the way.

I also maintain a living Unreal Engine 4 document that I update (on the rare chance I have the time to do so) for UE4-specific advice, links, good practices, code snippets, and other such things.

I have some old (and no-longer-maintained) UE 4.17-era assets, but I’ve since decided to stick with the most recent public engine version, so all assets use Unreal Engine 4.19 at the moment.

Recently Added Content

  • I continually maintain what I call “shaders” which are not, in the general sense, actual USF/USH/HLSL files, but rather just master materials I create for a generally-applicable use case that have a variety of potential options for different uses. I call them "shaders" and not "master materials" because I take a unique approach to these (some of which I've written about before) to rely on a static switch parameters to minimize the overhead of the compiled material instance. Anyway, including amongst these are:

  • My “standard” shader (and variants of it) for most materials you’ll need.

  • A standard shader more geared towards metallic materials (the standard shader has since acquired some of this shader’s features, but not all).

  • A metallic clearcoat standard shader.

  • And shaders for SpeedTree assets — one for meshes and one for billboards.

NOTE (on “shaders”): I’ve heard some concerns about this approach but, thus far, I have yet to see any real concrete performance issues (render time, memory usage, shader complexity) that raise any red flags for me.

  • A whole lot of material functions:

  • Various luminance detection functions (used in a post material for edge sharpening).

  • Fuzzy/metallic shading functions to exaggerate some shading styles.

  • Albedo tinting functions (using either a basic tint color & intensity or a Hue/Saturation/Value method of tinting).

  • An old-ish procedural gerstner wave-based water generation function set.

An Important Note on Textures

I follow a consistent and best-I’ve-found convention for PBR textures:

  • Albedo Map: Default compression (sRGB), no alpha channel (unless being used as a terrain layer albedo map).

  • Normal Map: Normal map compression type and, obviously, linear color space.

  • Metallic/Roughness/AO/Cavity Maps: Default compression (linear color space). If imported individually, my general preference is a grayscale PNG.

  • Compact Map (Metallic/Roughness/AO): A map that packs the Metallic data in the Red channel, Roughness data in the Blue channel, and AO data in the Green channel.

  • Use default compression and a linear color space.

Avoid the use of an alpha channel on imported UE4 textures as much as possible. Any imported texture with an alpha channel does not handle the standard compression formats very well and ends up being far more resource-heavy than you’d expect (from my very, very vague memory of years ago, I believe an alpha channel using DXT5 compression results in UE4 having the alpha channel use up as much resource space as the combined total of the RGB channels.

A Special “Hey, It’s Today” Present

Today, since I’ve been seeing a number of posts on reddit and the UE4 forums about landscape authoring, I added the node graph that I used to create a previous iteration of the landscape for the Nevada sandbox environment for Steel Hunters.

  • The main downside to this particular asset is that it requires both World Machine and GeoGlyph. That’s pretty standard fare for a lot of environment artists, of course, but it is an unfortunate restriction.

  • Since this is a downside, I also added the output of this node graph in the form of a height map, some layer masks, and a high-poly mesh.

  • Caveat: These outputs are slightly older than the repo’s node graph, as I did a quick clean-up pass on that graph before putting it in the repo. If I find time to generate the whole thing again, I’ll upload the results of that.

An older screenshot of Steel Hunters using this data (though I believe this screenshot was trying out a procedural landscape material instead of using the layers):

NOTE: Aforementioned procedural landscape texture is a mistake; use precomputed layer data as much as you can.

Other Work-in-Progress Work

There are things in the repo (like “Joy Create”) that are in on-and-off development and, as such, barely worth looking at; in this case, I’m working on an Electron-based l-system/turtle placement grammar set (for instancing shapes/meshes) and rendering the output (dynamically) of the ruleset someone types into the code column in a viewport to the left. I think this will be neat some day, but it’s very much a work-in-progress.

Final Notes

I do my best to update this repo, but it’s a non-trivial task, so a lot fails between the cracks. Documentation gets out of date and, since I don’t have a dedicated project for testing all these assets in isolation, I rely on anyone using the repo to just contact me or add an issue on the repo if anything is problematic.

Beyond that, if anyone wants to contribute, by all means feel free to do so. Neither I nor Joy Machine get any financial benefit from this whole thing; it’s solely being done to help the game development and UE4 community as I work.

And: A Final Link to the Joy Machine — Repo of Things

Read more about:

Featured Blogs
Daily news, dev blogs, and stories from Game Developer straight to your inbox

You May Also Like