New feature ideas 3

[Pixelcon]

The new VRaySky clouds are great but it can be very difficult to find a combination with lots of clouds and direct sunlight due to the sun often being occluded behind the clouds (especially at lower angles). I have found myself going through hundreds of seeds to find a good combination. It would be nice to have some sort of override that always ensures the sun is visible, if desired. Some way to diminish clouds anywhere near the sun, perhaps with some kind of falloff or a more intelligent system.

Happened to me just today. Some sort of spherefade effect around the sun-disk (with infinite depth ofc) and a controllable radius and falloff would be delicious.

[meanadam]

Vray material management. There has to be a better way to organize and maintain mat libraries. The "new" library is good (when it works), but why can't we create our own with this system to bypass the max library interface?

[Pixelcon]

Auto-Exposure compensation

Personally I think the auto-exposure feature is limited in its use due to a lack of exposure compensation. I think an extra box in the 'Color & Exposure' rollout for the VrapPhysicalCamera that allows one to input an EV exposure compensation would make the feature more rounded and more usable.

[Vizioen]

Vray material management. There has to be a better way to organize and maintain mat libraries. The "new" library is good (when it works), but why can't we create our own with this system to bypass the max library interface?

Just use Connecter, K studio Project Manager or XSMP. No need for another library manager, I'd rather have Chaos focus on render features rather than library features.

[philip kelly]

Data to optimize scenes. Like the new feature in maya, but for max and Vray, Please.

[GeraldW]

Hey,
I would love to see a Colormixer like the one from CameraRaw inside the VFB.
It let´s you adjusting Hue/Saturation/Luminance based on color. I use it all the time in PS to adjust the greens. Very easy to get a nice fresh look for your vegetation for example.

[JezUK]

***** Ignore *****

[francomanko]

This is a tiny one, but an option in the VFB, to save out the exr with ALL the layers disabled. This is so that, if I have a saved VFB layer file, I can reload the exr and reapply everything. (i know you can turn all layers off manually and do it, but maybe a quick option somewhere to turn on/off all....yes im lazy)

[Joelaff]

This is a tiny one, but an option in the VFB, to save out the exr with ALL the layers disabled. This is so that, if I have a saved VFB layer file, I can reload the exr and reapply everything. (i know you can turn all layers off manually and do it, but maybe a quick option somewhere to turn on/off all....yes im lazy)

Along a similar line it would be great if saving of any VFB corrections into the output file could be disabled in the render settings dialog. That way we could use those without fear of accidentally baking them into a render. I just did this on a project and had to re render it as it changed client approved colored footage.

With such a setup you could use the VFB features in IPR with no fear of baking them in to final renders.

I believe saving to vrimg does this now, but not EXR, if I am not mistaken.

[Vizioen]

Along a similar line it would be great if saving of any VFB corrections into the output file could be disabled in the render settings dialog. That way we could use those without fear of accidentally baking them into a render. I just did this on a project and had to re render it as it changed client approved colored footage.

With such a setup you could use the VFB features in IPR with no fear of baking them in to final renders.

I believe saving to vrimg does this now, but not EXR, if I am not mistaken.

Why not just use Vrimg?

[Joelaff]

Why not just use Vrimg?

The files are huge. The IO is single threaded. Very few programs read them. So this mean everything needs an extra processing task to convert. When dealing with 300 1.5GB vrimg files with single threaded IO that is not much fun. The farm can do it of course, but then do you delete the source vrimg or not? What if the conversion didn't work right? So now you have extra files in your projects that are not needed as well.

There should definitely be a way to keep VFB corrections from being baked into the output without having to manually turn them off before render. Also, why are the two major floating point formats (vrimg and EXR) treated differently? That is confusing in and of itself. There are already two areas for these settings in the Render Settings.

[Vizioen]

Maybe that's an idea for a wishlist item then, improve the vrimg format? I like it, because I do most of my first CC in the VFB and I'm not animating a lot, but when I do, the file sizes are indeed no fun. Maybe the compression method can be optimized, and multithreaded.

An option to save a file of your choice without VFB corrections would indeed for some workflows be a plus.

[piotrus3333]

The files are huge. The IO is single threaded. Very few programs read them. So this mean everything needs an extra processing task to convert. When dealing with 300 1.5GB vrimg files with single threaded IO that is not much fun. The farm can do it of course, but then do you delete the source vrimg or not? What if the conversion didn't work right? So now you have extra files in your projects that are not needed as well.

There should definitely be a way to keep VFB corrections from being baked into the output without having to manually turn them off before render. Also, why are the two major floating point formats (vrimg and EXR) treated differently? That is confusing in and of itself. There are already two areas for these settings in the Render Settings.

you can chose exr as your "VRay raw" output. if file size is not to your liking - use compression.

[piotrus3333]

Along a similar line it would be great if saving of any VFB corrections into the output file could be disabled in the render settings dialog. That way we could use those without fear of accidentally baking them into a render. I just did this on a project and had to re render it as it changed client approved colored footage.

With such a setup you could use the VFB features in IPR with no fear of baking them in to final renders.

I believe saving to vrimg does this now, but not EXR, if I am not mistaken.

VRay Unclamped Color element could help.

[Joelaff]

We typically use vrimg if we need to denoise. If the veDenoise could be improved that would solve all the problems on our end. Extensive info on this here. A few tweaks to some standalone tools… no UI… a programmer’s dream!

https://forums.chaos.com/forum/v-ray...production-use

I will have to look at unclamped color re. Is that going to be RGB beauty without the VFB stuff? Of course then you have both when you typically only need one.

I would say 95% of the time we just want the data without being processed by the VFB… except when doing early test renders before a comp is set up. This is why a render setting to disable saving VFB corrections would be so helpful. I guess I should look at modifying deadline to handle this.

Perhaps another approach would be for the VFB to have a separate “folder” for “view LUT” corrections that would be displayed, but never saved in any file. This would actually be the most versatile because it could have “ViewLUT” and “File LUT” options such that you could display one thing, but save something else. Like it does now with sRGB transforms for viewing linear data.