DR Connection problems

[aclark]

Hey guys,

I am trying to crunch some very large and complicated interior renderings and I need my DR to make it efficient. For some reason, the connection keeps getting reset, as well as runtime errors. Has anyone run into this before, and if so, any resolutions? I am running 1.05 and have 10 slaves.

[gallystops]

Re: DR Connection problems

I too have run into a similar problem.

the slave computer receives it then crashes...

-gallystops-

[mjm223]

Re: DR Connection problems

I've run into this problem with one of my slave computers, but I believe it was because it was connected to my network via remote access.

Is this the case with your slave computers? Check to see if your slave computers can take the exact same path from start to finish to get to the folder that has your texture and material images as the host computer.

[aclark]

Re: DR Connection problems

Can you expand on what you mean by connected to the network via remote access? I am running slaves on my companies network. The slaves are not directly connected to my machine and I have been using the network to link them. I have all my materials stored on a shared network location that all the slaves can access. I have pulled this off several times before, but for some reason, with these interior renderings, I am having problems. It may be the complexity of all the materials, lighting, and geometry but I can't know for sure. Could it be as simple as network latency? I noticed in my progress window that each of the slaves timed out and stated "ping not received". I am trying to convince IT to dedicate some machines for me to be directly connected to, but I have to prove the network is the problem. Any suggestions?

[mjm223]

Re: DR Connection problems

I have a group of computers in the office that are all on my company's network. They all work just fine as render slaves because they're all connected to the network the exact same way. All of my textures are saved in a shared folder that can be accessed by all of the office computers using the exact same path (R:/Library/V-Ray/Textures/...)

Now here's where the problem starts. I bought a new laptop recently and I connected it to my network via remote access. Because it's connected via remote access, it has to take a slightly different path to get to the same shared folder that all of the office computers can access. Instead of taking the "R:/Library/V-Ray/Textures/..." path it has to take the "SSANET/R:/Library/V-Ray/Textures/..." path (i.e. my laptop has to got through my company's SSANET access point first before going through all the folders.)

So when I start a render on one of my office computers and set up my laptop as a slave, my host computer will tell my laptop to take the "R:/Library/V-Ray/Textures/..." path to get to my textures. Since my laptop can't take that path without first going through SSANET, it doesn't know what to do. So it posts that error message that you've gotten, then it crashes.

I've also been meaning to get my IT to fully connect my laptop to the company network so that I can use it as a slave, but he only comes to the office if a computer explodes or something.

I hope this clears things up with remote access. Usually computers connected in this way have to go through an access point (in my case, SSANET) before accessing the folders on a network. Since VfSU's DR Spawner heavily relies on computers being able to take the same path to a shared folder, this causes lots of problems.

[mjm223]

Re: DR Connection problems

I just noticed that you said you had 10 slave computers. VfSU says you can have up to 10 slaves, but I've been hearing that a lot of people have been having problems when they have that many set up.

Have you tried reducing the number of slave computers? It might be worth a shot.

[dkendig]

Re: DR Connection problems

the pathing issue you described should be able to be resolved by simply mapping a drive to a folder on your network. So on your laptop, just map SSANET/R:/ to be R:/ Then the path shouldn't be different from one machine to another. If that's not possible, then you have an odd vpn, and that's a shame.

[aclark]

Re: DR Connection problems

Marcus,

Thanks for the input. The slaves are not connected through remote access and I can see how that would be a problem. As far as the textures are concerned, does it matter if you are using a defualt SKP material, which is normally mapped to your local hard drive? In your case, do you ever use SKP materials from the default library? Currently we have sketchup setup so that each machine has it's own local library for reference, but it has dawned on me that it may be better to relocate my default materials to a shared network location, then open that library instead, save as my default template so that I will no longer refernce local materials. Is something that anyone has done or run into problems with?

I have also tried pairing down my slaves to only 4, and I am still having the same problems.

[mjm223]

Re: DR Connection problems

I have had tons of issues with using default SketchUp materials because of that whole C: drive issue. As a result I ended up copying the entire library in my shared folder as well. And I never edit the material in SketchUp, that just causes more problems. Instead, I edit the material in Photoshop and give it a new file name to add to my collection.

Hmmm, even with just 4 slaves it's still not working? Which asset collection mode do you have enabled? "Send to shared Folder" or "send to each node?" I've had some success with the "send to each node" option.

[dkendig]

Re: DR Connection problems

DR has been rough in the latest version. I think the latest beta might be showing signs of recovery though. We might have nailed it in this last build. We're waiting on feedback from testers before we know for sure. If anyone's curious and would like to try it out, you can sign up for beta testing here: http://forum.asgvis.com/index.php?topic=7679.105 <== The Mighty Bug Hunt! Otherwise, hang in there a little longer if you can. We are getting closer to a stable patch every day.