We have a number of students using the Rhino 5 Beta and want to provide a straightforward rendering solution (one that doesn’t require saving down to Rhino 4), take advantage of the 64-bit capability, and generally, test now what we’re going to face when the release becomes official. The problem we’ve run into is that under Rhino 4, and I’m not a programmer so this may not be the correct term, the V-Ray for Rhino render window was modal so once the Deadline script in Rhino.py fed "Render " to the Rhino command line and those windows launched, the Rhino command line became inaccessible; following the completion of the render the command line was again available and "-SaveRenderWindowAs " could run, saving the results. Under Rhino 5, rendering is spun off to its own thread and the Rhino command line is almost immediately available – “-SaveRenderWindowAs” runs as soon as V-Ray has popped up a window to save and the results are 1K files that, as far as Deadline is concerned, are “completed”. Is there a solution or approach to take with this?
Unfortunately, we haven’t done any testing against the Rhino 5 beta, so it’s difficult to speculate what the problem might be. It sounds like they’ve changed the way the command line interaction works. Have you tested with the standard Rhino renderer to see if the same problem occurs? Perhaps the problem is specific to VRay…
Cheers,
- Ryan
It is V-Ray 1.5 – when we installed this version for Rhino 4 (strictly speaking, we’re running the Demo version – we don’t want to convert our license until we know where we stand with this) we got the same result; you should be able to reproduce it if you have Rhino 4 around. Because the Rhino version has been among the last in the V-Ray family to get upgraded, is there anything that can get recycled from the approach to 3ds Max or Maya, since they’d have been multithreaded earlier? I was looking through some of the pieces in the Advanced Plug-in code examples and functions and the standalone V-Ray plug-in and it looks like there are tools to get at pop-up text (to regex the “render completed” statement), which would provide some way of knowing when the rendering was finished. Not being a programmer, it’s just not clear whether these pieces can all fit into something (yes?) that would work. Assuming you’ll see the same behavior with V-Ray for Rhino 1.5 (which is now the only version you can purchase), it looks like this problem is knocking on the door. What do you think?
Interesting. So this is sounding more like a VRay specific problem.
The way we interact with Rhino is through the command line:
wiki.mcneel.com/developer/commandline
When we call the command line, we pass in all the commands we want to execute in their proper order. For example:
"c:\Program Files (x86)\Rhinoceros 4.0\System\Rhino4.exe" /runscript="_SetCurrentRenderPlugin ""V-Ray for Rhino"" _Render -_SaveRenderWindowAs ""R:\output\test.jpg"" -_CloseRenderWindow -_Exit" "R:\scenes\test.3dm"It is then up to Rhino to process those commands in order, with the assumption that a command won’t execute until the previous one does. Deadline doesn’t interact with Rhino while it’s processing these commands (other than watching stdout), so there isn’t anything Deadline can really do if the _Render command for vray isn’t a blocking command. To me, this sounds like a VRay bug, since it breaks the ability to batch render, and it also behaves differently from the other Rhino renderers.
We’ll see if we can get in touch with someone from the VRay for Rhino team about this, but it would probably be a good idea for you to report this to them as well.
Cheers,
- Ryan
I did put something in the Chaos Group V-Ray for Rhino “General” support forum over the weekend, citing pretty much the same thing:
A Rhino command line sequence using V-Ray for Rhino prior to 1.5, such as:
“c:\program files\Rhinoceros 4.0\system\Rhino4.exe” /runscript=“_SetCurrentRenderPlugIn V-Ray for Rhino render -saverenderwindowas test.jpg closerenderwindow -exit” hdri_test.3dm
(e.g. wiki.mcneel.com/developer/commandline)
would launch a render and save the result, the success a result of the render window being modal (correct term?) so that the -saverenderwindowas command could not execute until the rendering was finished. With V-Ray for Rhino 1.5, the render window is no longer modal, the “-saverenderwindowas” command executes as soon as there is a render window to find, and the result is an incomplete 1K file.
This command line approach is one that renderfarm applications use to submit jobs but it’s not clear now how a scripted approach would be able to determine when a rendering had finished and so execute a save sequence at the appropriate point. This is probably not the only multithreaded version of V-Ray (it’s the only one we use) and V-Ray seems to be a commonly supported renderfarm application (e.g. for 3DS Max); is there an approach to this?
It’s not clear whether they’d think of it as a problem, and whether this is what they mean when they say “Fully multithreaded raytracing engine”. It’s always been the case that it would use all the cores available, so in that sense the old version might have been considered “multithreaded”; it’s new in the sense that you could now continue to work on the Command line while your render was running and perhaps this is considered a “feature”. Again, because the Rhino version seems to be the last one that gets updated in the V-Ray family I’m puzzled about whether this had come up in Deadline before with other V-Ray family members (V-Ray for 3ds Max, V-Ray for Maya).
This hasn’t been a problem with VRay for other applications. In Max and Maya, the command that starts the render doesn’t return until the render is finished.
I guess I could see the _Render command returning immediately being useful when manually interacting with the Rhino command window, but it’s definitely not a useful “feature” when batches of commands from the command line. 
Can you post the link to the thread you started on the VRay for Rhino support forum? I would like to follow the thread.
Thanks!
- Ryan
The problem turned out to be mixing V-Ray for Rhino versions. We had some test files that were created using V-Ray 1.5 that we were running under V-Ray 1.05 (our student environment has both 1.05 and 1.5 users so we were looking at both) – according to Chaos Group, this doesn’t work. Because it almost works in standalone operation (files don’t crash, Options selections appear normal, files find materials), and because we didn’t do a good job of tracking the history of our test files, we ended up with these 1.5–>1.05 conversions and odd things happened. V-Ray for Rhino 1.05 files will render successfully under V-Ray for Rhino 1.5, according to the Chaos Group, but you can’t go the other way.
We were still running into problems when rendering files created with the previous version of V-Ray for Rhino (1.05.29) under the new/current V-Ray for Rhino 1.5 until we implemented a suggestion one of the senior members in the Chaos Group forum made – add a -_Loadscript parameter to the Deadline command sequence to load an .rvb file that forces “Batch Render” to be set to “on”:
Option Explicit
Dim vfr_object
Set vfr_object = Rhino.GetPluginObject(“V-Ray for Rhino”)
vfr_object.SetBatchRenderOn True
It wasn’t obvious that this was the problem. When we manually opened a 1.05 file, where “Batch Render” had been set to “on”, under 1.5 it still showed this setting was “on”. The same file would also render normally under 1.5 if it was run interactively from Rhino. The only situation where it failed to render was if it was run using the Deadline (McNeel) command sequence. By adding the -_Loadscript parameter to the Rhino.py command, though, the file processed normally and we can now submit files to Deadline from either version of V-Ray for Rhino.
We hadn’t found any other way to get a file that was created under V-Ray for Rhino 1.05 to render under 1.5 via script (ie. by Deadline) so this suggestion from the Chaos Group forum might be useful to incorporate somewhere in Deadline.
We’ll do this for Deadline 5.2. We had a test scene we could reproduce this problem with, and confirmed that the script resolves the issue.
Thanks for sharing this with us!
Cheers,
- Ryan