V-Ray 7.3 for Blender – Display correction changes in VFB no longer sync to Blender’s native render viewport (regression from 7.2/7.1)

Subject: V-Ray 7.3 for Blender – Display correction changes in VFB no longer sync to Blender’s native render viewport (regression from 7.2/7.1)

Description:

I’m not sure if this is a bug or an intentional change, but in V-Ray 7.3 for Blender, when I adjust exposure or change the display color space (e.g. switch to OCIO) inside the VFB’s “Display Correction” settings, those visual changes are not reflected in Blender’s native render viewport.
For example, if I set the display color space to OCIO in VFB, the Blender viewport still shows the default sRGB display color space.

This is different from previous versions (V-Ray 7.2 and 7.1 for Blender), where the display correction settings made in VFB were synchronized with Blender’s native render viewport.

As a heavy OCIO user, this regression makes my workflow much more difficult, because I can no longer see the correct display‑color‑space look inside Blender’s native viewport while rendering.

Could you please look into restoring the old behavior?
Thank you.

Feel free to copy and paste this into the Chaos Group forum, V-Ray Ideas Portal, or the official bug tracker.

Apparently, Blender’s viewport displays gamma 2.2. I have used the latest OCIO 1.3 ACEScg downloaded from GitHub to set up the VFB, since Blender’s cannot be modified. The config.ocio is there, but it doesn’t allow you to select ACES 1.3, 2.0, Khronos PBR, or anything else. I have used ACEScg 1.3, but the viewport still shows gamma 2.2.

Another question that arises here is: if I configure ACEScg in V-Ray, do I have to tell each diffuse color texture to use the ACEScg space, or do we leave it in sRGB? I ask this because, when I convert Blender materials to V-Ray materials with the plugin, they are set to sRGB, even though I am using color management in ACEScg.

It is also behaving a bit erratically, because the option to open an alternative config.ocio sometimes appears and sometimes does not in the VFB.

Blender 5.1 works with a newer config.ocio configuration, and it seems not to be compatible with the expected version in VRay. Also, Blender seems to set an environment variable during boot up that points to where the config.ocio file is, and VFB does not allow to load any other file. The path where config.ocio is located (in my computer) is as follows:

C:\Program Files\Blender Foundation\Blender 5.1\5.1\datafiles\colormanagement\config.ocio

Solution: I backed up this file, downloaded the desired config.ocio file from GitHub and copied it to the same folder, so VRay finds the expected version. Now VFB is working as expected with OCIO. I didn’t check on the RT viewport.

Yes, Blender uses a newer OCIO version that V-Ray’s OCIO library currently doesn’t support. It will be fixed in our next release.

Hi,

Finding my OCIO file is not a problem for me on Linux; depending on whether I install the Flatpak or portable version, the paths change, but I know where it is.

The thing is, when I tell Blender to use V-Ray as the render engine, it ignores Blender’s OCIO and uses its own. So far, that’s fine. The problem is that I can’t always tell the VFB to use it. Sometimes the option to load an alternative OCIO appears, and sometimes it doesn’t, as shown in the screenshots I attached earlier.

Here’s what I specifically noticed:

  1. When setting ACEScg in V-Ray and wanting the same color to show in the VFB, sometimes it allows starting with an alternative OCIO and sometimes it doesn’t, on Linux. It also won’t let me load ACEScg 1.3 as an environment variable via command line for the Blender executable. I don’t know if Chaos restricts control over environment variables for some specific reason.

  2. One more thing: I myself had reported a color mismatch bug between the viewport and VFB, which was fixed in the beta version. Thanks for that!

I really like V-Ray, but I still haven’t found a stable way to work with ACEScg. I waited until this version came out, but I see the issue is still there.

Regarding Substance Painter, I tried every way to use ACEScg 1.3, but it looks different. If you create a sphere of any color with metalness, working with the well-known standard ACEScg inside Painter and then look at it in the viewport blender, you notice that ACEScg isn’t working correctly; otherwise, that detail information would be recovered in the on-screen reflections.

About the workaround mentioned here of replacing the config.ocio file: yes, it’s possible on Linux, and I had actually already done it that way, as seen in the paths from the screenshots in my previous message. The images I’m uploading again clearly show the disparity between the viewport and the VFB when ACEScg 1 is loaded in the VFB but not in the viewport, even though I told V-Ray to use ACEScg. My guess is that maybe the OCIO wasn’t loaded correctly in Chaos’ addon folders, or some environment variable is missing. I’m not entirely sure.

Lastly, I think there are several questions raised in my previous message that weren’t addressed. For example: when converting materials while in ACEScg, is it correct for the diffuse to be generated with sRGB? I’d like to know if this is expected behavior or if something needs to be adjusted.

Thanks!

I’ve noticed that the most correct and compatible way with Substance Painter colors is to leave the diffuse maps in sRGB as they are.
But this is only for the VFB. In the viewport, as I mentioned before, the color difference clearly persists. It’s not a problem, one can get used to working with the VFB.

Thanks!

excellent work!

WIP.
In case it’s useful to anyone, here’s the configuration I found to best match the viewport and the VFB.

Or add Un-tone-mapped for better texture similarity.

Sorry for the OT…but is there already a Linux version of Vray for Blender?

I’m aware that it’s on development since some weeks but I’ve never seen it in action.
Are you part of a beta testing on this or I’ve missed something with latest release?

We officially released V-Ray for Blender on Linux last week :slight_smile:

We will look into the problems with color corrections and I am hoping we will have better OCIO support for next release. About your other ACEScg questions I will need some time to look into it and will try to give you an answer.

Bardo, how are you? Yes, I had access to a trial version a few weeks ago; to be honest, I bothered the developers quite a bit to get it, hehe.
But now you can already use the final Linux version with an installer that doesn’t discriminate between RPM or DEB, and you can download it from the Chaos website. It’s available for both the paid version and the community version.

:+1: Ok thanks, I appreciate it!

Thank you for interest and bothered the devs… :grinning_face: … I’ve missed this really nice feature…

Enjoy Bardo, enjoy :saluting_face:

Jumping in the discussion.

I, too, use a lot the OCIO workflow. So I reverted back to the previous version (update 2).

But I checked on the website, and the update 2 is no longer available anywhere. Fortunately I saved it on my hard drive, but any newcomer wanting to use the OCIO workflow will be unable to download a compatible version.

Please fix asap update 3 or make available to everyone the update 2 on the website.

Thanks !

Or you can also, until the next version, simply use the VFB to view your render previews there; it does load the color and the OCIO profile correctly.
Just be aware, only if you forcefully replace it in Blender’s colormanagement folder, because the little folder button is not in the VFB, at least on Linux.
I also saw that there is a super nice option to select objects directly on the VFB, if you have a small monitor and it takes up a lot of your space!

Cheers!

Good afternoon, I wanted to know if we will have correct color in the VFB and in the Blender viewport in some downloadable from nightlies soon?
Thank you.
Excellent work!