Post

I am at the Everything Procedural Conference in Breda for the next 2 days! It’s held in a beautiful space, an old monastery. There’s a giant red lit organ in the back as well, so I hope it’s used for one of the talks. Do you think it accepts midi?

Packed crowd! I’ve already learned that apparently a new AA game studio called Grid Games was started in Weesp, with about 50-60 people working on-site. And they’re hiring! I’m glad to know the Netherlands is still getting more studios, especially in today’s times.

First talk: Erik, from Embark, talking about procedural character pipelines for ARC Raiders and The Finals.

“Delay as many options as possible, until they are needed.” (a sentiment I really like as well.) It is very easy to overengineer. Make sure your users can move from DCC to game, and then resolve issues as they come up. So you solve what is actually necessary.

USD mentioned!! They’re using Houdini Solaris as the base, and any other DCCs as necessary, with openUSD as the source of truth.

They start off with very few nodes in Houdini, to make it easy for artists to get started in. And then graphs become more and more complex over time, if artists want or need to do so, with live linking.

With Houdini and USD they often get live linking for free. He shows an example with zbrush and Houdini. This makes the workflows feel much nicer, and faster.

So why Solaris? Because it allows for a better user experience that is less technical to understand. Visual scene graphs, for example. It then also allows for visual debugging, which is also easier to use.

Then using openUSD as the source of truth, with its layering systems, allowing composition arcs (e.g. references), so you can quickly isolate a single assets in a character, such as a bag, a hat, and then edit that on its own or providing overrides. So the same hat can be used in multiple ways.

So don’t repeat work if you can: Make sure refinement doesn’t require reauthoring (eg. Changing hat lattice for one skin) Providing overrides through nodes and caches, so folks can easily reuse assets. Provide a shared space for tech and art to intertwine.

And this also then allows for batch changes. An example of The Finals, where they wanted to add new body types a few seasons after release. So all old items had to work on these new body types. They could easily do this, due to their procedural pipeline. It actually improved the old items.

And because they delay all their decision making until the final point, they can then make changes right before the content hits unreal, such as changing material presets for higher resolution textures. So their asset source of truth is actually outside of Unreal, rather than inside Unreal! Neat!

The next talk is by Tim from Vertigo Games, about VR games and PCG in Unreal. It’s moving a bit too fast for me to live post it, but I appreciate this slide of generated as well as manually placed camera visibility points for automatic triangle culling. (Memories of visgroup calculation in Hammer)

They are very happy with PCG because it’s built into Unreal, so all other systems easily work with it, and you have access to the source code which allows them to make any changes they need.

Then you use blueprint actors to place things like vegetation. But it can also be used for level geometry! So they started doing all level design and art with PCG, and then finish with manual set dressing.

And they’re happy that PCG auto-regenerates when a manual asset is placed. E.g. a rock is placed, and then grass automatically appears around it. Though they are able to interrupt this, so that when they place a skeleton (with specific tags on it to ID it), it does not grow grass around it.

But then they have to convert all these instances to actors 😱 Apparently this is due to HLOD generation reasons, and he says he knows this sounds nuts. (To be honest I don’t understand this too much. Maybe @joewintergreen.com has thoughts on this?)