Vray DBR submission

Deadline
1

We have started using the Vray DBR submission tool in max 2014 and our users are noticing that it seems to cause regular slow downs in the Max UI.
Is there a reason leaving the DBR window open would cause this?

Our artists would like be able to keep nodes reserved for their use for periods of time as reserving them can take a while.

Any tips or hints.

thanks,

2

Hi,
Unfortunately, this is a known current limitation as maxscript doesn’t handle threading that great. We are looking at ways to improve this, but it’s a bit out of our hands at the moment, as it’s a maxscript limitation. If you didn’t use the in-app submission UI, but submitted a VRay DBR for 3dsMax job via the monitor, it would still reserve slaves for a DBR job, but you would just need to manually type in the machine names/IP addresses into the DBR UI in 3dsMax. At least, this wouldn’t ‘lock-up’ 3dsMax and let artists work normally. ~Annoyingly, Maya & Softimage VRay DBR python ‘threading’ work just fine…and 3dsMax 2014+extension onwards, now has Python…[hence my first comment :slight_smile:]
Regards,
Mike

3

Hey Troy, the reason it slows things down is that the DBR submitter is pulling Slave information continually. I’ll ask Ryan if it’s lag in the polling for Slave data, or in parsing it. We might be able to speed things up if it’s the former.

Edit: Talked with Mike, we’re already being as efficient as possible.

4

Fantastic info. I will see what we can figure out on our end about the manual submission. I have a feeling it will be cumbersome to manage that way for the artists.

thanks for the info!

5

I wonder if we should add an option to disable automatic updating of the UI, and then add a button that can be used to manually update it.

6

I would love for the artist to be able to tell it to stop polling once they have the nodes they need.
I just did a survey of our users, this studio is new to deadline, and the only thing negative was about how DR was handled for vray.
And this frustration was universal.

I know I have brought it up before but our ideal state is:

We have say 20 nodes in a DR pool
Say I have 10 users
user 1 submits a DR task and no one else has a DR task, that artist gets all 20
then user 2 comes along and submits a DR task, as the next 10 buckets on user 1’s job finish they go to user 2
then users 3-10 come along and the nodes get divided up 2 to a user.

Right now there is so much coordination required to manage the DR process it doesn’t scale well at all.

I am open to any suggestions about how to manage this and appreciate any advice.
We attempted to look at tile rendering, but with light caching coupled with the lack of visual feedback for the artist it didn’t really work for us.

7

one more question was just raised over here.

when the user closes the Vray DBR script window can you guys make it turn the DR checkbox off.

vray DR.JPG
vray DR.JPG456×729 68.1 KB

we think what we are seeing is that a user opens the DR script reserves the machines… completes the DR task. Closes the DR script window then if they hit render again its trying to DR still but deadline may be “unaware” of this stealth DR task and if another user has a job setup and the spawner process is running the user who is now outside the deadline system can then “steal” those nodes that another user has reserved?

is this a possible condition or I have misinterpreted what I am seeing here?

thanks,

8

Hi Troy,
Once a DBR job is completed in Deadline, the VRaySpawner exe is no longer running on those machines as the process is spawned as a child of the previous job on that slave and as that is no longer running, there is no way that the vrayspawner exe is still running via Deadline. We recommend NOT installing the vrayspawner exe as a background service or running it in normal, GIU standalone mode, as we are unable to ‘hook’ onto it as part of the Deadline DBR job and I also believe studios will have greater control, if they can spin up and kill off the vrayspawner in a JIT (just-in-time) style, so it can never conflict with any ‘normal’ jobs going through the Deadline queue. I also believe it’s really useful to have this child spawned approach, as we ensure everything gets cleaned up after processing, including the Max file/application, which can sometimes be left in a dirty state and not close correctly. The key thing is, we want to step in, do some DBR and then when we exit, we leave your slaves in a good state, to continue processing.

I think this is just a case of our submitter, turning the DR checkbox on and it’s left on, after the user has finished with DBR via Deadline. The thing is, it might have already been turned on, before the DBR UI was opened, so we should query the setting and store it, so we can restore the setting when the UI is closed…perhaps?

All feedback is good :slight_smile:

9

As always you guys are great!

I have passed this along to some of our artists to get feedback.

thanks so much for always answering our, at times, silly questions!

10

here is the feedback from one of our artists

As far as I know the spawner has never been setup as a service and has only ever been manually turned on prior to deadline being adopted. The only thing I can think is if someone turned DR on manually and never turned them back off
All I can say is that after DR I closed the DR window and hit render in max to do a local render and gotten 1 to 2 DRs on two different occasions. The only thing I can think is that the spawner is still on otherwise it could never connect to it since it’s a v-ray thing not max or deadline. My best guess is that there is a DR job in the queue for someone else. I exit DR, it drops those machines and the queued job picks them up. My DR is still checked and I hit render in max. V-ray tries to dr to those machines in my list. If the spawner is running regardless of what deadline is doing or done, it will render. There is a rare specific condition where this occurs it seems. If it occurs again I will get your attention to witness the event.

-d

11

any word on adding this feature? I dont know what kind of time frame we would be looking at but my artists would be super happy to have this as now the max UI keeps stuttering as long as they are running the deadline DBR script and it makes them craaaaazy…

thanks so much!

12

This was added in the 6.2 beta release that went out earlier today, so it will be included with the final 6.2 release.

Cheers,
Ryan

13

You guys never stop being amazing to work with!!

Is it possible to use the vray dbr script from the beta with deadline 6.1?
If so how can I get ahold of that?

14

Unfortunately, the script has gone through some changes that require it to run against Deadline 6.2, so it won’t work with 6.1. We’re still accepting beta requests though, so you can shoot an email to beta@thinkboxsoftware.com to get access.

Cheers,
Ryan

15

Any word if this is something that can be expected in the future?

16

Sure thing. I’ll add it to the wishlist, as we will want to add this same feature to all 3 x of our VRay DBR UI submitters to keep them consistent :slight_smile: