ACEScg

[^Lele^]

i seem to spend most of my time in that tool these days...max or vray needs a rule system like maya where you can specify texture naming and their corresponding colorspace info.

Edit: bah me, wrong link.
here:
https://docs.chaos.com/display/VMAX/...Workflow+Setup

[francomanko]

maybe its because im chicken, but I dont like the idea of having to go through all my textures and rename them, breaking my asset library etc. The rules thing was useful because it allowed me to work with my textures as they are but still automate the process. The vraymax convertor tool is very useful, but i just feel like im constantly in it

[Vizioen]

I agree and I will never start renaming my textures, that's insanity. There needs to be a better way. So many ways this could be implemented or specified, renaming textures is not one of them.

[^Lele^]

The best we can currently offer under Max is the above.
I personally find the rule system a cop-out, and a mess to set up properly, as there are a number of unavoidable clashes that can arise from it, and a degeneracy risk for arbitrary material (i.e. a rule per texture file.).
After all, rules won't be able to cope with randomly named textures, in random places, either: they'll need some form of naming convention, like any pipeline tool in CG does, to be effective.

All we do is have fixed, clear rules for naming.
It is much cleaner to have a copy of an asset built for the colorspace it's meant for, and old libraries refreshed to cope with the newer paradigms, than wading tentatively into a quagmire of mixed assets and hope they'll work.
The same kind of scripts you use will be of great help in relinking the renamed bitmaps into your shaders, just you won't be doing it several times per project.

[^Lele^]

I agree and I will never start renaming my textures, that's insanity. There needs to be a better way. So many ways this could be implemented or specified, renaming textures is not one of them.

You already rename them to define the channel they use, and rename them to define the transfer function.
I fail to see why adding one more particle for the color space to use is a blocker.

[francomanko]

Large asset libraries that changing the name would break and mean everything needs relinking.

[^Lele^]

Large asset libraries that changing the name would break and mean everything needs relinking.

Indeed.
But relinking under a very clear ruleset is super-easy to automate.
F.e., where it was "mytexture_diffuse.png" it's now "mytexture_diffuse_srgb.png".
It's also easy to have a duplicate of the original asset data, and that alone be renamed and relinked, so that original assets stay untouched (and can keep being used under the old colorspace.), and disk space isn't expensive, these days.
It's truly the bread and butter of any pipeline TD to be able to provide for these kind of features in their tools, and there's a swathe of free scripts to this effect around.

This said, Autodesk will have important improvements for color management coming for Max 2024, but we're not at liberty to speak of them just yet.

[Vizioen]

That sounds exciting.

I agree with the auto renaming thing, and I wouldn't be reluctant to renaming if every person or company that created assets also actually named their textures according to either a standard convention or even at all (be it diffuse or reflection or whatnot).

I have a library with over 25K 3D models, and there's a shitload of different naming or not even clear names like 165024682740684qsdjoqsjd.jpg No use in renaming any of that. I understand for studios with big budgets that might not be such a big problem, but in smaller studios it's not worth the hassle.

Although I always try to be updated with the latest of technologies or workflows, I think I might sit this one out for now, until a less cumbersome workflow arises. I remember the days of switching between gamma setups and all the shaders needed to be completely reworked. The horror.

[^Lele^]

I understand the predicament, i really think i do.

But for those kind of assets, a rule naming system like Maya's is only going to add complexity, not help solve any issue.
Besides, they are all sRGB-encoded, so why would you change the way they are interpreted by V-Ray?

The issue of haphazard naming and such is something that should be resolved before using the asset, rationalising naming and file placement.
If there is rhyme and reason (read: a convention) in how assets are prepared and stored, then both the rule system and our fixed-rule would be trivial to make work.
If there isn't, then texture filename appending is by far the easiest, and safest, way to go about it.

[Joelaff]

Perhaps you could implement a meta file system where if there is a file with the same name as the texture .meta in the same directory this could contain info on the colorspace, etc as a text file of course.

[^Lele^]

I need to apologize here as i had missed one key part of this issue: that the bitmaps are treated as if they were encoded in the colorspace used.
This is great in a few cases, but it's indeed cumbersome when someone wants to use an sRGB asset in an ACEScg colorspace, as the textures would then be automatically interpreted as ACEScg encoded, and they are instead left as sRGB.
This in turns leads to the need to use scripts to mass-change the bitmap properties.

It would work better if instead any 8bit texture for which the "_ACEScg" flag wasn't specified was instead treated as sRGB by default.
Someone duplicating an asset and its textures to work in ACEScg would find the trivial to add the particle to the filename, and cascade the changes needed to the asset, while anyone bringing sRGB content to the ACEScg colorspace wouldn't have to change a million sRGB maps settings manually.

So perhaps we'll change to work this way (for versions of Max earlier than 2024).

Thoughts?

[Joelaff]

Sounds like a good idea, but I also like the idea of a separate .meta file or similar because you don’t have to rename textures and they contribute to work with old projects.

The VRayBitmap Loader could also give the option to create this .meta file (Like the way Loaders create .ifl files now) so that the setting would become permanent for future uses of the textures.

[^Lele^]

Sbs files are not liked universally, unfortunately.
The risk of losing them, along with the metadata they have, is great (ask anyone with a ton of retouched photos for which they lost the SBS files...), so relying on them exposes us to the risk.
Going forward, OCIO color management will provide for much better ways across the board, even in Max.

[M.Max]

It would work better if instead any 8bit texture for which the "_ACEScg" flag wasn't specified was instead treated as sRGB by default.

This would be perfect ^

Please consider this or at least an option under render settings >Color space options to "force sRGB for none specified bitmap color space", so it doesn't break other peopel workflow.

[Vizioen]

It would work better if instead any 8bit texture for which the "_ACEScg" flag wasn't specified was instead treated as sRGB by default.

This sounds good.