I’m checking out alternatives to Backburner at the moment and I’m having a bit of hard time for some reason with rendering effectively with RT CUDA. As it’s very fast, I feel that we’re loosing a lot of time on loading scene etc.
While backburner somehow manages to not unload the scene from RT, keeping the link at all times it lacks functionality of multi-slave rendering or support for multi-user management.
That’s why I’m testing Deadline 7 on 30 days trial, but there is something wrong. As long as it manages to keep 3ds max opened between tasks, every-time frame changes its closing DR session and sends it again to RT from start. That’s very ineffective especially with bigger scenes. I know that this is probably issue with deadline and I have to check with them as well, but maybe there is some other solution to the problem from V-Ray side.
We are actually working on rendering with RT directly inside of 3ds Max, so all of these issues will go away eventually. It won’t be for the service pack next month as there is not enough time to properly test it, but it will go into the nightly builds soon.
Rendering directly inside of 3ds Max will cut down the translation time and will allow us to reuse loaded textures. It will also make rendering a bit faster as the results won’t have to be sent from one process to another.
That would be really good actually. But still, that leaves us with only Backburner as use-able solution at the moment, unless I will start testing other solutions. I just love how it manages to just update frame number, start it, send update to VRay.exe and render it smoothly without restarting the process - http://wyszolmirski.home.pl/screen/screen/2015-04-10\_1336.png .
With deadline after each frame i see ‘closing DR session’ . But I think that’s Deadline issue. It’s talking with max differently I think. Backburner uses named pipe and somehow manages work better. It’s just a shame I can’t run 2 jobs at the same slave via BB.
Anyway. Thanks for the quick response. I will try to find a good solution.
I’ve just setup this free manager cgru.info and it does work quite well so far. In batches of 10 frames it will reset max/vray_RT once every 1 hour for most of the scenes. So this isn’t so bad.
This lets us render quite effectively on GPU (CGRU) and CPU (BB) at the same time. It’s a bit of hustle to set it up at first but after initial battle it just works.
I’m having no luck rendering a simple chalk teapot using VRay RT as a production renderer with Backburner.
Is there something Im missing?
The scene renders fine on my workstation using Quadro 4000 but when I send exactly the same file as a network job using Backburner, the job launches but VRFB is black and the rgb render also black. Alpha is there.
I’d really like to use RT to produce animations, using mulitple machines so I don’t have to lock up my workstation during the day.
I only have 1 max licence so can’t leave it running on another machine.
Thanks for your quick reply.
In this case I was just closing down max on my workstation and starting the ‘server’ application on the same workstation.
(Backburner Manager and Monitor also both running on my workstation just to test the workflow).
I just tried both CPU and CUDA from within max and they rendered fine - but when sending as a Backburner network job, the frame buffer opens, shuts down quickly (I see the progress bar move much faster than normal), then the render job stops and saves a load of black frames for each render element.
The scene is simple - teapot on a plane, chalk override material, 1x vray plane light
I am using Max Design 2014 with vray 3.00.05 - Win 7 x64
i7 3930K (not overclocked) Quadro 4000
Would it be possible to send the scene for investigation even if it is very simple one?
Let us know also what steps we must follow in order to reproduce the issue the same way as you did in your environment.
We’ve done a couple of test here but we couldn’t reproduce the bug into our environment.
Open the .max file
Render the camera viewport locally within max using RT either CPU or CUDA -- works fine.
Send exactly the same render using Backburner -- renders black
Using Max Design 2014 SP5 with Backburner 2015 (since 2015 is installed it overwrote Backburner 2014)
Thank you very much for the attached scene - it helped us a lot to find where the issue lies.
It seems that there is an issue with the Standard Camera when rendering with RT via BackBurner, V-Ray Physical Camera works fine fortunately.
Almost there ! -- using the VRay cam has solved the issue when rendering to my workstation.
BUT - when rendering using the render slave I get the following issue:
RenderSlave, using RT with CPU (Sent as a Backburner network render) - first time the render starts (I see the teapot in the vr framebuffer) but does not complete and Backburner server ‘hangs’
I then restart Backburner server, the network job starts again and it renders fine !?
RenderSlave, using RT with CUDA (Sent as a Backburner network render) -vr frame buffer remains black (max launches ok, vray starts but nothing happens)
The render slave is basically the same as my workstation- i7 3930K with a Quadro 4000
I remember reading somewhere about vray DR not liking Remote desktop (which I am using to view the render slaves) - could that be the problem?
IF it is - how do you suggest I log in to my slaves?
Many thanks again, Thomas
Yes, there is known issue with the usage of RT GPU via Remote desktop. Instead try using TeamViewer or VNC.
RT GPU (CUDA) works fine with VRayPhysicalCamera on our side.
And thanks to you both - the problem is now SOLVED.
For anyone wanting a quick summary of what worked for me:
When using Vray RT to render animations using Backburner.
1) Use a Vray Physical camera (not max camera)
2) Don’t use Remote desktop - I used Teamviewer and both CPU and CUDA seems to work fine.
NB -- install Teamviewer on your render slaves as a service otherwise it wont work properly.
3) Update your Quadro driver - mine is now version 348.07 (older one crashed vray when using CUDA)
Now the challenge is just to get my GPU renders looking like my CPU ones!
