Octane Basics
Texture Set / SBSAR Workflow
Version 2.0, Updated January 2023 using Octane 2023.1.2 and C4D 2024.2
Texture Set / SBSAR Workflow
Version 2.0, Updated January 2023 using Octane 2023.1.2 and C4D 2024.2
About This Guide
This guide looks at best practices for getting texture sets generated by apps like Substance or Quixel into Octane for Cinema 4D as quickly and efficiently as possible.
Part I goes over what Texture Sets are and kind of how they came about.
Part II talks about C4D and Octane integration and size/format/color space considerations.
Part III has two process walkthroughs - one for a downloaded texture set, and one for an SBSAR.
What Changed from 1.0
Complete rewrite. Using the C4D Substance Shader is no longer recommended because of instability and the lack of ability to use proper color spaces for the maps and other niceties that the ImageTexture node affords. Automatic PBR map detection is now a huge timesaver, so importing maps isn’t nearly as fussy as it was when 1.0 of this guide was written.
PDF
This guide is also available in PDF format here.
Downloads
We’re going to be using assets from Poly Haven and ambientcg, both of which provides an excellent set of textures, HDRIs, and other goodies under the Creative Commons CC0 license (completely free for all usage).
Part I: What is a Texture Set?
In the Beginning
Back in the day, some smart people figured out that materials could be broken down into properties (How shiny is it? What color is it? Can we see through it?). As 3D render engines were being built, their material systems defined these properties and set value scales to them. Everyone had a different idea of how big the scale was, what the names of the knobs and switches were and how many were needed to control each property, what the values actually meant, and how their engines translated them. As we can imagine, since this process grew organically and in silos, it was a nightmare to go from engine to engine and relearn all the rules.
Physically-Based Rendering (PBR) was a term that started gaining traction as engines and the hardware and software to run them got better and we could start doing a better job of simulating reality and not take so many shortcuts. This concept meant that light interacted with materials the way it would in reality, and - surprise, surprise - renders started getting more realistic. Now that we had “The Physical World” as a target, we could start to at least (mostly) agree on the names of material properties and how they were implemented.
Channels and Materials
Modern material systems in render engines bundled all these properties into layers commonly referred to as channels. Most engines nowadays have adopted a mostly standard set of channels for their materials.
Typically there’s something that defines the overall color (albedo/color/diffuse), some sort of reflection (specular/metallic), transmission or emission (light can pass through it or it can emit its own light), surface detailing like bump, normal, displacement, helper properties like IOR and roughness that further influence some of the base properties, and then special effects and coatings.
Each property is controlled by one or more channels, and the channels all combine in a particular way to make a material. The Universal Materials Channels Deep Dive guide shows what all of these properties do in Octane using the Universal Material.
The properties in these channels can by controlled in a few different ways. The simplest way is to assign a single value to each one - so roughness can be 50%, specular can be 90%, albedo can be #FFCC00, etc. This worked great for creating uniform surfaces in a particular engine, but not so great for porting materials from one engine to another, or for making nonuniform surfaces.
To solve both of those issues, we needed to turn to an old standby - texture mapping!
Texture Mapping
The concept of using standard images like PNGs, JPGs, and TIFFs as textures to drive properties rather than single values has been around almost as long as 3D graphics have. Originally, the idea was to take a 2D photo or illustration and map it over the surface of a 3D model in a process called texture mapping. This only affected what we’d call the Color/Diffuse/Albedo channel today. This was a big step up from trying to color each individual polygon, but it still wasn’t super realistic.
Eventually this concept expanded to several other types of non-color properties like bump, metallic, and roughness that controlled material properties across the surface of the geometry and allowed for more nonuniform, realistic looking surfaces.
The biggest advantage is that most of the engines out there already were able to read and incorporate images into at least some of their channels, so retrofitting the rest of the channels to accept images wouldn’t really be a heavy lift. Now one set of images could be produced that could easily be ported from engine to engine.
Scale was still a problem from engine to engine, but a clever 0-1 system was developed to help with this. Grayscale images were repurposed to use the grays as percentage values instead of color data. If a pixel was black, that meant the value was zero (no roughness or specular or whatever). If it was white, that meant it was 100% (maximum roughness, specular, or whatever). Anything in between mapped to a particular percentage. By using a 0-1 scale with a decimal point, we could get very granular detail in our percentages like 0.15237, or 10.5237%. Now that this min/max system was standardized, it was up to the engine to determine what its minimum (0) and maximum (1) values meant for each channel, and render accordingly.
As time went on, other channels were introduced that used all of the rest of the color data as values. We ended up with Normal and Vector Displacement maps that use Red 0-1, Green 0-1, and Blue 0-1 to determine the direction that light is bounced (or polygons are pushed), making for more variety and realism in those channels.
Today, we have a fairly standard-ish set of texture maps that any engine can use. There are still some naming quirks we have to be aware of, and sometimes we need to invert part or all of a texture to make it work in Octane, but we should be able to adapt nearly any set out there to get a good looking material.
The Catch
There had to be a catch, right? The biggest issue is that these texture maps eat resources. It’s not really that big a deal with a few materials with a few maps, but once 10-20 materials are used, each with 8-10 high resolution, high bit-depth texture maps, it starts to take up a significant portion of our already limited VRAM during the render. There’s a whole guide series dedicated to this.
Part II - Cinema 4D and Octane Integration
Color Space Considerations
Texture maps are usually exported in either in the sRGB or non-color data color space. We’re not going to go into detail about this here because it’s a giant rathole that has its own guides.
General rule of thumb: Color data (anything meant to look like the image map itself or take color values from it like Albedo or Transmission) should probably be sRGB unless we know it’s in a different color space.
Non-color data (anything where the gray or color values are meant to drive raw data like roughness percentage or normal direction) should be set to Non-color data unless we know it’s in a particular color space for some reason.
File Format and Sizes
Important: The one thing to know about Octane as of this writing (2023.1) is that the file type does not affect the amount of VRAM used. It affects the amount of hard drive space the file takes up, but a 16-bit 4k PNG uses the same amount of VRAM as a 16-bit 4K EXR, regardless of compression. More on that here.
JPG: Only use these for diffuse/color/albedo maps, and only if hard drive space is at a premium
PNG: Go-to for most maps. 8-bit is fine for color data, 16-bit is usually fine for non-color channels like bump/normal/specular/etc.
EXR: Generally only need this for 32-bit displacement maps where 16-bit still produces crunchy edges.
256px -1K: good for materials that either go on small (relative to the scene) objects like screwheads and the like, or as a small pattern with no variation that gets repeated a lot on an object like checks or polka dots.
2K: Good for general use if the camera doesn’t get too close and/or the output size isn’t too large (standard monitors/phones).
4K-8K: Good for closeups, large formats (print pieces or high res footage meant for large screens), and high detail displacement maps. 4K-8K textures can consume a LOT of VRAM and cause scenes to load slower, so we need to carefully consider whether we absolutely need them or not.
Octane Materials
Like most render engines, Octane has had the ability to use texture maps from the start. The Universal Material was designed to make texture sets easier to work with, and then recently the Autodesk Standard Surface Material was added so we now have two choices for our material node. In this guide we’re just going to talk about the Universal Material, but the workflows should be similar for Standard Surface.
There are a lot of channels here, but most sets only include maps for Albedo, Metallic, Roughness, Height, and Normal. Specular is sometimes included, but often just a single value, so it’s best to set that in the float instead.
Importing Textures
When importing images, we have a few options. The best, most versatile, and most portable way to do this is to put each texture into an ImageTexture node and then hook them up to the appropriate channel inputs in the Universal Material or Standard Surface Material.
The worst way to do it is to use Cinema 4D’s native bitmap shader. This shader doesn’t easily allow for manipulation of size/tiling/color spaces the way the native Octane one does.
There’s also an option to use an SBSAR directly. This is done by having Cinema import the SBSAR and generate a standard material, and then using Octane’s material converter to convert it to an Octane material. It makes a mess with material layers and such, but it does give us access to the Substance Shader. While this shader does allow us to alter the SBSAR properties and audition different looks, it has many of the same issues the C4D bitmap shader does. This node has also caused lots of stability problems in the past, so it’s best to just avoid it.
Texture Set Automation
As of Octane 2023, if we have a set of texture maps that’s appropriately named, we can just select any of the texture files in Windows Explorer and dump them on a material in the Node Editor and Octane will import each map into an ImageTexture node, set the color space (mostly) correctly, and hook them up to the (mostly) appropriate inputs. This massively speeds up the process from earlier versions of Octane where we had to know which map went where and manually set the color space for each one.
Part III: Workflows
Poly Haven Texture Set
We’re going to start with a very simple texture set - Slate Driveway by Poly Haven. Poly Haven is a fantastic resource - it’s a Patreon-driven asset library that creates CC0 texture sets, HDRIs, and models and releases them out to the world for free. It’s pretty Blender-forward, but we can still use the sets and HDRIs by setting a few options.
When we first hit a Polygon texture page, we’ll see a purple bar in the upper right corner with a 4K dropdown and a Blender logo dropdown to the right of it. If we were to hit download, we’d get a zip file with a .blend file and a textures folder. We could use the textures folder in this, but the default file formats may not be to our liking. Fortunately we can customize the download package by hitting the Blender icon and choosing ZIP from the menu instead. This opens up a panel that lets us pick and choose which maps we want in which format.
Which format and which resolution depends heavily on the intended use of the material. We’re going to go all PNG for this one, but if we were going to use displacement, an EXR height map would be recommended. Let’s un-purple BLEND and GLTF (not going to use either of those), then purple PNG for Diffuse, Displacement (we’ll use this in bump instead), Normal GL (not DX), and Rough. We don’t need AO, or AO/Rough/Metal (which is also known as ARM - Octane doesn’t support that at this time).
2K is good for now, so let’s change 4K to 2K, and then hit Download to get the archive.
Next we’ll want to make a new C4D file, make sure it’s saved somewhere with a /tex folder next to it, and call it something like driveway.c4d. Now let’s make a new Universal Material, name it Slate Driveway, double-click it, and hit the Node Editor button to open the node editor.
The archive we got from Poly Haven gets unzipped to the /tex folder in the same location as our C4D file. It can be in a subfolder to keep the structure tidy (so /tex/slate_driveway/ for example).
If we were to try the automatic PBR detection function in Octane now, only the roughness map would work. Unfortunately, Poly Haven doesn’t write out the entire map name in their materials, and Octane doesn’t understand the abbreviations, so we’ll have to rename the files to contain the full channel name.
diff>diffuse
disp>displacement
nor>normal
rough>roughness
NOW if we drag any of the four maps from Windows Explorer on to the Universal Material node, they’ll all appear inside ImageTexture nodes and hook up to the proper channels so long as they’re all in the same folder.
The utility maps will already be in the right color space (Linear sRGB + legacy gamma, gamma =1). The non-color data option would probably be a better choice just from a “oh, that makes sense” perspective, but Linear sRGB & gamma=1 also works since they’re functionally the same thing.
The diffuse map (hooked up to Albedo) comes in with the wrong color space, though. Linear sRGB + legacy gamma, gamma = 2.2 is close to, but not exactly the same as sRGB, which is the proper color space for this map. 99% of the time this won’t be a dealbreaker, but it does shift the colors a little, so it’s a good idea to set this dropdown to sRGB instead (legacy gamma no longer applies if sRGB is chosen).
For more information about color spaces, check out this guide.
We’re not going to use displacement with this material, because it’s a much more advanced topic that requires lots of things to go exactly right. This guide is the first in a series that explains this in a lot more detail.
The displacement map in this case is the same as a height map, which is what’s also used in the bump channel, so let’s delete the displacement node and run the displacement map into the bump channel.
The last thing we need to do here is kill the specular - there’s no map for it, which probably means this material isn’t meant to be reflective. Looking at the preview on Poly Haven’s site confirms this. The Universal Material defaults to 1 (full specular), so we just want to bring that to 0 (no specular).
If we put this on a cube and throw in an HDRI to light it, we’ll see it looks pretty close to the preview on Poly Haven. Nice :)
Optimizing
At this point, it’s a good idea to take stock of the maps and see what we really need. If we hook and unhook each one, we can see the effect it has on the material - if it turns out that bump or roughness doesn’t add a whole lot, we can just delete them and save some VRAM. In this case there are four 2K maps which are only taking up ~350MB, so we’re probably fine to leave them all.
Some texture sets also have maps that are entirely black or white (channel is off or on). Rather than eat up VRAM with these, we can just use the float slider in the channel to turn the channel off (0) or fully on (1).
SBSAR (Substance Material) Workflow
Substance Player is a free tool (no account or login needed) that allows us to load SBSAR files, see what they look like on a model, adjust settings, and export maps in various resolutions and file sizes.
In this example, we’re going to use the Facade Substance 004 SBSAR from ambientcg.com (free, no account).This is a good starter material with a few different maps.
Once Substance is downloaded, installed, and set to use whatever engine we’re going to use (probably DirectX on Windows), we can use it to open the Facade Substance in it.
There are only a few things that need doing here. At the top, along the 2D view, there’s a list of the texture maps used in the SBSAR. We can look through them and see what each one does. On the right, there’s the Output Size. This is where we choose how large the texture maps will be when exported. Under that, there are all the exposed parameters we can mess around with if we want to customize the material. Finally at the top, there’s an Export to Bitmap button.
When we hit this button (after choosing the Output Size in the main UI), we’ll see a list of the texture maps (Substance calls them ‘outputs’) on the left that we can turn on or off depending on our needs. In the upper right corner, there’s a Format dropdown - this we’ll need to set to either PNG or EXR, depending on what we’re going to do with the maps. We’re going to use PNG in this example. The Pattern system allows us to customize the naming of the files. Default is fine - the full name of the channel is already there (%O), so no action needed.
Important - Substance doesn’t allow for per-map file format selection, so we’ll have to export twice if we want, say, all our maps except height to be PNG, and height to be EXR.
Once we’ve put in a path where we want the files saved, we can hit Export and Substance Player will generate all the requested texture map files. Great.
When we grab any one of these maps and dump them on a new Universal Material, Octane will recognize BaseColor (same as Color/Diffuse/Albedo), Normal, Roughness, Metallic, and Height and hook them up. It will ignore Emission and Ambient Occlusion - we’ll have to do these manually.
The BaseColor map’s color space should be sRGB, so let’s change that, and then detach Height from Displacement, delete the Displacement node, and run the Height map into the Bump channel instead.
If we look closely at the Normal map and compare it to the Base Color map, we’ll see that green is on portions that go “down” and purple is on portions that go “up”. This means it’s a DX-type normal map. GL-type normal maps have the green channel reversed, so red and blue are the same, but green should be “up” and purple should be “down”.
Both maps are legit, it’s just a matter of whether the app supports one or the other (or both). Substance caters to video game engines, many of which use DX-type maps, while Octane uses GL-type normal maps which is more common in 3D creation tools. Unless the designer of the SBSAR chose to include a GL-type map (this one doesn’t), we’ll have to fix this. Fortunately, Octane has a Channel Inverter node that we can use to do just that. If we run our Normal Map through a Channel Inverter and set the Channel Inverter to invert the green channel, it will effectively convert the DX map into a GL one and the material will look as intended.
We’ll have to drop in the AO and Emission maps separately since Octane ignores maps it can’t use with Automatic Detection.
Ambient Occlusion (AO) is a utility node, so the color space should ideally be non-color data. If we want the effect stronger, we can use a Color Correction node and adjust the contrast or gamma, or a second Multiply node and multiply the AO by itself before combining it with the Base Color texture. AO is fake shading, so most of the time we won’t need this, but if the model is far away, sometimes this will help sell the effect without having to resort to Displacement.
Emission uses color data (yellow should appear yellow, blue should appear blue, eta), so its color space is sRGB. This gets piped into a Texture Emission node, which starts out super bright. We can fix this by turning on Surface Brightness and lowering the Power to something like 1 or 1.5. The map will now drive the color of the lights, but the power and other settings in the Texture Emission node will control intensity and other properties of the emission. There’s a whole Lighting and Emission guide that might help with this.
Each Substance is unique in its makeup, and will use all manner of maps. Automatic Detection is a nice timesaver, but we’ll likely have to tweak each material as we build it and make some decisions along the way to get the look we want.
Author Notes
Version 2.0, Updated Jan 2024 using Octane 2023.1.2 and C4D 2024.2
This guide originally appeared on https://be.net/scottbenson and https://help.otoy.com/hc/en-us/articles/212549326-OctaneRender-for-CINEMA-4D-Cheatsheet
All rights reserved.
The written guide may be distributed freely and can be used for personal or professional training, but not modified or sold. The assets distributed with in this guide are either generated specifically for this guide and released as cc0, or sourced from cc0 sites, so they may be used for any reason, personal or commercial.
