Problems in Distributed Rendering of VfS Release Candidate

[cattt]

First appreicate you guys working so hard on putting DR in the pack.

With little wait, I put the test into practice yesterday. However, I guess there are still problems to be solved.

1. Material with textures on the client side will not be rendered with it from the server side. At the mean time, the server console tells you that textures required can not be loaded from x:\Document..Settings\NAME\Local Settings\Temp\ ,which is a CLIENT side path where sketchup normally put textures.

To solve this, I copied the textures needed to "Temp" of the server side. The tricky thing here is my path of "Temp" on both machines are exactly the same, what if it hasnt been?

The server really needs link a folder regardless to which side. But personally I prefer a folder on client side, which subsequently avoid frequent texture synchrosization to the server side.

2. When you edited the material a little(like color), the server ignores the change. It still renders its part beyond the change. It seems like a dirty catch problem. The server didn't clear all the catchs before starting a new rendering, although it told so.

To solve this, the only thing I can do is restart the server machine and pray it will do the right job this time.

3. Even you get right on both the problems above. You still get even squares sometimes. Actually, it were sometimes that I get right results.

This is all about what I found. I get really confused now.

[dalomar_cg]

Re: Problems in Distributed Rendering of VfS Release Candidate

As far as the textures go, they need to be in the same path in all locations. This is due to the large amount of information that would need to be transfered if maps were transfered to the slave machines. The optimum setup is to have a network drive for each machine that is the same path. If not you will have to make the same file folder on each machine in order for the maps to be read.

[joe_b]

Re: Problems in Distributed Rendering of VfS Release Candidate

To solve this, I copied the textures needed to "Temp" of the server side. The tricky thing here is my path of "Temp" on both machines are exactly the same, what if it hasnt been?

Yes - at this time the textures need to be at a spot that is accessible to client and slaves.

The server really needs link a folder regardless to which side. But personally I prefer a folder on client side, which subsequently avoid frequent texture synchrosization to the server side.

There have been a lot of suggestions on how to best handle the DR resource sharing. But for the moment making the resources be in a location where its accessible to all is the only option. The problem with having a folder on the client side is that not all networks are setup in such a way that stuff on the client-side is accessible to any other machine.

2. When you edited the material a little(like color), the server ignores the change. It still renders its part beyond the change. It seems like a dirty catch problem. The server didn't clear all the catchs before starting a new rendering, although it told so.

Yes- we caught this a day or two ago and have resolved it in our internal build. It will be taken care of in the next release.

Sorry for the confusion

[jsmith00]

Re: Problems in Distributed Rendering of VfS Release Candidate

...making the resources be in a location where its accessible to all is the only option.

Is there an easy way to assign the material library path in SketchUp for output? I have tried reassigning the path to a directory on the server but the temp folder is where it always wants to look when rendering. I even reapplied the materials from a new exported directory on the server containing all the materials... and it still assigns the path to the same temp directory under the user path. So effectively I keep getting the Bitmap file error on each slave machine when trying to render.

Any help is greatly appreciated...

[cattt]

Re: Problems in Distributed Rendering of VfS Release Candidate

...making the resources be in a location where its accessible to all is the only option.

Is there an easy way to assign the material library path in SketchUp for output? I have tried reassigning the path to a directory on the server but the temp folder is where it always wants to look when rendering. I even reapplied the materials from a new exported directory on the server containing all the materials... and it still assigns the path to the same temp directory under the user path. So effectively I keep getting the Bitmap file error on each slave machine when trying to render.

Any help is greatly appreciated...

As you said, this didn't work.

Before we start, a little context may help. Actually it is the VfS put its temporary textures in "Temp" rather than sketchup native renderer. Simply because if you render a model with it, there won't be any texture files generated in the Temp folder. Plus If you have a look at the folder where sketchup has its native materials, they are *.skm format rather than standard image formats.

So, let's make it clear. The VfS generate the half way texture each time before it start rendering(This needs to be confirmed by the programer however fact that each time just after rendering start, the texture files in temp have been refreshed if you check the creation time).


Then there comes the solution. But I'm sure this is neither a smart nor easy idea.

First of all,have you modified the texture settings or this is the first rendering. You have to make an early termination rendering in the client side that ends just after the new texture were told "loaded". Now we can say the texture files here in the Temp folder is the latest version with which every server could start.

To the server side, please bear in mind that the vray server only accepts an absloute path exactly the same as client side and the path is related to the user name in the OS. So you have to have all the server OS has a sharing user name(I didnt try if MAKE such a path on server side will do, but theoretically I guess so). So "x:\Document..Settings\NAME\Local Settings\Temp\" has to be set around all the servers whatever the way.

Then, I use a file synchronizer(a type of software that synchronzie files between folder and folder, computer and computer) to transfer the texture files over all servers.

Then the rendering are expected running smoothly.

My choice is Super Flexible File Synchronizer. It supports "File Mask" that acted as a filter to keep out of other file types be synchronzed.

As you can see, this method is not smart, still it is a semi-automatical process as long as you just need to push a button to synchorize all the textures. However, IMHO, I do think the developer should solve the DR texture problem rather than leave it to final customers most of which are designers that are not professional at solving IT issues. This is also consistent with the "ease of use" sketchup culture.

[joe_b]

Re: Problems in Distributed Rendering of VfS Release Candidate

Ok - I'll work out a solution that should make it easier on you guys. Thanks

[rv1974]

Re: Problems in Distributed Rendering of VfS Release Candidate

Hi all!
1.Is there a way to save the slave's adresses (may be in xxx.visopt file)?
2.By far we have to wait for cultural solution
of lost bitmap issue?
Thanks

[joe_b]

Re: Problems in Distributed Rendering of VfS Release Candidate

Make sure you have the latest release - in the latest release the render slaves are retained between sessions. Also we added a means of transferring the bitmaps automatically to the render slaves.