Proper ACEScg workflow

[3DZver]

Does it work on bitmaps nested with Multi/sub materials, or Falloff, Color Correction, VrayMultiSubTex maps, etc? Would be much simpler if there was just a global option to use sRGB for all images in diffuse nodes .

Script or global option makes no difference here: if an image is in multiple, conflicting places (i.e. diffuse and bump), there's no way to do it right.

Actually it can be done. This feature is already implemented in the V-RayMtl Converter plugin (in "Advanced Fix" section).

Any chance of adding Forest Color submaps to that script Lele?

V-RayMtl Converter does this if Forest Color map (like any other multi-map) used VRayBitmap or VRayColor as submaps.

ps: Although the question was intended for ^Lele^, I hope he doesn't mind if I answer

[justini]

Actually it can be done. This feature is already implemented in the V-RayMtl Converter plugin (in "Advanced Fix" section).



V-RayMtl Converter does this if Forest Color map (like any other multi-map) used VRayBitmap or VRayColor as submaps.

ps: Although the question was intended for ^Lele^, I hope he doesn't mind if I answer

I already own this so this is excellent news. Thank you!

[^Lele^]

Actually it can be done. This feature is already implemented in the V-RayMtl Converter plugin (in "Advanced Fix" section).

I should indeed have added "without changing the user's assets."
Duplication isn't a solution, in my book, for a host of reasons.
Truth be told, if one was using only VRayBitmap loaders, then the code and logic for those is much more advanced, and the instancing/duplication affair would only be a case of layout changes to a scene, not of memory consumption.

ps: Although the question was intended for ^Lele^, I hope he doesn't mind if I answer

Not at all, glad you joined in!

[Mikhalenko]

I should indeed have added "without changing the user's assets."
Duplication isn't a solution, in my book, for a host of reasons.
Truth be told, if one was using only VRayBitmap loaders, then the code and logic for those is much more advanced, and the instancing/duplication affair would only be a case of layout changes to a scene, not of memory consumption.


Not at all, glad you joined in!

^Lele^ maybe you can add to your script option with ForestColor?

[^Lele^]

^Lele^ maybe you can add to your script option with ForestColor?

Will look into it, but can't make promises on the timing.

[3DZver]

I should indeed have added "without changing the user's assets."
Duplication isn't a solution, in my book, for a host of reasons.
Truth be told, if one was using only VRayBitmap loaders, then the code and logic for those is much more advanced, and the instancing/duplication affair would only be a case of layout changes to a scene, not of memory consumption.


Not at all, glad you joined in!

Hello Lele!

Perhaps, I did not quite understand your message, but the function implemented in V-RayMtl Converter does not changed user's assets.
It switches the color space to ACEScg or sRGB in the settings of the VRayBitmap and VRayColor maps, while checking whether the references of these maps are in conflicting places (i.e. diffuse and bump etc.), and if it finds such, the map in the bump is made unique, breaking the dependent link with the original references. For example, if the function detects that the same VRayBitmap map is used in the diffuse and bump slots, then the map in the bump is made independent of the map in the diffuse. In this case, the color space of the map in the diffuse switches to the one specified by the user (ACEScg or sRGB), and the color space of the bump map does not change.
It might have a slight effect on memory, but in the end it will greatly reduce the time compared to doing it manually with a huge number of texturemaps in the scene. Moreover, if this were done manually, it would still have to break the dependent connections of the maps in the conflicting places.
I would also like to note that for this function to work correctly, you must first convert all the maps in the scene to VRayBitmap, since only these maps (same as VRayColor) allow you to switch the color space.

Maybe I'm wrong about something, but at the moment this is still the best solution compared to processing and renaming a lot of texture files used in the project.

[^Lele^]

Yeah, by changing assets i meant precisely that: making copies out of instances.
I had missed the fact we work with v-ray bitmap loaders, so the memory difference is negligible (as maps aren't loaded twice, regardless.).
As for conveninece, it really depends on a per-user basis: i personally find a lot easier to go into the textures and rename, there are a ton of free tools for that, and i do it once and for all.
Breaking the instancing may have severe consequences on some specific setups, particularly when it comes to variations, and scripted scene managers, so it's something i am still not comfortable in offering from the part of Chaos.
It's however good your script does it, so long as the user's warned of the implications, as you're a third party.

[3DZver]

Yeah, by changing assets i meant precisely that: making copies out of instances.
I had missed the fact we work with v-ray bitmap loaders, so the memory difference is negligible (as maps aren't loaded twice, regardless.).
As for conveninece, it really depends on a per-user basis: i personally find a lot easier to go into the textures and rename, there are a ton of free tools for that, and i do it once and for all.
Breaking the instancing may have severe consequences on some specific setups, particularly when it comes to variations, and scripted scene managers, so it's something i am still not comfortable in offering from the part of Chaos.
It's however good your script does it, so long as the user's warned of the implications, as you're a third party.

To be honest, I have never encountered any problems when making copies out of instances. Throughout my long practice in visualization, I often had to do this, especially in the process of working on a scene and setting up materials in it, and there were no problems with this. Although we have not yet received any reports of any problems from our users, you are certainly right that users should be aware of any problems that may arise when working with scene assets regardless of whether they are using third-party or native software for this.

[^Lele^]

Think massive car rendering, with thousands of possible permutations for configurators being rendered, and metadated: maps can carry info.
Or setups which rely on map names and/or their instanced qualities to change things in a scene or pass.
I've had all sorts of issues to dodge both in film/tv and car rendering, myself, but it's really down to what the specific user/company needs are, and how a given pipeline is set up.

[3DZver]

Think massive car rendering, with thousands of possible permutations for configurators being rendered, and metadated: maps can carry info.
Or setups which rely on map names and/or their instanced qualities to change things in a scene or pass.
I've had all sorts of issues to dodge both in film/tv and car rendering, myself, but it's really down to what the specific user/company needs are, and how a given pipeline is set up.

Yes, I agree. It all depends on the specific case and the specific workflow. But here the user himself has to choose what to use in his workflow. It is impossible to foresee all the millions of variations in principle
We do not offer the only correct solution for all cases, we only offer one of the options that can help users in solving their problems.

ps: By the way, when creating a duplicate map, the name remains the same (it only changes the unique AnimHandle ID), but can make it so that a new name is assigned to this duplicate.

[^Lele^]

It is impossible to foresee all the millions of variations in principle

Eh, i loved that when i used to be TD for a single company at a time!
Take this simple example:



Imagine a script has a hardcoded map name ("MyMapName"), and has the task to output render passes based on what bitmap is actually loaded.

Now, splitting the bitmap will create a problem.
If the new map name is not exactly "MyMapName", then the script is not going to find the map, and in the generated passes, only the RGB changes (if that was the original map).
If the new map name is exactly "MyMapName", then it's a duplicate name, which means the script will likely become confused, and it's a generally horrible practice to have duplicate node names.
An issue like this will need, in my experience, a TD to go through the scene AND script together, and find a better way forward.
Which likely will involve renaming maps, and manually splitting duplicates where needed in a way the modified script can be tracking.

We do not offer the only correct solution for all cases, we only offer one of the options that can help users in solving their problems.

As third party, the load is somewhat lessened (and you write your own EULA).
We'd get into troubles in no time.

[3DZver]

Eh, i loved that when i used to be TD for a single company at a time!
Take this simple example:



Imagine a script has a hardcoded map name ("MyMapName"), and has the task to output render passes based on what bitmap is actually loaded.

Now, splitting the bitmap will create a problem.
If the new map name is not exactly "MyMapName", then the script is not going to find the map, and in the generated passes, only the RGB changes (if that was the original map).
If the new map name is exactly "MyMapName", then it's a duplicate name, which means the script will likely become confused, and it's a generally horrible practice to have duplicate node names.
An issue like this will need, in my experience, a TD to go through the scene AND script together, and find a better way forward.
Which likely will involve renaming maps, and manually splitting duplicates where needed in a way the modified script can be tracking.



As third party, the load is somewhat lessened (and you write your own EULA).
We'd get into troubles in no time.

Yes, I wrote about this - most likely it will be necessary to give a new name to the map when creating a duplicate (this is also already implemented in the V-RayMtl Converter). Thanks for the clarification!
In fact, we are constantly working on improving the plugin's capabilities, so any comments will be welcomed by us.

[justini]

I should indeed have added "without changing the user's assets."
Duplication isn't a solution, in my book, for a host of reasons.
Truth be told, if one was using only VRayBitmap loaders, then the code and logic for those is much more advanced, and the instancing/duplication affair would only be a case of layout changes to a scene, not of memory consumption.


Not at all, glad you joined in!

So would a better solution not be to have a new VrayColorPrimaries map which lets you change the primaries on selected channels without needing to duplicate and rename the maps? This would also be handy for plugin maps which don't support conversion of bitmap loaders to VrayBitmap, such as Multitexture.

[arcmos]

Mikhalenko

check out this script:
https://www.pixamoon.com/shop/458756...nizer/10951730


RGB color space (red) will be added soon. Color space transfer (green) is working.

[olly]

So would a better solution not be to have a new VrayColorPrimaries map which lets you change the primaries on selected channels without needing to duplicate and rename the maps? This would also be handy for plugin maps which don't support conversion of bitmap loaders to VrayBitmap, such as Multitexture.

VRayOCIO can probably help you here?