Hey guys!
Today I have started to play around with the latest downloadable preview version of crowd render with Blender 2.90.1.
Besides a few hick-ups with connecting to the node or syncing I got it working to render via network.
Now I am facing the old problem of how to handle the baked data on the node: I get no fire or smoke rendered to the node's tiles. Workstation tiles look perfect.
I thought this should work:
On my workstation client
I have got all my projects on E:\Blender-Projects\ and
and the folders for temp and caching: E:\z_blender-sysfolders\temp and E:\z_blender-sysfolders\caches. Not sure if that's necessary to be honest. The paths have been entered in the preferences of both Blender installations (workstation and node).
This folder is shared on the network and and my first (and currently only) node can access it via the same drive letter E: so that Blender
can access all project assets and subfolders no matter if addressed relatively or absolutely and
also access the temp and cache folders on the workstation client as if they are lying there physically.
But still when I render from the workstation via crowd-render I still the same, Blender on the node can't seem to find the metaflow bake cache folder named "cache_fluid_4b85f272" and does not render the flames and smoke.
Rendering on the node manually opening the project file from the shared drive E: works great - all is being rendered.
Can anybody help me to what I am missing and how to make Blender on the node(s) to find the baking cache subfolders?
Thank you!
Thomas
Hi Thomas, ok, I think the issue is setting all paths relative. I'll try to explain (might help me understand this better too!)
Ok, so lets say you have a file on your E: drive, lets take a hypothetical file called fluid.data which I'll pretend is here:
E:\cache_fluid_4b85f272\fluid.data
With absolute files, blender will store the path to this resource exactly as above. When crowdrender does a render, it uses a background process of blender to render a tile.
So crowdrender starts blender, then blender gets all the resources it needs to render, it looks for
E:\cache_fluid_4b85f272\fluid.data
and then uses this file, and you get your fire.
If you set paths to relative, on the client things still work, blender stores the path like this
\\cache_fluid_4b85f272\fluid.data
which gets translated to
E:\cache_fluid_4b85f272\fluid.data
Since this is where the blend file is located. Relative paths are translated by prefixing them with the path to the blend file. Since the blend file is in the same directory as the cache_folder, which is on the E drive. Just the drive letter is prefixed in this case.
Now, what happens on the render node is different, and the reason why your fire doesn't show up there. On a render node, the blend file used is NOT on the E: drive. It will be stored here
C:\Users\*logged in user name*\cr\server\*Unique session ID*\
So what happens at render time now is this. Blender starts and prefixes the path to the blend file to the relative path cache_fluid_4b85f272\fluid.data which results in
C:\Users\*logged in user name*\cr\server\*Unique session ID*\cache_fluid_4b85f272\fluid.data
There is no such folder however, CR doesn't re-create your cache folder for you, and as a result there's no fire.
How can you fix this?
Use absolute paths. If you set all paths to be absolute, then instead of prefixing the \cache_fluid_4b85f272\fluid.data part with the path to the blend file (which is incorrect on the render nodes), blender will use the absolute path which is
E:\cache_fluid_4b85f272\fluid.data
So long as you have created a shared drive E: with exactly the same path on each render node, blender will be able to access the data across the network, provided you have enabled sharing of course (it sounds like you have done that though if you can see the files in a browser from the render nodes?).
Alternatively you can use relative paths, but you'd need to transfer the cache for the fire simulation to each render node manually and locate it next to the blend file. This of course is a bit laborious and not as nice as using the shared drive approach.
does this help? Happy to assist further if need be.