A tasting of the dynamics and geometrys side (of) effects

This release is not about the number of features, but about finishing what was started, achieving true production readiness, robustness, performance, and ease of use. It’s a version focused on quality of life. Feature sets like MPM simulations and Karma have matured like a good wine. The machine learning tools respect the artist’s skill set and have left their state of play are actual usefull in production.

Even though SideFX remains modest in its official statements, Houdini 21 is a massive release. For the feature-hungry among us, the highlights include a fully matured APEX; a refined and clever animation and rigging framework; a simulating Copernicus (think Substance on Dope), and in the VFX realm, the production-ready MPM Solver. On top of that, we’re seeing machine learning tools popping up in all the right places (AI for people who don’t expect a Pixar film from a single click), faster and expanded rendering with Karma, and a healthy dose of quality-of-life improvements.

Since our editorial cat can only count to 300, we can’t tell you the exact number of new or improved features, but we’re impressed nonetheless. And soon, you will be too. To avoid overwhelming both writer and reader, we’re breaking this article into a mini-series. We’ll start with VFX & Geometry, followed by Solaris & Karma, Copernicus & Terrain, and the massive Animation & Rigging tools.

MPM

One of the most exciting additions in H20.5 was without question the MPM Solver. The MaterialPointMethod truly allows you to simulate a wide range of different materials. From water, snow, and sand to honey, metal, and concrete, all within a single Solver setup. The geometry is simply substituted by points or particles, which are then simulated. The different materials interact physically accurate and constraint-free, purely based on their assigned parameters.

The initial release was already impressive, but it left users standing somewhat in the simulated rain when asking: “How do I get a proper mesh with UVs?” That exact issue has now been beautifully solved in H21. Any MPM simulation, whether rigid body or fluid, can now be meshed (as polygons or SDF volumes), including UVs, color, and other attributes, using no more than two nodes.

A nice and usefull addition to this workflow is the MPM Debris node, which generates new points along fracture lines as sources for smoke, dirt, or secondary debris effects. So let’s take a look at meshing hard and fluid or granular surfaces across a few setups and scenarios and wrap things up with a creamed cookies drink while watching the official and very excellent MPM demo.

Surfacing MPM Simulations

Testing time! For this test setup, we’ll have a clay ball smash into a vase model, paying close attention to UV transfer and the generation of smaller fragments through the Debris Source. The easiest way to start an MPM simulation is by typing “MPM Configure” into the node search. This gives you a complete set of starter nodes right away. (Under MPM Configure, you’ll also find plenty of additional example setups for study or creative repurposing.) By the way, the MPM container on the far right controls the overall resolution of the entire simulation.

We replace the default sphere with our own model and can now assign materials directly inside the mpmSource node and tweak them to our liking. It’s genuinely fun. Feels a bit like a mini-game. Since a concrete material would be more realistic but also quite boring as a vase material, we went with Chunky Snow instead. The environment comes in via an Object Merge directly into the mpmCollider Sop, ready to go. Our clay ball, the antagonist of this little simulation, isn’t a collider per definition but another mpmSource ready to be smashed, merged with the vase and given its own material behavior, Chunk Soil.

To make sure the particles can actually see and “love” each other, we need to enable Particle-Level Collision in the solver. The new Auto Sleep feature helps keep the vase passive until the collision happens, preventing it from collapsing at frame one and saving quite a bit of compute time.

Since the clay ball will be meshed as a fluid and granular surface and the vase as a rigid object, we first separate the MPM particles using a Blast node, filtering them by their respective source names.

For surfacing the vase, we use the mpmPostFracture node, which takes the rest-geometry and the MPM particles as input. This node essentially breaks the geometry apart “end to start,” so it needs to be fed the final frame of the simulation. After that, we choose either Voronoi or Boolean Cut as the fracture method. The latter can generate interior details, subtle irregularities on the inner faces of the fracture, that weren’t visible before, and it’s also faster to compute. We can further control the number of pieces as well as define the minimum fragment size at which new pieces should be generated.

The final node in the chain is mpmDeformPieces, which transfers the newly generated fracture geometry onto the MPM particles and just like that, the vase shards, physically convinced they’re made of snow, go flying through the scene, complete with perfectly intact UVs. For more of a muddy mess, we could have generated a liquid or granular surface instead, but we’ll save that for the clay ball. The result from the Debris Source, which lets you precisely define when and where particles based on fracture are emitted, is then passed into a POP network, including collisions from the vase and background).

Time to get serious:

Continuos Emissions & Surface Tension

With this new option, you can quickly fill containers, simulate expanding materials, or layer different materials on top of each other. The option is located in the mpmource node and spreads new particles apart using positive pressure.

Let’s take our vase and let a thick, viscous something ooze out of it. A good chance to show how simple MPM can be: if we want things to float inside the fluid, they just need a lower density. A few cubes are generated and assigned a jelly material. Two geometries, two MPM Sources, merged and fed into the solver. That’s all it takes. Just as easily, you can mix different fluids within the same setup. And for a bit more drama, we can dive into the solver and add a POP Wind node with some turbulence.

Surface tension allows for realistic effects such as droplets, tendrils, and flowing water. H21 introduces two new ways to control surface tension for both liquid and viscous materials inside the MPM Solver. The Point Based method offers higher accuracy and stability, making it ideal for small and detailed simulations. The Grid Based method, on the other hand, is optimized for performance and handles millions of particles more efficiently, which makes it better suited for large-scale scenes. External forces and friction can be increased if objects keep moving when they shouldn’t. Otherwise, you might end up with a scene straight out of Terminator 2.

To achieve high levels of detail without an unnecessarily large number of simulation points, the new, more precise collision detection allows you to use the fracture edges of a simulation as the source for a targeted secondary simulation. The attribute Jp (Plastic Compression/Stretching) is key here. It can be used to isolate the fractured areas and feed them into a Surfacing node set to VDB mode. This resulting volume can then serve as the source for the second simulation. And don’t forget to use the main simulation result as a collider.

And finally to top it off, the official demo. A detailed breakdown of that beautiful cookie shot.

Machine Learning in Dynamics

You won’t find any generative AI native in Houdini, but rather a growing collection of smart, locally running models, often trained by yourself, designed to simplify or speed up time-consuming tasks.

Surfacing Flip, Vellum & Particle Simulations

Alongside Neural Point Surfacing for MPM, the new Neural Point Surface and proven Particle Fluid Surface nodes now bring neural meshing to FLIP, Vellum, and POP simulations as well. Until now a bunch of points are trying to reconstruct the surface of a material. With neural meshing, you can now achieve much sharper, more detailed surfaces across a both high and low frequencies. The result: surfaces that are no longer uniformly fuzzy, but crisp, structured, and temporally stable. As before, you can train your own models, but even the included presets already produce finer details. And thankfully, the whole thing is GPU-accelerated.

Volume Upres

The core problem behind volume up-resing: for efficiency, artists often create and approve low-resolution simulations. But once the voxeldensity is increased, the overall shape of the sim tends to change. With the new tools, a low-res simulation can now be upscaled while preserving its exact shape. This not only keeps previously approved versions intact, but also allows for far more iterations. A model that’s been trained on a specific motion or behavior can now upscale multiple variations of it.

The Billowy Smoke recipe (or shelf tool) comes with a pretrained up-res model already integrated. Let’s start by looking at a comparison between the low-res input simulation and the 3× up-res result.

Details are nicely added, while the overall shape is preserved impressively well. Caching took a bit of time, but it’s still far faster than running a full high-res simulation. The real idea, however, is that we can now reuse this up-res model for all our future Billowy Smoke setups and honestly, we probably should. So, let’s quickly modify the setup and see if we can break the upscaler.

This time, the solver runs at a voxel size of 0.05, using the 2× upscaler. The 3× model didn’t really add more detail, just extra waiting time. For a bit more fun, a Gas Wind with random direction and a collision shape were added. That collision shape, as it turns out, gives the upscaler a bit of trouble as seen below.

But when comparing the up-res result to a true high-res sim, it’s clear that the system is really good at preserving the base form. Doubling the voxel size in the high-res sim, on the other hand, changes the overall shape and eats up a ton of time but stays artifact-free. Or, if you really want perfection, you could just train a model specifically for this type of collision.

If you want to train your own model, this Equinox Hive talk walks you through every detail:

Zibra AI VDB compression

With this plugin you can save up to 99 percent of storage space when caching VDB simulations, which makes it perfectly suited for use in real-time engines such as Unreal Engine 5. The Zibra toolset, distributed via SideFX Labs, provides three dedicated nodes.

The first, zibravdb_compress, writes and exports .zibravdb files for use in Unreal and similar environments. The second, zibravdb_decompress, brings those files back into Houdini. And finally, zibravdb_filecache acts as a modified File Cache node that automatically handles compression, loading, and decompression for further use inside Houdini. Before diving in, you’ll need to download the model and obtain a license, potentially a free personal one if your revenue is below 100 K USD. The license management can be accessed directly from any of the three nodes.

For a quick benchmark, I used the Fireball Recipe and cached one regular VDB sequence alongside two Zibra versions with different quality settings. The original VDB sequence weighed 294 MB. The Zibra compression at a quality setting of 0.2 came in at only 5 MB, roughly 98 percent smaller. At a quality setting of 0.9, the result visually matched the original VDB almost perfectly while staying at just 36 MB, around 88 percent less.
That insane low file size at 0.2 naturally comes at the cost of lost detail, as visible in the comparison graph below. Still, the results are impressive and they open up the possibility for bringing volumetric simulations into real-time pipelines far more efficiently than before.

Pyro Shelve Tool Presets

Another way to get artists up to speed faster are production-ready presets, not just educational examples, but tools meant to be customized for your very real projects. Each of them comes with a ready-to-use Solaris network, fully set up for rendering straight out of the box. Even better, the Help section now includes a short guide and exploanation of important Nodes for every preset.

SideFX strikes a noticeably new tone here, aiming to flatten the learning curve rather than overwhelming newcomers with endless options (which, to be fair, they still do from time to time). These guides can be found under Documentation → What’s New → Pyro. In this section, we’ll take a closer look at three fundamentally different presets, each showcasing its own approach and creative use case.

Stylized Flame

With the refined Copernicus toolset, entirely new worlds open up: stylized fire based on a classic Pyro simulation, right inside Houdini. And if needed, even live-rendered in Solaris.

To put the claim of “easy adaptability” to the test, we took the Pyro Fireball preset and gave it a Toon-style makeover. Adding the VDB field “Flame” inside the solver’s output was all it took to make it work. The output from the Cop node, by the way, can be merged directly into the scene for further Houdini style editing.

Ground Explosion B

This shelf tool sets up a sparse pyro simulation featuring a large-scale explosion, smoke trails, and a shockwave. For more control and efficiency, it’s actually made up of two separate simulations, layered on top of each other and interacting through their velocity fields.

Candle Flame

A candle flame might not be the most exciting thing visually, but it’s one of those Pyro results you end up needing again and again. What makes this preset interesting, though, is the procedurally modeled candle that comes with it. Exploring that setup is almost more fun than the Pyro sim itself.

Thruster FX

In true H21 fashion and in the spirit of overall efficiency boosts, the new Thruster FX tool makes its debut: a setup designed to create engine and propulsion emissions with ease. It’s not just a new node, but rather a complete Recipe, a preconfigured network of nodes that some might, in hushed tones, simply call “presets.”

With a cheerful click on Thruster Exhaust in the Pyro Shelf Tools (or via Configure Thruster in the Tab menu), you’ll get a fully adaptable node tree, including a ready-to-render Solaris network. The effect itself isn’t a simulation but a cleverly layered, art-directable procedural system built around VOP Nodes. Multiple pyrothrusterexhaust nodes are stacked in layers, each responsible for different components like sparks, fire, and plasma. All working together to form a surprisingly easy to use thruster system.

So, what does it actually look like? And can it really be used straight out of the box, as promised? The short answer: pretty much, yes. The rendering comes surprisingly close to the viewport preview. To get it running, only a few connections inside the included Solaris network needed to be adjusted. For our small test scene, we did a bit of kitbashing inside Solaris, then added some glow and polish in Fusion.

Let’s take a closer look at the node, both from the outside and under the hood. The node expects a primitive as input, and a simple circle usually does the trick. It outputs both particles and a volume containing density and temperature fields. In the General tab, you can control speed, length, and the overall shape via a spline ramp. The Exhaust section handles the color ramp and lets you tweak the underlying noise pattern, which has a strong impact on the overall form. Under the hood, the node generates a VDB from Polygon, then modifies the result with a Volume VOP and a Volume Adjust Fog node.

As part of the ongoing effort to simplify things and lower the learning curve, SideFX has also released a good and detailed tutorial mini series: sidefx.com/tutorials/how-to-create-thruster-fx

Car Destruction FX

So that we can also crash the rigs built with the Car Rig SOP introduced in H20.5, Houdini 21 brings us the new Car Destruction Tools, led by the mighty RBD Car Fracture SOP, supported by the RBD Car Transform SOP. The first one takes care of fracturing and constraint creation, automatically handling the typical materials you’d expect in a vehicle: glass, metal, wood, and rubber. The RBD Car Transform SOP, similar to Transform Pieces, ensures that all pre-fractured parts are efficiently transformed based on the simulation points. You’re not limited to cars, by the way. Anything that follows the same basic logic can be blown apart. From motorcycles to helicopters, it all breaks just fine.

Destruction-hungry artists will find a detailed yet easy-to-follow example scene in the SideFX Content Library, the same visuals you might recognize from the keynote: sidefx.com/carbd-dual-car-collision/. A fitting go-through video can be found here:

Geometry, Viewport and other tasty QoL

Coming from its deep VFX roots, Houdini has taken quite a journey to establish its own distinct style of procedural modeling. With H21, that journey continues, extending existing nodes and adding a few genuinely useful new ones along the way. This time, even the viewport got some well-deserved love, now powered by Vulkan and capable of loading Gaussian Splats directly.

Sculpting in Time

The Sculpt SOP, introduced in H20.5 and (surprisingly) quite useful, now gets a genuinely groundbreaking new feature called Shot Sculpting allowing time-based, keyframe-free sculpting. Originally intended as a correction tool for character animation, the node turns out to be just as handy for VFX and motion design work.

Temporal control is handled through the Shot Sculpt panel, which at first glance looks a lot like an NLE timeline and, in principle, works much the same way. Sculpting can be organized into layers that can be offset in time, faded in and out (complete with easing), muted, or adjusted in opacity. Alternatively, you can use mask_track to paint time-based attributes, which can then be passed downstream and used in other nodes, for an obvious example, as masks.

Otherwise, the same rules apply as for the regular Sculpt SOP, whose updates we’ll take a look at next. In line with the new Shot Sculpting feature, the mask system has been reworked. Masks can still be painted manually, but can now also be loaded from an upstream float attribute, saved permanently, and blurred or sharpened as needed.

There are also new brushes. My personal highlight, the Elastic Grab brush:

Of course, the complexity and depth of ZBrush remain unmatched, but for many tasks, artists can now comfortably stay right inside Houdini.

Geometry Masks

There are also updates when it comes to masking. Several well-known nodes now include a Mask parameter, allowing the effect to be restricted to a painted or procedurally generated mask. Among them: Peak SOP, Soft Peak SOP, Inflate SOP, Flatten SOP, and Point Jitter SOP.

UV Flatten from Points

The latest addition to Houdini’s already powerful UV toolset could just as well be called “UV from Voronoi” since that’s exactly what it’s based on. The node distributes random or precisely placed points across the surface and uses them to calculate clean, non-overlapping UVs. It’s primarily designed for complex, high-resolution meshes, where traditional unwrapping tends to get messy fast.

Vulkan Viewport

Now enabled by default, the new Vulkan 3D viewport offers noticeably improved lighting, Ambient Occlusion, shading and ray tracing with built-in denoising, and a more accurate texture display though performance can take a hit if you push it too far. New worklights including a fully adjustable Dome Light, Physical Sky, and Three-Point Light setup now serve as the default viewport lighting.

Looking toward the future, the viewport can now display Gaussian Splats directly. Since splats are essentially just point clouds, and Houdini is fundamentally point-based, this opens up a rather promising combination. The .ply file can simply be loaded via a File SOP and passed into a Bake Splat SOP for further processing. From there, you can treat and manipulate the splats just like any other geometry using the usual SOP tools. More on rendering those Splats in the upcoming section on Solaris & Karma.

Curve Tools

The new Extract Contours SOP can generate object outlines from a camera’s perspective either directly as edges or as an edge group. Quite handy for toon-style effects.

The well-known Curve SOP now allows you to interactively split points into branches (with unique vertex numbers) or fuse them back together.

Unsubdivide

If things ever get a bit too much, this node can reconstruct a low-res input geometry based on Catmull-Clark.

Conclusion after some bottles of VFX

Even though the stated (and achieved) goal of H21 was mainly polishing existing systems and adding plenty of quality-of-life improvements, it still manages to sneak in a massive load of new features along the way. And we’ve only scratched the surface here. Deep dives on Copernicus, Solaris, Karma, Rigging, and Animation are already in the works.

What’s also refreshing is the ongoing effort to flatten the learning curve through better documentation, tons of in-house tutorials, and solid example files in the Content Library. Many things have become easier or let’s say, more accessible, without losing depth, at least for those who want to go there. As always, most nodes can still be cracked open and modified at their core. Nice one, SideFX.

The post Houdini 21: Like good wine (Part1, VFX & Geo) first appeared on DIGITAL PRODUCTION and was written by Manuel Kotulla.

Trimble has released SketchUp 2025, introducing real-time photorealistic materials that dynamically react to lighting conditions. These materials feature physically based reflectivity, transparency, and roughness, allowing users to preview real-world material behavior without requiring an external renderer. The update affects all SketchUp editions, including Desktop, Web, and iPad.

Environment Lighting with HDRI and EXR

Lighting simulation has also improved: SketchUp now supports 360-degree HDRI and EXR images as light sources. Instead of relying on generic ambient lighting, users can import high-dynamic-range images to simulate realistic environmental lighting, enhancing material realism. The feature is available across the SketchUp ecosystem, including LayOut.

Ambient Occlusion for More Depth

Another key addition is ambient occlusion, a shading technique that increases depth perception by simulating how light interacts with corners and edges. Even when no materials are applied, ambient occlusion improves model clarity, making it easier to interpret spatial relationships in architectural and industrial designs.

Expanded Interoperability and File Support

SketchUp 2025 further refines Revit and IFC file integration, allowing for more predictable IFC roundtrips and enhanced control over which Revit elements are imported. The update also improves USD and glTF export, now with support for photorealistic materials. This makes SketchUp more compatible with visualization pipelines that use real-time engines like Unreal Engine and Unity.

Updated 3D Warehouse and LayOut Workflow

3D Warehouse has been expanded with curated photoreal materials, environments, and configurable 3D assets, reducing the need to create assets from scratch. Meanwhile, LayOut’s UX has been updated to improve consistency with SketchUp’s interface, providing a smoother document creation experience.

Pricing and Availability

SketchUp 2025 is compatible with Windows 10+ and macOS 12.0+. It is available as a subscription-based service:

• SketchUp Go (browser + iPad) – $119/year
• SketchUp Pro (desktop + LayOut) – $349/year
• SketchUp Studio (full suite) – $749/year
• SketchUp Free (web-based, feature-limited) – Free

Final Thoughts

SketchUp 2025 delivers a noticeable leap in visual realism and interoperability. While it doesn’t replace dedicated render engines, the real-time material and lighting previews provide faster, more informed design decisions. As always, test these new features thoroughly before integrating them into your workflow.

The post SketchUp 2025: Better Visuals, Smoother Workflows first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

Rendering ambient occlusion (AO) and depth passes in Unreal Engine 5 has become more accessible, thanks to the detailed tutorials from Arghanion’s Puzzlebox.For post-production professionals and VFX artists, mastering these techniques is essential for creating realistic and dynamic scenes.Unreal Engine 5 offers robust tools for real-time graphics, but usability remains paramount in production pipelines.

Restoring Ambient Occlusion Control
In the tutorial titled “I RESTORED Ambient Occlusion Control in Unreal Engine 5!”, Arghanion demonstrates how to regain control over traditional ambient occlusion, a feature that has evolved in UE5. The process involves enabling traditional AO and effectively using AO maps within material shaders to achieve better artistic control.This approach allows artists to fine-tune shadow softness and intensity, enhancing the depth and realism of 3D scenes.

Rendering Clean Ambient Occlusion and Depth Passes
In the video “Unreal Engine 5 Rendering Mastery in 2025: What You Need to Know!” Arghanion provides a comprehensive guide on rendering clean ambient occlusion and depth passes. The tutorial covers setting up the Movie Render Queue for custom passes, creating post-process materials for AO and depth, and configuring console commands to ensure proper rendering. Additionally, it delves into using Level Sequences for render output and adjusting essential settings to achieve clean passes, crucial for compositors integrating CG into live-action footage.

Accessing the Tutorials
Arghanion’s Puzzlebox offers these tutorials for free on YouTube. For more in-depth tutorials and insights, visit Arghanion’s Puzzlebox YouTube channel.

*Note: Always verify the compatibility of new techniques with your existing pipeline to ensure seamless integration and maintain production stability.

The post Unreal Engine 5: Ambient Occlusion Returns first appeared on DIGITAL PRODUCTION and was written by Günter Hagedorn.

And who would have thought we would get the chance to talk to Kevin Meek, lead environment artist for Anthem, who was involved as the Character and Environment Director in the legendary edition. He is an alumnus if such varied title as “Mechwarrior Online”, “Transverse”, “Duke Nukem Forever” and now the “Mass Effect” Universe.

DP: To get a rough idea of the project: How many people were involved?
Kevin Meek: The “Mass Effect Legendary Edition” (MELE) was largely driven by BioWare Edmonton itself and here we have a fairly small, but quite senior group of people. Around a dozen developers, where everyone has at least 10 years experience. And the vast majority has already worked on the original trilogy. Then there was a handful of people like myself who came at it as fans and did not work on the original trilogy, but almost everyone has probably 20 years of experience working in games.

With a smaller size team, it almost feels like an indie team – just a whole bunch of people wearing a bunch of different hats. They’ve all been through the process before, so they know what they’re doing and just did get down to business really fast.

That being said, we also had a lot of external help – we were able to push some of the work to outsource studios and just find specific experts in certain fields. For example, Blind Squirrel (blindsquirrelentertainment.com) was a programming partner for us, because they have lots of experience with porting from other remasters and remakes – specifically with Unreal Engine 3, which we are using. They are very involved in the whole intricacies of taking something up onto DirectX 11 and getting it onto the next generation of consoles.

That’s a big amount of work for us regular developers of BioWare. We would be able to get our way through, but if you can find people who are experts in that field, we can bring them in and partner with them. Also, there’s a handful of experts in Unreal 3 from Europe called Abstraction (www.abstraction.games). They came onto the project for a couple of months and really added a lot. But everything went through the Edmonton Studio.

DP: With the “Mass Effect” trilogy being made in Unreal 3, did you have newer technologies from Anthem, for example, to add?
Kevin Meek: The last time we, as a company, used Unreal 3 – or Unreal at all – was with “Mass Effect 3”. At that point, “Dragon Age Inquisition” and then “Andromeda” and “Anthem” switched to Frostbyte. It’s almost ten years since any of us have touched Unreal … except for private projects.

DP: With 10 years since the assets have been active, did you switch to newer versions of your toolset, or did you use legacy versions on newer hardware?
Kevin Meek: Well, it’s a decade long trilogy, so the tools in ME1 weren’t even the same as in ME2 and ME3. Sometimes, in order to get a file to open, so we could export it into something current – for example a very specific version of ZBrush.

But we also didn’t want to dust off and maintain three different sets of tools with their respective underlying infrastructure and engine code, so one of the first things we did is unifying that. Generally speaking, that meant going up to the most recent version, so we went up to a more recent version of Unreal 3 – more recent than “Mass Effect 3”, actually. For ME1, that was a pretty substantial upgrade, for ME3 it’s a handful of newer tools and a few iterations.

For our underlying tools – like mesh exporters and so on – the latest version in which everything was working is 3ds Max 2018, so we just unified everything to that. There were even a handful of tools that required Max 2018, because we couldn’t get the old ones compiling.

For the rest of the pipeline, we used whatever the original developers used. We opened up the assets, and then there were mesh files, and ZBrush files, and Mudbox files and Photoshop files … the development ran from 2006-ish through to 2015. That’s quite a lot of time in the games industry for a lot of tools and different pipelines. And on top of that, people were still figuring out how to use certain technologies – how to make and incorporate normal maps and high-poly /low-poly baking, for example.

DP: Do you have any tips for getting older stuff to work again?
Kevin Meek: Yes, anytime anything was documented at all was such a lifesaver – if you ever work on something that has even the slightest chance of being remade, save copies of the installation files for the programs you use. Especially near the end of a project, get everyone to work clean in the organisation of assets. It is sadly quite common to modify the texture directly, and not go back into the Photoshop file. This might get the game done, but it makes the work for the remaster or remake a LOT harder, when you have to become a archaeologist, and scroll through final_2_2.xyz.

DP: And how about technologies that weren’t possible when the games came out?
Kevin Meek: There are definitely effects, that you expect from the current generation of games. You expect some ambient occlusion, some sort of (at least faked) subsurface scattering, volumetrics …
Especially volumetrics, which came in the latest version of Unreal 3. It adds so much life and depth to a scene. We found that in ME1 and even in ME2, there was not a lot of movement and dynamic attributes to the levels. And that was largely technical constraints. Either the stuff hadn’t been invented yet, or the things were very expensive in terms of performance. Translucency and sorting and having half your screen filled up with transparent pixels. That’s still expensive, mind you – you can really catch yourself out with particle effects creating overdraw issues.

In MELE, we couldn’t go crazy, but consoles are ten times more powerful, and we have all this understanding what we want games to look like. And we could add that sense of life and dynamic. And since we brought all three parts onto one level, we could add certain types of tech into ME1 and 2.

There are other tools we had to write by hand – like our version of the ambient is custom. And the wrap lighting or the custom depth of filed is either custom, or ported back by hand from how you do it in modern day. Thankfully, with Unreal 3, there is troves of knowledge online on how to fake things like subsurface scattering these days – we took from well documented graphics bibles and user cases and tutorials. That’s one of the really big perks of working in Unreal – you just have to google it, and there’s the answer, sometimes in 10 different ways.

DP: When we look at the textures: How did you upscale all of those, and what tools did you use?
Kevin Meek: We used a number of things – we knew going in, that current AI-tools would be only level 1 for us. So, we did that as the first step – before anyone touched anything, we got that done. Myself and one programmer analysed a bunch of AI upscaling methods (Upres), and I was a bit of a sceptic before those tests. It’s like that meme “Zoom and Enhance”.

We did a lot of tests with textures, UI and FX, all the way to environment and character art. We had internal tools, and we had some out-of-the-box solutions. I was impressed with the results, but you have to test a lot and pick and choose, specifically for games.

We exported (and reimported) large batches of Targa files straight from the game files, so any last-minute changes were available – like I said, when you are close to finish, artists don’t always use the source-PSD-files, but work in engine.

Basically, we got everything from the game, and on that we ran the AI upres. At this point we had to pay close attention to the file-types, like normal maps and stacked textures. Every texture is a red-green-blue and sometimes an alpha channel. They usually don’t know about each other. So, if you upres, you suddenly get a lot of bleeding – because in the resolution change, they are not ignorant of each other, and they are suddenly mathematically incorrect.

Same thing with the stacked textures – basically a bunch of masks, for a character’s armour for example, where the different versions are just in some free channel in the texture. We had information about how shiny the armour is in the red channel and in the green channel you have the information which colours can go were. Or vice versa.

And if you process that, you get a lot of garbage – so we had to split those out into four different textures. Now we have four PNGs and then we upres those, and recombine them into a colour map and convert it back to Targa. There’s a little bit of a stepping processes.

With that approach, we ended up well north of 30,000 textures for the characters alone. But that worked really well, and bumped up the picture quality of the game. And we only upscaled one step in the source art – so from a 128-texture up to a 256-texture. Or a 1,024 to a 2,048.

DP: What was your pipeline for that heap of assets?
Kevin Meek: We had a really good tools programmer – and we tracked everything. The batch tool put the texture somewhere, split it apart, and create an Excel sheet of tens of thousands of lines, with “here’s the texture name, here is its new name (times four), here is what type of texture it used to be, and where does it go now”. And as long as you keep that Excel sheet saved, then all the tools can reference from that.

And we’d update the tools as we find things going wrong, and then you’d end up having to run the whole process again. A number of times we just reverted everything back to that “Safe Revision 01”. We babysat the AI upres and we only ran a few thousand threw it at once, just in case it crashed or anything went wrong. Largely it was just like a bank of computers working on that, as we slept or went home for the weekend.

DP: And, on the creative side, where is the tipping point where you need an artist?
Kevin Meek: Well, coming from the AI upres, we basically had the game up and running, and then the artists started coming in – and they used their trained eyes. Let’s take for example environment art: I would assign an artist to a level and they would own that level, play through it a number of times and create a list of assets they critiqued as not good enough. Those assets got ranked by priority, based on how bad it was versus how often is it used, or if it is a hero-piece, and then you just hit through your list of ugliest assets. When you play through the level again, the standard is raised – and you walk through that cycle a couple of times, and it is getting good.

But with iteratively getting the things better until the point where nothing catches your eye as bad, you still have to remember: A remaster is very art-focussed, but at the end of the day, “Mass Effect” is a story-driven game, with the characters and their interactions in the foreground – and therefore, our job as artists was to make sure that you are never distracted by the art in a negative way.

The AI upres gives us a great base to work off of, but it doesn’t make bad art good. If something is noisy or boring or shifted, you just have to recreate that texture. And then there is everything else we layered on top. AI upres is fine, but it isn’t doing anything to the meshes or the shaders or to the lighting. All of this stuff, the big-brush coating of the levels, which makes it feel more like a current generation game, has to be done by hand. There is no AI solution for relighting the level. Maybe one day there will be …

DP: Aside from the textures, did you re-do the riggs or the animations for finer details?
Kevin Meek: (laughs) Our animation pipeline did not do well after 15 years. Often it was just Perforce sitting there in the server, getting server dust on it. So, we found that often, if we would redo an animation and reimport it into the game, that took a long time just to get going in the first place. And then secondly, there were a lot of ripple effects of bugs that came from basically touching the system at all. That could be anything from underlying Unreal issues, where we’ve upgraded the version from whatever version it shipped on to the current version. Also, there were some mathematical changes, which happened a lot with lighting. Some piece of averaging, how light affects a character, changed, and now the system reacts differently. These might be little things that you don’t even pick up until you worked some time with it.

With the animation, we couldn’t really do anything about that, without devoting a huge amount of time into it and setting up the system again. What we ended up doing was change how the underlying system works with the animation – like animation trees. In a video game, you don’t animate every single thing the character could possibly do – you animate independently and blend the actions together through an animation tree – turn left, look up, aim at, these are animations that are blended, and there were a lot of issues in the tree for how things can blend together. That ended with a lot of cross-eyed moments – which was almost funny – especially when Shepard and the team go to cover, and you see their faces, and they would pull a gun and their eyes would roll up in their head. That kind of stuff, we were able to change and clean up.

The riggs stayed the same, but we had to reskin every single armour and piece of clothing we touched, because we upressed the meshes themselves. There are more poly­gons for smother shoulders and the details, that might just have been texture before, are now polygons and cut-outs and extrusions which catch the light. So, our tech-department reskinned the verts to the skeleton. These new polygons need to be connected to the bones to move with them.

DP: With your background in environment art: How did you treat the planets, some of whom were quite barren in ME1?
Kevin Meek: For the uncharted worlds, they were the most barren. They are all Unreal-terrain-based and not a static mesh. That gives you a few semi-procedural options, but still works well within the tools that existed in Unreal 3.

What we would do is like a scatter mesh system, instead of just green texture on the ground. Now we have green texture on the ground, which is upressed and looks better and has a better material to it. And finally, it is actually projected on the ground instead of UV stretched everywhere. But also, on top of that, there is an actual mesh on top, like of blades of grass or rocks.

That’s basically a system you tell “on this type of texture, given this angle allowance, how dense do you want these rocks to be”. Every time you load the level, it is different. But nothing so large it needs collision, so trees we would stay away from. That would have created a whole swarm of ripple effects, because you would be stuck on the tree, but it is not always there, because it is generated. So, we kept everything level enough that you can walk around without collision.

The mesh of the terrain we upressed, and the materials we used are now triplanar shaders on the terrain. In the original, it was just top-down-projection. A polygon on a cliff would have the UV stretched all the way down the cliff, because it doesn’t know about angles. But with a triplanar projection shader, it actually shoots the texture from X, Y and Z and then it blends those intersection points. So now your cliff actually looks like a cliff instead of melting rock. That’s not new tech, but it is much more expensive, and they obviously couldn’t have afforded that back in the day. But it makes a world of difference when you’re driving around those levels.

DP: When you remastered all three parts: Did you use assets from ME3 in ME1, since they were already better quality?
Kevin Meek: Yeah, actually there were a lot of assets that are shared between the entire trilogy, so as they finished work on “Mass Effect 1”, “Mass Effect 2” would start and they have the library of assets to start from and a number of those made it through all the way up into “Mass Effect 3”.

Certain ones got improved in Mass Effect 3 and we were able to use those as a starting point. Especially with characters and also placeable props. Your job as an artist would be to ask: “Does this exist in ‘Mass Effect 3’? And does it look better in one of the other games?” It was baked into every single character armour and faces with the morph head system and wrinkle maps and all of your character customization options and more. But all came from whatever the best version was, which is generally ME3, but not always. Then we improve that and then brought it across the trilogy. But crates were unchanged. Some of the crates, which are so prevalent in a cover shooter, were the exact same crates that existed in “Mass Effect 1”, and it was kind of rough, but it was the exact same asset in ME3.

DP: What are you telling your colleagues working in upcoming games, now that you finished the remastering of a decade–long project?
Kevin Meek: I think for any game that we’re working on, it is good to have naming conventions and documentation – and get the artists to understand the best practice for that. The original Devs of the “Mass Effect” trilogy did a really good job with those. We can go back into the original Perforce and search files.
On the other hand, there is no documentation whatsoever of how to rebuild lighting in the levels, which is like a baked static lighting. But what layers do you show? And in what order? All because there’s just not a single page somewhere in some internal wiki that says: okay, here’s how to do it, guys.

It was all tribal knowledge, so that’s the main thing: Always assume that you are off the project in a week and that your tribal knowledge is going to be lost with you. I think, if you take that approach to everything and just over-save and over-document, then you’ll be in an okay state 15 years later, when someone says you’re amazing game is worth remastering.

The post Legendary Scaling – Mass Effect Returns first appeared on DIGITAL PRODUCTION and was written by Bela Beier.