drspawner.exe shuts down

V-Ray for Rhino V-Ray for Rhino :: General
1

Hey guys,
looks like I discovered this forum to finally post all the questions and maybe get all the answers I lacked over the past years… :slight_smile:

Recently, we set up distributed rendering and for most operations it’s a blessing. 8)
However, when attempting to process large scenes, drspawner.exe suddenly shuts down when the data is being transferred to the slave computer.
Is there a simple explanation for this? e.g. a less powerful slave cannot cope with the heap of bytes received…
Do I have to copy the scene/maps/other stuff to the slave machine to make it work? Into which folder do those files go?

Your help is very much appreciated!
Cheers,
matthias

2

Re: drspawner.exe shuts down

Be carefull with textures used for multiple objects:

http://forum.asgvis.com/index.php?topic=5887.0

Check the RAM usage at the slave during loading. Look at the process window, what is the last message?

3

Re: drspawner.exe shuts down

I see, there’s quite a bunch of twist-and-tweaking going on
Extracting the rendermesh appears to be the magic bullet, right? :smile:

Here’s my log book:

okay, I checked my scene with your polycount tools, it says:
Found 885 object(s) with 1420575 polygon(s)

Shouldn’t be too much of a problem with my setup. But it could be smaller… let’s see.
After hitting your extract rendermesh button, we’ve got
Found 950 object(s) with 1438630 polygon(s)

?
drspawner.exe still crashes at such an early stage (can’t be much more than five lines in cmd) that it’s impossible to read anything…

I’ve checked the Override materials item in the Global Switches menu and now it renders fast and fine.
Rhino4.exe @master uses 895.000K
drspawner @slave uses 441.000K

Now I can backtrack the last line in cmd where the previous crashes occurred:
Preparing camera sampler…

Now, what shall we do with the drunken sailor?
There’s way too many objects in the scene, I wouldn’t be able to fix all this anymore. I’ll go with the slow single machine rendering option for now and keep an eye on multiple textures in the future.

Are there any tweaks on the VfR Options catalogue to be looked at any closer?

btw: I’ve got all the texture files stored in the exact same location (path) on both computers. this because there’s a backup routine scheduled in the background.

:o gotcha!! :slight_smile:
There’s a material that seems to return an invalid colour (huge negative rgb values) - whatever this means, as soon as this material is removed from the scene, drspawner.exe does not crash any more.

Funny enough, I never create materials that produce such errors. How come it happened at all?

Okay, it’s kinda late around here - See ya 'round tomorrow!

Cheers,
matthias

4

Re: drspawner.exe shuts down

The invalid color bug is reported since a very long time. Details are not known. Some times it seems to be caused by the texture, some times by geometry. But general don’t use grey format images.

5

Re: drspawner.exe shuts down

Alright - this explains a lot.
There’s been different b/w type images in the scene. Even as a reflexion map. Funny enough, I didn’t see this error in all those years before!

Is it enough to open those images in Photoshop and change them from Greyscale to RGB? Or is it mandatory to actually have colour in it?

6

Re: drspawner.exe shuts down

Change Grey to RGB is enough.