- any headless Linux server
- Blender v2.79 or v2.80 - v2.93 (from package manager or blender.org)
- latest version of CrowdRender addon
- optional: GPU drivers for GPU-rendering
$ blender -b --python-console
(InteractiveConsole)
>>> import bpy
>>> bpy.ops.wm.addon_install(overwrite=True, filepath="/path/to/folder/addon.zip")
>>> bpy.ops.wm.addon_enable(module='crowdrender')
>>> bpy.ops.wm.save_userpref()
>>> exit()
$ blender -b --python-console
(InteractiveConsole)
>>> import bpy
>>> bpy.ops.preferences.addon_install(overwrite=True,filepath='/path/to/addon.zip')
>>> bpy.ops.preferences.addon_enable(module='crowdrender')
>>> bpy.ops.wm.save_userpref()
>>> exit()
$ blender -noaudio -b --python ~/.config/blender/2.79/scripts/addons/crowdrender/src/bl_2_79/serv_int_start.py -- -t "server_int_proc"
Crowd Render Server Interface Process ready
for blender v2.80 you will need to change the path to serv_int_start.py
accordingly
$ blender -noaudio -b --python ~/.config/blender/2.79/scripts/addons/crowdrender/src/py_3_5_3/serv_int_start.py -- -t "server_int_proc"
$ blender -noaudio -b --python ~/.config/blender/2.80/scripts/addons/crowdrender/src/py_3_7/serv_int_start.py -- -t "server_int_proc"
$ blender -noaudio -b --python ~/.config/blender/2.80/scripts/addons/crowdrender/src/cr/serv_int_start.py -- -t "server_int_proc"
now it should show the IP address of your server and you should be able to connect to the server via any client running in the same network
-p false
- if you're using a virtual machine from a cloud provider, you may not want to permanently store it in your crowdrender account as if you do, each time you use a vm from a cloud provider, you'll get a different vm and they'll start to pile up in your account.-ak
- called the access key, if you setup multiple vm's on your own servers, best give them each a unique access key. This can be literally anything, but its important if you're using containerisation or vms on your own hardware since if you do, chances are the hardware id of those vm's containers could be the same, which totally prevents you from connecting to more than on of them at once, defeating the purpose of using our software.-ct
- authorisation token of your Crowdrender cloud account. Using this allows the vm's / containers to post to your cloud account on our servers when they are alive. This means you'll actually be able to see which of them are alive and able to be used and which are offline (or just not posting cause they're not logged in).
you can run the process in the background by using screen
and detatch it with Ctrl + a + d
$ screen blender -noaudio -b [...]
(Blender 2.80)
You create a unit /etc/systemd/system/crowdrender.service
[Unit]
Description=CrowdRender service
After=network.target
[Service]
Type=simple
ExecStart=/path/to/blender -noaudio -b --python /home/example/.config/blender/2.80/scripts/addons/crowdrender/src/py_3_7/serv_int_start.py -- -t "server_int_proc"
Restart=on-failure
RestartSec=10
[Install]
WantedBy=multi-user.target
for Blender 2.79/2.81 etc. you need to change the path to the addon in ExecStart
To start the demon you run:
systemctl start crowdrender.service
To start at boot you enable it:
systemctl enable crowdrender.service
Specs are listed below, but before I go into those I do have a bit more information now. I am able to render easily with multiple nodes and I found that the automatic load balancer works pretty well (Nodes finish within about 5% of each other at the end of a render). This was with a much smaller .obj file than the excessively large 400mb obj file, but I still found it weird that crowdrender was what crashed blender (I was able to open the file after removing CR). Maybe it was a case of the straw that broke the camel's back, but it would be nice if there was a failsafe where CR just stops working instead of crashing blender altogether but I don't know the feasibility of that. And now here are the specs of the hardware that I love to play around with too much:
The master:
OS: Manjaro kde kernel: 5.14.1
cpu: i5-7500 @3.8ghz
ram: 16G ddr4
The client(server1):
OS host: Proxmox
OS VM: Ubuntu 21.04
CPU: 2x Xeon X5672 (VM has access to full cpu)
RAM(VM): 16G ddr3
Client(server2):
OS host: Proxmox
OS VM: Ubuntu 21.04
CPU : Xeon X5687 (VM only has access to 6 of the 8 threads)
RAM(VM): 4G
If you don't know much about proxmox, I tend to get less than 5% performance loss in a vm