render farm setup - vray standalone

[brobins]

Hi there,

I am in the process of setting up a new render farm for the studio and have a few questions regarding vray standalone.

As a studio we use both 3ds Max and Maya with vray cpu (mainly).

In my mind, a vray standalone setup would be the easiest to setup and maintain but the draw backs seem to be around some of the limitations to do with what is exported (or not) from 3ds Max when creating the vrscene files. I am wondering what the best workflow is for ensuring that 3ds Max scenes are setup with plugins / nodes that are supported with vray standalone? Currently we have the Analyze tool on the exporter in Max to list what is showing up but I think there is more to it. I remember something to do with animated key frames not being 1:1 too?

Like I say, my ideal is that we use vray standalone for rendering on the farm but I would like to ensure we are not getting surprises / differences in what the guys see in Max and what the farm spits out.

Interested to hear any thoughts and suggestions.

Thank you!

[Morbid Angel]

In my many years of experience we always found that standalone rendering was much more taxing and troublesome then direct rendering. Even to this day I have scenes export to .vrscene from max and don't work some times when rendering from maya. Our farm is setup with 3ds max vray and Maya vray, and this seems to be best bet. You will always run into issues caching frames, large frame sizes besides all the other potential issues.

[Joelaff]

Standalone can indeed be a big pain, but we have been using it more and more lately because it makes it much cheaper for cloud rendering in Linux vs windows.

We have been on a large project requiring a lot of rendering beyond our local farm (like a ton). In order to not break the bank we have been using standalone. The export times and file sizes are an issue, especially with things like Forest Pack, where it is almost unbearable.

Keep in mind that procedurals render differently between Max and standalone. So you may not be able to intercut footage that way. If the procedurals are used for displacement then you can’t even intercut matte passes.

The VrayPluginNodeTex and VrayNoiseTex do render the same. So do yourself a favor and use those from the outset.

PhoenixOceanTex renders slightly differently between Max and standalone. I reported this, but it was already known and in the list to fix.

There’s are some bugs I have reported (and support reproduced) involving MultiMatteElements when using include/exclude to select object names (as opposed to MatId or ObjectID). This is especially the case of your objects have displacement. So don’t use those.

Modifiers that change geometry every frame will make for very large vrscene files. As will simply having a ProOptimizer in your stack with a large object.

If you run into any issues at all REPORT THEM. Standalone is much less tested than rendering from Max. These bugs need to be reported so they can get fixed.

Tyflows can increase vrscene sizes. Try to use chaos tools when possible (VrayInstancer, or PRTReader from Phoenix (not the Loader from Krakatoa), or PRT files loaded into the PHX simulator). You can also export things to Alembic orvVrayProxy and load with VRayProxy nodes. By exporting things you can reduce your vrscene sizes and export times, not having to export those over and over for every renderer.

[brobins]

Some great advice there so thank you.

[Joelaff]

BTW, I may have been wrong about Alembics being reference externally. I am currently getting giant vrscene files due to them being embedded in the (very space-inefficient text based) vrscene file. I should have used PRT or VrayProxy...

[Joelaff]

Converting the Alembic, which was being embedded to PRT loaded with PRTReader took the vrscene file from 7GB to 300MB.

You have to constantly watch for massive vrscene files. This is one of the biggest time wasters.

[Morbid Angel]

We deal with giant caches a lot from houdini. In houdini there is a way to link your ifd cache to your existing bgeo caches (ifd is like vrscene). I think there should be an option to do that in vray scene export.

[Joelaff]

We deal with giant caches a lot from houdini. In houdini there is a way to link your ifd cache to your existing bgeo caches (ifd is like vrscene). I think there should be an option to do that in vray scene export.

You sure would think do. I can't find any such thing, and due to the difference in vrscene file size, the Alembic is definitely being embedded, and we are literally only using it for particles. The PRT is working great of course. (I asked the Houdini guy to export as PRT, but he had trouble and went with ABC instead.)

We are in Max, BTW.

[dougWilkinson]

heya. this thread is interesting for sure. I'm hoping we can switch to a vray standalone workflow to bring Maya/Houdini/C4d into a common workflow. Its going to be a challenge for sure. The cost savings when cloud rendering on Linux is a huge modivator!

it seems like loading alembics via vray proxy might be the best way to keep the them from being baked down into the .vrscene

Did either of you make progress?

[Joelaff]

We used the techniques described above. It is still a cumbersome process, but it can be done. Never did nail down exactly when or why some Alembic data (particles at least) were being embedded, but PRT solved the issue as mentioned above.