Upgrade questions from Vray 3.7 to Vray5

[ben_hamburg]

Hey there,
We are still in the process of upgrading from Vray 3.7 to Vray 5.
Our most pressing questions about the sss speed has been resolved, now we´re mostly wondering about how to best utilize our farm.

Its been awhile, since I last tried out Vray GPU and then there was Vray Next and now its Vray 5, so there is a bit of confusion.

From what I gathered so far, Vray 5 contains Vray GPU and Vray Production, which is probably closest to the Vray 3.7 we know, in terms of functionality.

Back when I first looked into Vray GPU, there were just too many limitations of what could be rendered and what couldn´t.

I already know, that the newest version can still render on CPU if necessary, so, mainly if there is too much data to fit on the GPU.
So, in theory, we could do our lookdev purely with gpu on our workstation and then render in the farm on cpu, without any visual difference, and upgrade our farm in the future if need arised.

BUT...here are my questions:

1. What exactly are the differences between Vray GPU and Vray Production?
2. Can I just render 3.7 scenes on GPU without doing any conversion? Or do I need Vray Production to guarantee seemless transition from 3.7 scenes (and by guarantee and seemless I mean, just like with the old upgrades, where I just got a box telling me "Vray sampling has changed etc" or " New sky model", and nothing major, like features not rendering at all)?
3. Are there still limitations of features that are not available on GPU? I already know Vraydisplacement is now available, as well as volumetric renderinga and forest pack. What about procedural maps etc? If there are still restrictions, is there a list online I could check?
4. If scenes don´t fit on the cpu while rendering with Vray GPU...is there a warning message or something, so I know why a rendering takes much longer than expected?
5.

I´ve already downloaded the Vray 5 demo, but I can´t test in in the office and my workstation at home has a hopelessly outdated GPU, so I couldn´t really test Vray GPU properly yet.

[kosso_olli]

So, in theory, we could do our lookdev purely with gpu on our workstation and then render in the farm on cpu, without any visual difference, and upgrade our farm in the future if need arised.

No. There will be visual differences between the two. Decide which renderer to use at the beginning of the project and then stick to it.

[ben_hamburg]

Do you have an example of the visual difference? If its just a bit darker or brighter in areas, that might not not that big of an issue in most of our projects.
As long as there are no compaitibility issues with previous scenes, made with vray 3.7.
It would be also more interesting to know the differences betweeen gpu and production.
We are not looking to switch renderers on a per project basis, but rather pick the one suited best to our needs and then stick to it...

[hermit.crab]

First of all, V-Ray GPU is the upgraded version of what in V-Ray 3.7 was named V-Ray RT. And directly answering your questions:

1. Think of V-Ray and V-Ray GPU as separate render engines, each using its own coding solution that is optimized for the specific hardware. Results are not always identical (i.e. displacement may be with a different seed on both engines), but the differences are minimized with each update.
2. Yes, you could do that. If there is something changed that is required, there will most likely be a warning message.
3. Here is a list of the supported features in V-Ray GPU on our documentation page.
4. I presume here you mean in the memory (as in VRAM)? There most certainly will be a warning message if you are exceeding the VRAM limit. This page might be helpful in such cases.

[ben_hamburg]

Ok, that answers some of my questions, thanks for the links.
Looks like there was some major catching up done in terms of what renders in Vray GPU now.

There is a bit of confusion about Hair, since it says it doesn´t render hair&fur...but I assume it renders Ornatrix?
And is Vray Hybrid yet another version, or is it just a checkbox to be ticked in Vray GPU?

My preferred option, as mentioned, would be to pick one engine and stick to that, whenever possible and whenever an old project doesn´t require an unsupported feature.

So, given your explanation about 1....Am I correct to assume that rendering Vray GPU purely on CPU would be slower than rendering Vray Production on CPU?
Because as I mentioned, the idea would be to do lookdev on a workstation with a powerful GPU and then just render in the farm on CPU.
But if rendertimes on cpu for Vray GPU vs rendertimes for Vrayproduction on cpu would be massively different, that wouldnt work for us.

And about 4. Do I just get an error message and then I need to tick a checkbox to render on CPU instead, or how does this work then? Or would I just keep that checkbox ticked in generak and not worry about error messages then?
I mean, I have no idea how much scene we could pack on a 3090 with 24 GB of ram, but Vraydisplacemet ( which we use extensively for our medical stuff) quickly fills up ram on Non-GPU renders as it is....

[ben_hamburg]

I just found this page:
https://docs.chaosgroup.com/display/...PUSetup-hybrid

So now I´m mostly interested in the rendertime difference between hybrid on cpu and production on cpu.

[hermit.crab]

As you've probably already read, the hybrid rendering is simply activating (a checkbox) the CPU cores in V-Ray GPU. Though a bit outdated, this article might provide clarity.

Regarding rendering with CPU on V-Ray GPU - most likely yes it will be slower, since running the CUDA engine on CPU is not efficient. CUDA is highly optimized for GPU cores, that work better with a bigger amount, but small in size jobs, on which the GPU with its hundreds of cores excels.

Regarding the lack of memory - A scene must be loaded into the VRAM prior to rendering. If there isn't enough VRAM (because a scene is too heavy - large textures, extremely detailed displacement, etc.), the rendering would not start. The amount of memory taken depends on the scene itself, so it is recommended that if V-Ray GPU is planned for rendering, the scene optimization should take place from the very start (there are options that ease this process such as mipmapping textures). The document I linked above provides optimization methods as well.

EDIT: Just tested Ornatrix hair on GPU and it seems to be working fine. We may need to update the documentation page, I'll look into this.

[ben_hamburg]

Yeah, I read that. Would it be possible to do a render test between Vray GPU on CPU and Vray Production render? Thats the only number I can´t figure out with the existing docs on the matter, like the link above, that only compares rendertimes between VrayGPU on GPU or CPU.

Depending on that we´d have to decide if it makes sense to only upgrade our workstation GPUS and we would still have decent rendertimes on Vray GPU in the CPU only farm, with the potential of future improvements, or if the rendertimes would be 10 fold higher than Vray Production, which would mean we´d have to stick to Vray Production until we can upgrade the whole farm to make use of Vray GPU.

OR....

Maybe we can still use Vray GPU for Lookdev on the workstations and then just switch to Vray production before sending it to the farm.
Depending on how big the render difference would be, at least we would never run into an issue with unsupported features, as all features from Vray GPU should be available for Vray Production, right?

Might be a bit unconventional, but I can´t imagine the render differences to be so huge, that it would be a problem for 80% of our projects.

[hermit.crab]

Well, it's not as simple as that. These differences (due to unsupported functionalities, etc.) consider the engine code itself regardless of the hardware used, so rendering something that is unsupported in V-Ray GPU on CPU won't resolve the issue. Most functionalities are supported, but there are exceptions.
Starting with V-Ray CPU and sending to render with V-Ray GPU is, as already mentioned, not recommended. First, because of the possible differences that may occur, which may or may not have a decent workaround (some requiring re-rendering, which surely time-consuming). Second, because of the optimizations required mentioned earlier. A scene may render fine with CPU, but sending it directly to GPU may require additional optimizations that should have been thought of at the very start of the production.

Look at the attached image (a comparison between V-Ray CPU and CPU on V-Ray GPU, at noise threshold 0.01). Though the result is nearly identical (different noise distribution), render times are nearly double with CPU on CUDA.

[ben_hamburg]

Hey, thanks for the testrender, thats a good example. If rendertimes are doubled in that comparison, it might really not be an option to render with vray GPU on a purely cpu based farm, vs simply sticking to Vray Production.

However...it also illustrates, that I can´t spot a single visual difference between Vray GPU and Vray Production that wouldn´t be ok, albeit its a very simple scene...

That leaves me with the option I imnetioned above: To simply do my Lookdev on my Workstation on Vray GPU for all projects that fit to the GPU and profit from the speedtboost with material and lights lookdev, and then simply switch over to Vray production, do a test render to see if there are any massive look differences or not (Like I said, only for forgiving projects that don´t need pixel perfect accuracy), and then render it in the farm with Vray production.
The only hurdle would be to not accidentally keep working on Vray Production than and adding unsupported features.
It will also get me used to the current restrictions of Vray GPU for projects, so once the farm is being updated to gpu rendering, we will also know the workflow better (plus, you´ll keep making those restrictions less and less...

As long as there are no Vray GPU exclusive features, that would make a scene not render correctly in Vray Production, this seems lika a viable compromise for now.

I see only a problem the other way around: Working first on a Vray Production project and then switching to Vray GPU, due to restricted features.

[kosso_olli]

However...it also illustrates, that I can´t spot a single visual difference between Vray GPU and Vray Production that wouldn´t be ok, albeit its a very simple scene...

Do the same on a complex scene (some interior render, renders with Forest Pack etc.) and you will see massive differences between the two. Starting from difference in bump mapped materials, to light distribution, discplacement, differences in prodecural textures, render noise differences etc.

[^Lele^]

The GPU Vs. CPU rabbit hole goes a lot deeper than a teapot and plane can show.

If you plan to render Hair, test for hair specifically, with the shaders and kind of setups you expect to use for production.
For volumes, SSS, complex shading networks, do the same thing.

The GPU will always wipe the floor with a CPU on very specific tasks (f.e., basic diffuse shading, and so on), while it'll be hopelessly slower than the same CPU at divergent ones (think shading with many conditionals into the material setup, long SSS paths, etc.).

To this, you should add that GPU will have to depend on the video drivers, and so performance may vary without our - or yours - prior knowledge with each driver update.
The change may be for the good (speed or features) or for the bad, and fixing those would always need some time.
So the technical layer to be wary of is slightly bigger for GPUs, and controlling very tightly what happens on a specific workstation (recommended drivers, minimal auto-updates, etc.) will have to be factored in in the operating costs (that they are going to be paid by IT or by the user, is irrelevant.).

Truly, consider that the overlap between CPU and GPU is purely one of workflow (i.e. which maps and materials one uses, and their controls.), and even that is only partial.
We make absolutely no claim of results parity between the engines, and we do so with full knowledge of the past efforts made to achieve it, without managing that.

If one starts with GPU, one can *only* expect to finish that job with GPU.
Using CPU for it would mean redoing the scene setup nearly from scratch (and redoing it from scratch would be my personal suggestion.).
The same can be expected going in the opposite direction.

So the plan to do lookdev on GPU is not quite achievable.

If you're heavily invested in CPU power already, stay safe in the knowledge that you aren't really missing out on GPU rendering.
On the other hand, were you truly invested in rendering on GPU (so, many a quadro card, with tons of RAM and crosslinks. A lot of money. A single gaming card wouldn't be able to do much production of decent size.), you could work away knowing you're missing little to nothing in features compared to CPU, even if many of them worked differently.

We have many examples of clients doing great work using either (if not both together!).

[ben_hamburg]

Yeah, I´m not doubting your judgment and I´m thankful for any input.
I´m still hoping to get my workflow idea to work out, Like I said, a lot of our projects are very forgiving and get a ton of "makeover" in After effects anyways.
We´ve also started looking into Unreal engine as a secondary render engine for certain projects (I yet have to look into Vray for Unreal and wether that makes sense as an inbetween workflow).

The learning curve on materials is incredibly steep, because of the optimizations to run in realtime require a lot more complex node setups to achieve simple tasks as blending two materials.
BUT.
What I did learn is how much more creative and fun it is to work in or near realtime for lookdev, especially for lighting and that I´d rather work around some limitations, when I can spend more time making artistic choices vs waiting for testrenders and fiddling my thumbs.

Again, I´ll have to wait for my GPU upgrade and for our company to move to vray 5 to really be able to decide wether its just wishful thinking to work like that.

I´m still happy you worked hard to weed out the restrictions on whats supported on GPU, that made me stay away from GPU the last 2-3 years! As long as I can use the same shaders and lights, I´m way more willing to overlook differences in the final look, and knowing where the differences actually are, will help to decide wether to even start a project on GPU.

As others have mentioned...knowing wether a project will fit into Vray for example, when starting out, is often impossible to predict.

If you have some more testscenes you can show us to point out differences between Vray GPU rendeirng and Vray Production rendering, I´m sure more people would be interested in it though!
The threshold of what is acceptable in look differences is just very subjective and relly depends on the type of project you are working on.