isotropix.com

I'm trying to get one short list that captures everything needed for textures, whether megascans, self scanned, texturehaven, from substance painter, or any pbr textures used in Clarisse.

I've seen a few posts here but there are only a handful of textures: (1) diffuse/albedo, (2) normal (3) displacement (4) roughness (5) AO
How complicated is it to have one short text listing what to do with each in Clarisse? Why does everyone new to Clarisse have to go hunting for these bits and pieces?
something that looks like this, but captures all what needs to be addressed:

(1) diffuse
File colour space: Utility-sRGB-Texture
...

(2) normal
use raw data?
Single chennel file behaviour:?
...

(3) displacement
this is a greyscale texture. Single chennel file behaviour: force luminance
File colour space: Utility-Linear-sRGB
...

(4) roughness
this is a greyscale texture. Single channel file behaviour: force luminance
File colour space: Utility-Linear-sRGB
...

(5) AO
this is a greyscale texture. Single channel file behaviour: force luminance
File colour space: Utility-Linear-sRGB
...

Do you think this is possible?
This isn't some documentation exercise that I'm going through, this is a painful render that doesn't look anything like the pbr textures imported.

Hello Karen,

The issue is not related to Clarisse and will be the same in any other 3D DCC and renderers. The solution is to modify the ACES config file, remove what you don't need and use this edited config file (keep the original as backup) and you may/should be able to have a list of only the color transforms you need, which I agree, saves a bit of time.

That said, to improve the ACES OCIO workflow in Clarisse, have a look at this (image attached). Top menu > Image > Edit File format...


Best

I'd like to mention the Yanik's CSK: https://github.com/aydinyanik/clarisse_survival_kit

Clarisse Survival Kit is a set of Python functions for Clarisse to automate repetitive processes such as importing generic textures, Megascans assets and mixing materials.

If you have any specific requirements, you can contact Yanik on the Clarisse Discord server (link in my signature) or directly on his website/social pages.

Best

Thank you, but all textures from megascans and most other texture websites are jpegs. it's not about the file extension.

Hi,

As all functions in Clarisse menus are python scripts you can edit the import_texture_map_file.py and add a snippet that detects string parts like albedo, roughness etc etc ... and apply some commands when such strings are detected. Like setting a Color Space, setting the Single Channel File Behavior etc ...

Cheers

Hello Karen,

The file extension does matter. For instance, and especially with ACEScg, a Megascans albedo (base color) JPG file will be set to "Utility - Texture - sRGB" while if it was an EXR, it would have been "Utility - Linear - sRGB" since JPG are 8bit files and EXR can go up to 32bit (half or full) floating points. Although color textures usually represent 1/4 of all your texture map files as most of the others are data/scalar maps that need to be linearized (set to "RAW"). Besides that, you are correct, the type of file (color or data/scalar) makes the difference between different maps that have the same file format.

Quixel Bridge comes with a plugin ("LiveLink") for Clarisse https://help.quixel.com/hc/en-us/articles/360002409078-Installing-the-Megascans-Plugin-for-Clarisse, although it hasn't been updated lately, at least not yet. Otherwise, I'll point you again on the Yanik's CSK that has a texture-importer tool, as Démian mentioned, it's a python based script.

Best

I guess she meant if you have albedo, roughness etc... all in the same format. If all your textures are in the same format (displacement included) you are stuck natively to give them different color spaces. You have to write a snippet of code.

Quixel Bridge, CSK, they're all forms of spoon feeding, very welcome in some cases, not in my case. If I cannot import and connect these textures myself, there is something wrong.

You may want to avoid falling in the trap of seeing your software as the norm.
It's actually the exception that needs to be told: force luminance on greyscale maps
It's the exception in displacements: https://youtu.be/3lvi2wO7xzA?t=204
it's the exception in a lot of things, there is nothing wrong with that, other than forgetting it is an exception, and exceptions needed to be highlighted to potential users. Once they are known in plain English, of course they can be converted to python.

Thank you, will pass. We've moved on, we'll be using Karma and Solaris instead.

I use Houdini here, for almost every projects now. Good luck with Solaris and Karma. Not that I am against it but they are clearly not production ready yet. Maybe in a year or two... Rule of thumb: a renderer to be mature, count at least 3 years for everything. Not to mention Solaris and how slower it is compared to Clarisse that is designed from the ground up to be artist friendly, hassle-free workflow and easy to use while being technically very TD friendly, advanced and based on industry standards.

The problem you described is workflow related, there is no technical issue or bug. I'll second what dboude said: a custom script could help solve this very easily.

For your information, if you are using streamed map file, you don't need to use the force_luminance option. Besides that, I do not understand your message entirely, or his meaning. Clarisse as a norm? It is already used in many studios, and in CGI, there isn't "one" norm but many.

Making a pipeline decision just because of what you posted on this post is absurd.

We try to be as neutral as possible and let the users define their pipeline. As I said a simple script can automate those settings. You will spend a half-day making the script but then will gain hours building your scenes. It's up to you.

Good luck