Author Topic: Does Substance make sense for props within low end game projects?  (Read 1261 times)

From what I understand, even the big studios like NaughtyDog really only use substance for tiling textures. I see many people using substance for props but it's usually for portfolio purposes.

Imagine a prop such as a clock, say it had wood, metal, plastic and diamonds. You'd need 4 substance designer materials but each of those would have albedo, metal, gloss, AO, ID map, Normal etc. So this one prop would have 25 texture maps. So I'm guessing this isn't really feasible for games (especially on my intended platform of mobile) or is it? Perhaps for the long run you end up with less maps because those 5 maps for wood are used all over the project?

Does anyone here have experience of how they go about texturing props in Substance Painter for a game project? I'm guessing I missing something technical here, like there is no need to export any maps because the engine reads substances which are much lower in filesize?

While a clock would reference all those materials within Substance software, all the practical pipeline processes would merge those maps into one set, a 'clock' material, in a sense, or three or four 'clock' maps.

Tiling textures is just the first part of texture creation, in my opinion. The real power comes from filters that alter the substance using mesh-data. Baked maps of the mesh can tell a graph what areas are exposed to damage, or where dirt-collecting crevices might be. In the end, your clock might have damaged, un-varnished corners in the wood, patina or rust in the grooves of the metal, and slightly scratched, less glossy plastic in areas that have flat surfaces.

I like to use exported maps in my workflow, although many engines can read SBSAR files, now, too. So I'll export these combined and filtered materials as Clock_BaseColor, Clock_Normal, and Clock_MetallicGlossiness and move them all into Unity. In Unity Gloss is stored in Metal's Alpha channel, and I only really find AO necessary if I'm aiming for photorealism, so baking it into BaseColor makes sense for me. No ID is necessary because all materials are combined.

The same sort of thing is true if you use SBSARs in-engine. The engine will bake out composite maps before rendering, anyway, it just does it before runtime or as the code demands (for dynamic textures)

Great information Cory. I also posted this question on polycount and between these two forums I understand it now. The problem I had before was thinking you would be exporting maps for the tiling wood, tiling metal etc that you 'paint' onto the clock asset. When really, SP combines as many substance materials as you desire into one texture map for the required slots (In my case albedo, metal and normal). So it's just 3 maps for one asset which is of course manageable.

So in my project I'll be exporting these maps, potentially using the SBSARS for dynamic textures (mostly tiling textures I imagine).

Well that's a problem I had when I first started using substance.

"Imagine a prop such as a clock, say it had wood, metal, plastic and diamonds. You'd need 4 substance designer materials but each of those would have albedo, metal, gloss, AO, ID map, Normal etc. So this one prop would have 25 texture maps"

Actually, I have a trick for this. You don't need high-res gloss/roughness spec/metallic maps for absolutely everything, especially smaller parts of an object. Sometimes, I just create 8x8 pixel greyscale maps for roughness and metallicness just to make a substance more or less shiny. These maps take literally no disk space and have no performance impact. Of course, for bigger objects, you may want to use roughness to create a grunge effect, then the texture resolution has to be at least 1k, ideally 2K (the bigger and the most obvious the object is, the higher the resolution should be).

But remember, if you just use plain color/greyscale maps in a channel, reduce their size as much as you can. Since they are plain, it won't make a difference and you'll gain quite a lot of performance. And don't hesitate to use 512x512 (or even 256x256) maps for small and less noticeable areas of a model.

Thanks for sharing your thoughts Coweb, I'm already trying to get into the habit of lowering sizes for nodes where it doesn't make much of a different. I posted a question about this actually, if you wouldn't mind could you take a look. I'm trying to figure out if it's possible to reduce the size of instance nodes...

https://forum.allegorithmic.com/index.php?topic=19468.new#new