All posts related to V2
Hi, I have a scene with two characters going around in a small pool. Not really much going on, but there are some displacement maps, RF mesh and hair used in the scene.

When I try to render out a sequence on the local farm (4 mac + 1 pc), there seem to be a random order in when a computer actually get past the "preprocessing data..." and when a computer "just hangs".

So, if I send a sequence on 10 frames, computer A will render frame 01. But maybe hang next time the same sequence is sent. So I find it a bit hard to problem solve it, since I can't see the logic in why it does not "random" work.

Any tips to how I should investigate it further/better?

Here are all the logs: ... t/
The two Mac´s is rendering as normal, but the Pc is just hanging in "preprocessing data". Maybe the logs can shed some information?

Best regards,
Tor Martin
I think all the machines have above 24gb in ram. Just tried to render it again, and then the PC rendered just fine but one of the mac´s froze in "preprocessing data..." state.

So it seems its quite random.

Yes, there is no motion blur - I add that in post.
Yes, tried to render an image on the PC. First time it stopped on "preprocessing data.." Second time it also stopped. Could it be something in the scene that create trouble.

Its just so strange that I have some frames that renders out with no trouble..

Yes, I am also sending dependencies to each computer. So all the files should be local. Have seen in each computer temp folder, and every file is there. Also the .bin file from Realflow is moved to each computer.
if you can reproduce the error rendering local via the gui, then it won't be an issue with sending dependencies or with network at all.

the only time i remember random network crashes like this were with broken image file formats.
i think some odd tiff format that sometimes crashed the process. but that is some time ago.

if it starts to render.. is it actually looking ok and how is ram consumption?
I have left work for today, but the rendered images looks as supposed. So when it do render, it render nicely.

Did a new test with only Mac's (4). All rendered the first frame. Now I see that three are stil rendering and one Mac has stopped at "preprocessing data"

I'll do some more tests over the weekend, but the preprocessing takes quite a while. But I guess is has something with the realflow mesh.

I think the ram consumption is normal I.e what you expect with Maxwell. But I'll check it out next time I am infront of the computer again.

Thanks for your thoughts!
I wonder if the node freezes up or if the network monitor is not responding. I have left animations to render overnight, and when I arrive in the morning, the monitor shows that render progress has frozen, but all frames have been rendered and saved.
That depends entirely if you use Send textures or not. In case you don't use this option, then yes, the other nodes need to have direct access to the folder where you keep your textures/ior files/anything else needed to render the scene (so when you add the job, you need to specify the "dependencies path" parameter using a network path: \\mycomputername\mytexturefolder). In case you do check "send dependencies", then the Manager will handle sending the assets to each node.

Kevron, if possible, do a pack & go of the scene and send me the files. Email is in the button below my post.
it happened to me too, but I've found that always the reason is that some of the geometry got corrupted somehow (in Maya).
I usually have to "scan" the scene in parts, and find the bad object and it's fixed.
I guess it is the RF mesh that is making some problem. I have rendered out a short film without any large hiccups, and the difference between the short and this little project is basically two RF mesh objects.

I´ll do some test with and without the mesh.

Thanks for all input!

I'm writing a converter for curves from Houdini to[…]

Free HDRIs for everyone

Thank you!

Hi Guys... Just updated Rhino to Maxwell plugin V[…]

SketchUp 2021 Update

Hi there! Sorry, it is the obligatory post relat[…]