Buring the Engine Down – fast – fxguide
ActionVFX has partnered with Undertone FX, which specializes in creating real-time effects for video games and VR experiences including AAA titles such as Halo, Call of Duty, etc.
ActionVFX believes one of the biggest challenges the industry is facing is the fact that, while there’s now widespread adoption of the Unreal Engine for virtual production, people are finding that they need really high-quality assets to work with inside these virtual environments. Teams and companies such as Quixel have done an exceptional job but there is room for much more. Luke Thompson, Chief Operating Officer at ActionVFX believes that “pushing the boundaries and raising the bar for the in-engine FX comes from beginning with real visual effects assets.”
The two companies first combined product is the Ultimate Fire Pack. The teams started with real fire and then built the assets into a UE particle system. “This allows the user to simply adjust the sliders to alter spark amounts, smoke density, size of the fire, and more,” Thompson explained.
Fxguide spoke to David (DJ) Johnson of Undertone FX about how they brought these real-world elements to life inside a game engine.
FXGUIDE: How was the production organized?
DJ: First was a handoff of the filmed fire footage from the ActionVFX guys. We started a Perforce Depot so that we could get multiple artists working on it. We probably had five or so artists touch the project when all was done, but generally, only one or two artists were on it at any one time.
The first step was compositing, which our artist Faraji Benson took point to get the footage from film ready to game engine consumable. Then we had other artists take over the Cascade, Niagara, Shuriken, and VFX graph implementations. The Unreal one came first, and the Unity was a rough match of what we had set up in Unreal. Our artist Neal Krupa did the heavy lifting on the blueprint and Niagara technical setup. I personally did a polish pass to work out any kinks and make sure the quality was there across the board.
FXGUIDE: What are the main challenges when creating such packs?
DJ: Sure, the stages in summary were
1) The footage is brought into After Effects and narrowed down to the loopable sections whose frames can then be output in rows and columns in a single 4k texture that the game engine can consume.
2) The textures are brought into Unreal, and Niagara particle systems are created that use the fire as a texture. The fire footage is the basis, but other particles/textures/layers are added for embers, smoke, glow, lighting, distortion, bursts of embers, etc…
3) It still needs to work in full 3D, so some treatment is done to make the fire work, when looking straight down at it. Some “fire licks” were added, and the primary fire texture is fresnel-ed out, so it disappears when looking straight down on it from above.
4) There is quite a bit of material work to make it work for all cases… clipping through geometry, we need a depth fade noise, fresnel when seen edge-on, emissive overdrive, (- so it’s nice and bright and glowy), phase randomization so that the particles aren’t all in sync with one another, etc…
5) We then did lots of blueprint work paired with Niagara setups so that a placed actor has a ton of “user variables”. This allows a non-effects artist to use the assets and customize them. Such as achieving subtle tweaking and disabling whatever layers they don’t want to use.
6) Then we had to lay it all out in a gallery setting so that we can demonstrate each version of the fire placed in a level, looking good, and a “texture gallery” that shows off all of the textures in isolation.
7) We did this work all in Cascade, for teams that are on older builds of UE.
8 ) We then did it all again in Unity in both Shuriken and VFX Graph. It was a lot more of an undertaking than we initially expected.
FXGUIDE: How are the effects optimized for different projects? What are the peculiarities here?
Both Memory and CPU load?
The textures are implemented in a “the whole shebang” approach. We expect the typical user (non-games effects artist) will just open the gallery level, copy the placed nodes (likely Niagara versions) and go to their level… paste. When doing this, you’re going to get all the full rez textures, and the memory load will be about 300MB. Probably too high for most game projects, but fine for “no-hassle” virtual production implementations.
We expect that users will “tune to fit” the memory load. If it’s a big-budget game, and these are hero elements… then, by all means, go to town, use them as is. But that’s probably too much memory, so there are two primary ways to lower the memory:
A) Drop MIPS. Tell the engine to max the texture resolution to 2k, instead of 4k. That will cut the memory down to around 75MB from around 300MB. This takes about 5 minutes to do. A user is just changing a single setting across 16 textures.
B) Fewer variants. The fires call all 4 variants for maximum randomization. It’s not hard to change this to use just 2 or 1 of the variants for each of the sizes. This will also “quarter the memory load”, from 300 to 75MB.
C) if one does both A and B, – and the user is down to about 19MB. So, it’s fairly easy to customize these to whatever memory targets you want to hit… but right out of the box, they are set to maximum quality.
This is where the Actor setups come in handy. Again, our philosophy was to ship them with “highest quality” right out of the box, with easy-to-use suppressions to lower the CPU load. The actors have checkboxes for almost every layer in the fires. The heavier elements are the popping embers (high particle count GPU particles), so although they are GPU particles, they give a bit of a CPU spike as they spawn a lot of particles in a single frame. These can be just turned off to lower the load. Or… turn them off on 90% of the placed instances… but leave one or two in any area that has them on so you get the effect, but mitigate performance concerns. The light, distortion, etc… all of them have single checkbox disables, so that people can balance load vs target platform. If you’re using these on mobile… just turn pretty much everything off but the main fire layer, and you’re good to go (though… add the memory suggestions above for mobile also)!
We do have some additional automatic performance improvements we’re intending to include in our next update, for better distance auto culling, but already they are ready to rock in full game production.
The real-time fire is compatible across all OS’ that support the Unreal Engine. Note the Epic site had the Ultimate Fire Pack listed this as only being Windows other OS systems are supported. They also work in UE5, while only being listed for use in UE4.
Note: images above from animated feature film RIFT, courtesy of HaZimation.