Vray 6 vs Redshift 3.5 simple comparison

[GregoryVFX]

Huh...

This was interesting...
https://www.dropbox.com/s/05x8itrszz...rison.mp4?dl=0

Not too bad at all...

[Alex_M]

What are we looking at here? Are you comparing rendering speed?

[Muhammed_Hamed]

Hi GregoryVFX

Did you swap the labels in your video, I see you labeled V-Ray's frame buffer Redshift 3.5
And are you using GPU LC for this comparison?
What denoising options are you using in V-Ray and Redshift?

Our GPU IPR + AI Denoiser in V6 has improved quite a lot
The AI denoiser is much better now, and is able to preserve the shading details much better, and on the other side we have a new Device Manager coming up soon. It will allow you to pick a device for your GPU denoising(if you set the denoiser to use a separate device, you get nearly double the IPR performance)

We have an ongoing effort on improving the GPU Look-Dev workflow(interactivity/undersampling), as it is why most people use GPU rendering in the first place. This is WIP now, and should hopefully make it to V6.0

Best,
Muhammed

[GregoryVFX]

What are we looking at here? Are you comparing rendering speed?

We are watching the superiority of Vray 6 over latest Redshift, in terms of not redrawing the image with every single viewport interaction.
Redshift redraws and reapplies Denoising over every single viewport change, where Vray stays solid.

[GregoryVFX]

Hi GregoryVFX

Did you swap the labels in your video, I see you labeled V-Ray's frame buffer Redshift 3.5
And are you using GPU LC for this comparison?
What denoising options are you using in V-Ray and Redshift?

Our GPU IPR + AI Denoiser in V6 has improved quite a lot
The AI denoiser is much better now, and is able to preserve the shading details much better, and on the other side we have a new Device Manager coming up soon. It will allow you to pick a device for your GPU denoising(if you set the denoiser to use a separate device, you get nearly double the IPR performance)

We have an ongoing effort on improving the GPU Look-Dev workflow(interactivity/undersampling), as it is why most people use GPU rendering in the first place. This is WIP now, and should hopefully make it to V6.0

Best,
Muhammed

Redshift 3.5 is correct label; that's Redshift's Viewport IPR window.
Both scenes are identical settings; brute force for both primary and secondary.
nVidia denoiser used on both.

[Muhammed_Hamed]

Thanks for explaining that
One note is that you don't necessarily need BF/BF in V-Ray's case to compare, our GPU LC is mature now and very fast to calculate. It uses 100 bounces by default and allows for many features like adaptive domelight

Best,
Muhammed

[GregoryVFX]

I was never a fan of LC on any renderer and being disabling it for ages in favor of brute force, since it's as fast, without pre-calc time and flicker-free safe.
But, I'll check the status in v6 for sure...

[Muhammed_Hamed]

Yes, we recommend using LC always, it is key in V-Ray's workflow.
Our implementation is very advanced and widely adapted in production. It takes seconds to calculate in V6, we pushed it to use the GPU resources close to 100%
LC allows for many cool features like Adaptive domelight(better illumination for HDRI lighting, easier setup and much faster rendering), Adaptive lights(speeds up rendering of scenes with many light sources), Auto exposure/white-balance and you have an Animation preset that prevents flicker..
You get 100 GI bounces for free, this makes a difference if you have bright surfaces in your scene, you get a brighter result and more balanced contrast overall in the scene. With BF you can use 3 or 4 bounces, and each extra bounce nearly doubles your render time
And about speed, it depends on your scene. Here is a quick test,

https://imgsli.com/MTA4MTc0



The BF/LC result is much cleaner, to get the image as clean it will take much longer with BF/BF

Best,
Muhammed

[GregoryVFX]

I'll give it a try for sure.

I don't do static arch stuff though and I deal with deforming animated geometries - like fluids and other FX- most of the time.
It required a lot trial and error in the past to make sure no flickering was coming from using LC.

Usually BF works straight away with no need for pre-calculating caches for animation etc. so it ends up a faster workflow.
Rendering is handled by the "slaves" (computers), but the hands-on user time is way more precious.

But, definitely I'll have to explore the new LC workflow with VRay 6, for sure.

Thanks for the insight...

Chees,
Greg

[DestinHalfmann]

VRay is not designed to use BF+BF. BF+LC is used for most of its internal features and are requred for most of the newer features.
If you decide to do volumetrics in BF+BF combination. Your computer will hate you.
It seems you're using VRay the way it was "meant" to 5-10 years ago.

The VRay default settings should get you 95% of the way with no to almost no need for tweaks.

BUT, this is based on the CPU feature set/workflow. Not sure if this applies 1:1 for the GPU version.

[GregoryVFX]

VRay is not designed to use BF+BF. BF+LC is used for most of its internal features and are requred for most of the newer features.
If you decide to do volumetrics in BF+BF combination. Your computer will hate you.
It seems you're using VRay the way it was "meant" to 5-10 years ago.

The VRay default settings should get you 95% of the way with no to almost no need for tweaks.

BUT, this is based on the CPU feature set/workflow. Not sure if this applies 1:1 for the GPU version.

Well, now...

I do mostly fluid sims and Light Cache is much slower than BF; considerably when rendering long sequences.
This is a fact with sequences rendered twice using BF/LC and BF/BF.
VRay default settings are not meant for fluid sims, by a long shot.

Do some homework before jumping into conclusions.