Hi XenWildman, thanks for the great feedback! Let me take the time to answer this:
Of course, you’re right. I just hoped someone could step in and provide binary packages for these distros. Your wish was definitely noted. I’ll see what I can do.
Once compiled, there are two ways to launch- bin/bitwrk-client and through the addon “start bitwrk client” but through the terminal “allow other computers as workers” is not an available option. If started from terminal, start and stop client are unavailable in blender.
Allow other computers as workers is actually identical to passing -intiface “” to bitwrk-client (the two double quotes are important). The behavior you’re observing wrt buttons greyed out is actually intentional, because there is already a client running on the selected port.
It is unclear whether when I start bitwrk-client from terminal it is available as a worker for other computers or not. Do I need to load up blender and start worker? If so, then starting from terminal only works for local (same computer, not LAN) anyway and start from terminal is superfluous.
bitwrk-client acts as a hub for workers. They connect to a bitwrk client and wait for jobs. Starting a worker can be done easily from Blender. It will then use the running Blender and connect to the bitwrk client configured in the settings panel (usually on localhost:8081, but can be somewhere on LAN, too).
You can start a worker on the command line, too. See below.
When I open up the web interface, there is a message in a big blue bar that covers up the Activities/Workers/Mandates text that denotes what the columns mean. This message is not immediately obvious that it can be closed so that information is unavailable.
Thanks for telling me this!
In Blender, I started the Bitwrk client with Start worker with the client host ip set to my other machine. It shows up as available on my other machine but when I try to render it always asks for a different port.
Error performing sell (delaying next sell by 20s): Worker finished with error: Post http://127.0.0.1:37647/work: dial tcp 127.0.0.1:37647: getsockopt: connection refused
If I change to that port, the requested port will change too.
Ok, I looked into this and had a little facepalm moment. You found a bug that prevents LAN rendering from working correctly. Shame on me! :eek:
As a workaround, you might start a worker on the command line:
> python3 ./blender-slave.py --blender /usr/bin/blender --bitwrk-host 192.168.1.1 --bitwrk-port 8081 --listen-port 8765 --listen-iface 192.168.1.2
I assumed 192.168.1.1 as the LAN address of the computer running bitwrk-client and 192.168.1.2 as the IP of the worker computer (as reported by ifconfig). Port 8765 was arbitrarily chosen.
Thanks for reporting this!
It is unclear whether “concurrent tiles” means total for all machines or local threads.
It defines how many tiles Blender dispatches to the BitWrk client at once. Playing around with this a little can be beneficial at the moment.
When I enable Bitwrk Render, all materials in material view (3d viewport) go black.
It seems when I go into the web interface, I can manually publish the job to be done by a computer somewhere else at 0BTC, but I have to do this for each tile instead of a block of them.
This is where I get stuck. At it’s current state, Bitwrk renders require way more manual intervention and are slower than local rendering as a result.
If you hit the checkbox next to “Valid for up to … trades”, you can set a price for the next N tiles.
With BitWrk in addition to local rendering, you should be able to get a little more speed out of it.
Thanks again for the valuable report, and I will fix that LAN bug shortly!
Keep on BitWrk’ing