Updated June 20, 2016 – Brian from the V-Ray forum has a couple of additional features that are not supported in exporting vrscene files from Max which I’ve added to my list below.
My post about using VRay with a Linux render farm has turned out to be easily my post read post, so it’s obvious I wasn’t the only one trying to figure out this combination. That post was written before V-Ray 3 came out, so it’s time for an update.
V-Ray 3 adds a number of new features that have been covered elsewhere, but it also added some less publicized capabilities when rendering on a Linux render farm. The changes break down into two main areas – licensing changes and technology changes.
V-Ray 3 licensing changes
V-Ray 3 is no longer free to render on as many machines as you like as it was in the <=2.x days. I was always amazed they offered that in the first place, so even though it was a great help when rendering on a big farm, it was probably an inevitable change. As I briefly outlined in the last post, this change makes the prospect of using a Linux farm more attractive.
In the past it basically was a tradeoff between spending money on the OS (Windows) and getting V-Ray nodes for free, or spending money on V-Ray Standalone nodes and getting the OS (Linux) for free. Now you can’t get V-Ray for free, so you might as well get the OS for free.
All of the other advantages to Linux are still true, it’s a much more flexible operating system. You can install it to a flash drive (no more hot and power hungry hard drives!), completely avoid a GUI which saves a lot of memory, it seems to render about 10% faster than Windows machines, software updates are easier and can be automated with programs like Puppet or Chef and more.
All other things being equal (which of course they never are – keep reading), it’s an obvious choice. For anyone considering rendering with a cloud service, the benefit of using Linux is even more obvious. As of right now (June 2016) Amazon charges $1.68 / hr to render on their fastest machine type with Linux, and $3.008 to render on the same machine with Windows.
V-Ray 3 technology changes
For those interested in using Linux for the render farm, the news here is good too. The main challenge in the past was the exporter that created .vrscene files for rendering on V-Ray Standalone. The 2.x exporter had a number of glitches that had to be worked around using either scripting or at worst a few minutes in a text editor for each export.
The .vrscene exporter in V-Ray 3 isn’t perfect yet, but it’s a lot better. Here’s a rundown of what I’ve found works, and what doesn’t in the exporter:
Working with V-Ray 3 .vrscene exporter
These are some of the things I was worried might not work but found that they do:
- V-Ray Dirt material in an ExtraTex render element. (this was not working in 2.x)
- V-Ray Multimatte elements (this was not working in 2.x)
- V-Ray Light material
- Multimatte + material IDs (this was fixed in the 3ds Max 3.4 plugin)
- Forest Pack Pro objects (see exception below)
- 3ds Max physical camera
- Distributed rendering with a Linux / Windows standalone host to a Linux / Windows standalone slave. Rendering from a 3ds Max host still can’t connect to a standalone slave.
Not working with V-Ray 3 .vrscene exporter
These are the things not working yet, along with the .vrscene code you need to add or modify to get it working. That can be done automatically through something like Python or Maxscript, or manually with a text editor.
- V-Ray toon atmospheric effect
-
SettingsEnvironment renderEnvironment { . . . environment_volume=List( toon ); . . . } VolumeVRayToon toon { lineColor=Color(0.0, 0.0, 0.0); widthType=0; # or 0 for pixels width, 1 for world units width lineWidth=1.5; opacity=1.0; hideInnerEdges=0; # or 1 to hide inner edges normalThreshold=0.7; overlapThreshold=0.95; traceBias=0.079; doSecondaryRays=0; # or 1 to trace reflections / refractions excludeType=0; # not sure how to exclude objects compensateExposure=0; # or 1 to compensate for camera exposure }
- Deep images and embedded render elements for exr output can’t be setup directly. You need to add some text to the .vrscene file in the SettingsOutput section to render deep images.
-
SettingsOutput xxxx { . . . img_deepFile=1; # this enables deep images img_rawFile=1; # this enables embedded channels }
Multimatte material ID does not work, but multimatte object ID does work– this was fixed in a recent release (3.4 I think) so if it’s not working for you, upgrade to the latest 3ds Max plugin version!- Animated image sequences do not work. We are using them in V-Ray Mtl shaders and also in ExtraTex render elements, both of which are broken
- Gradient Ramp texture does not export
- Forest Pack Pro objects with V-Ray Properties don’t include the V-Ray properties. For example if you want to set the trees of a FPP object to be matte, you should use a material wrapper instead of setting the V-Ray properties on the component objects or forest
- Exporting large animations can be kind of slow. It’s usually not a problem, but a recent scene at Hypothetical was taking about 30 minutes to export and generated a 6GB file. This scene had animated trees that had to be collapsed down to a separate mesh per frame, so it’s somewhat of an extreme case. I’ve seen on the Chaos Group forums that there will be .vrscene standalone support coming in 2016 (similar to X-Ref scenes except with .vrscene, so for parts that are finished you could export them once and reference the vrscene file to save export time)
Conclusion
V-Ray 3 is a big step forward for cross-platform rendering. A lot of export glitches are resolved and I’ve noticed as new features are added to 3.x updates they consistently export correctly to render in V-Ray standalone. With the additional of V-Ray for Nuke which can load .vrscene files, hopefully Chaos Group will continue to maintain and improve the exporter.
If you have any experiences with the combination of V-Ray on Linux and 3ds Max, please let me know in the comments!
3ds Max + VRay Standalone is not as terrifying as you think | Hypothetical
June 15, 2016 @ 1:28 pm
[…] I have a new post up that updates this information with the latest in VRay 3.0! […]
Strob
August 29, 2016 @ 8:20 am
Hi,
very interesting!
And what about plugins? Max always needs a lot of plugins to do everything. Hair fluids, particles, krakatoa, bercon noise.
I know we can bake everything related to mesh or animation or texture and we can also use VDB for volume. But what about particles?
Can vrscene bake on the fly stuff like animated mesh with changing topology?
Eric
August 29, 2016 @ 9:45 am
I don’t know for sure about the particles but I think it would work. The catch would be that it would be exporting the mesh at each frame and that could make the exported file huge and also very slow to complete. That was a problem for me when exporting animated trees from GrowFX.
Plugins are a stickier issue. I think – but don’t quote me on this – that the plugin maker would have to build a version of the plugin meant for Vray standalone. Then the Vray exporter in Max would have to know how to export the data in the proper format. That seems like a big burden for the developer for what is likely to be a very small number of potential customers, but I suppose some might do it.
If you do any experimentation I’d love to find out your results!
Strob
August 29, 2016 @ 10:32 am
Thanks for your answer. I’m a long time max user but I’m also slowly but surely switching to Houdini and Blender. Making max work in Linux is maybe more work than learning Houdini and Blender.
Then there will be the Zbrush problem. We have to convince Pixologic to make a Linux version.
Eric
August 29, 2016 @ 1:25 pm
Yeah, it would be nice to be able to switch over to Linux completely but I gave up on that a while ago. Too many programs are still Windows only or get better support for Windows. (UE4, Max, the list goes on)
But for specialized tasks like rendering I like it a lot!
Strob
August 29, 2016 @ 8:25 am
I just saw that Vlado said on the forum that MultiMatte based on material IDs should work fine in V-Ray 3.40
Eric
August 29, 2016 @ 9:36 am
Good catch! I’ll update the post to reflect that. Thanks