To test this feature, visit your live site.

Raspberry cluster

Have read all posts about Raspi's but still not found a solution. Trying to do the impossible: build a renderfarm with 24 PI's 2B+ (4 cores, 1 Gb mem, 8 Gb disk). To do some tests first about possible benefits, I've rendered an image of the standard cube with Cycles on my Mac (3.5 GHz I5, 32Gb 1600 MHz memory). Rendertime about a minute (Yes, yes, Eevee is much quicker but can not do that on my PI's). Then I've configured a headless PI (Raspbian BullsEye, need that for Kubernetes), installed Blender and CrowdRender, synced the node and rendered (with the Mac unsynced) only with the synced PI: rendertime a disapointing ~30 minutes. So I tried an other PI a BullsEye with graphics, installed Blender and started Blender GUI. Very slow UI but the render of the standard cube took only a surprising 5 minutes. Some difference is acceptable given some CrowdRender communication overhead but on the other hand the headless uses less ram because it does not have the GUI installed. So the GUI version beating the headless with factor 6 is a bit weird. So the first question is: how is this possible?

All Blender versions were 2.83.5, Python 3.9.2, and CR 3.1 on the PI and any version of CR on the Mac will do up until 4.1. I assume and hope that later versions of CR on the PI will perform better but I can not install them. Many errors.

First of all, when Python module pyzmq is not installed on the PI, you can't get CR to work at all. Took me some time to figure that out, but would have loved to see that in the requirements.

Blender 2.93.1 on the Mac (and BL041) was not syncing with the PI. No errors, just not syncing. That’s why I had to go back to Blender 2.83.5 on the Mac as well. The PI's do not go very much further anyway. Not really a problem. Blender 2.79 gave all sorts of unexpected errors so I abandoned that version on all machines.

On the Mac CR 4.1 can be installed but in the headless PI's I can not go further than CR 3.1 because . . .

CR032 gives "RuntimeError: unsupported operating system! : sys.version_info(major=3, minor=9, micro=2, releaselevel='final', serial=0) Linux, MacOS and Win64 are supported"

CR040 gives "NameError: name 'python_version' is not defined"

CR041 gives again the "unsupported OS" error.

CR030 and CR031 run but slooooooowwww :)))

How can I go from here or isn’t there any version of CR that can meet or beat the 5 minutes of the standalone GUI version on the PI?

TIA, Rob

5 comments

5 Comments

James Crowther

Sep 06, 2022

Sorry, been trying to reply but seems our forum is a bit glitchy

Ok, so V0.4.1 is def the right choice since all the other versions don't package binaries for arm, and installing pyzmq yourself, though it might help in the cases of the older versions, the newer versions fix important issues, so its better to figure out what is broken with V0.4.1 on arm. Plus when you come to upgrade Blender and it uses a higher version of python, you'll need to remember to also upgrade pyzmq, which will be annoying to say the least.

I don't have any Pis to test with, but if you can maybe upload the contents of your console or do a screen capture showing how you installed and ran the addon/blender, I will do my best to help debug.

James Crowther

Sep 06, 2022

Hi Rob,

rob.ista

Aug 30, 2022

To answer some of my questions myself: obviously from CR032 onwards, it's been decided not to support armv7l anymore. When installing, in __INIT__.py all Linux archs except x86_64 and aarch64 became invalid. I've tried to bake sth myself from CR030 and CR041 but that did not go very well. Sync from my Mac (CR030 and CR041) does start (sometimes) but fails quickly.

def select_platform():

""" checks python/blender versions and sets import paths accordingly

"""

global cr_source

if platform.system() == 'Darwin' and platform.machine() == 'x86_64':

set_sys_path('Darwin_x86_64')

elif platform.system() == 'Darwin' and platform.machine() == 'arm64':

set_sys_path('Darwin_arm64')

elif platform.system() == 'Linux' and platform.machine() == 'x86_64':

set_sys_path('Linux_x86_64')

elif platform.system() == 'Linux' and platform.machine() == 'aarch64':

set_sys_path('Linux_aarch64')

""" add 32 bit architecture to include 32 bit ZMQ libraries

"""

elif platform.system() == 'Linux' and platform.machine() == 'armv7l':

set_sys_path('Linux_aarch32')

elif sys.platform.startswith('win'):

set_sys_path('Win64')

else:

raise RuntimeError(f" unsupported operating system! :\

{sys.version_info} Linux, MacOS and Win64 are supported")

from . import cr_source

Nowhere to go obviously. Probably abandoning this route. Cheers.

James Crowther

Sep 06, 2022

Replying to

Finally this makes sense, you're using a Pi 2B, just realised they are 32 bit machines. We never packaged support for 32 bit archs.

To be honest there never was huge demand for this. Or if there was, it went unvoiced.

This could probably work if you've installed the pyzmq binaries yourself. However, Blender needs to know where your installation of those binaries is. Blender usually, AFAIK, doesn't check the paths of your python installation since it bundles it's own.

You can check where blender is looking for python libs by opening blender (you can do it headless if the slow GUI is a pain), going to a scripting view and typing

import sys
sys.path

If the location of your installed pyzmq isn't in one of those locations, then Blender won't be able to find it, and by extension neither will the addon.

All the code you modified does is modify the sys.path for the python env in Blender. I can't see what your mods are though since you've either omitted it or not yet written it?

If its the latter, then that's prob a good explanation of why it doesn't work. If its the former, then be great to see what errors you get.

Of course if you've already abandoned ship, no worries, bon voyage!

Just know that others have already got this to work, but, I think they have used models of pi that are 64 bit and so don't have this extra hurdle to jump over. If you're planning to purchase more Pi's (like 24 of them), I'd recommend picking a model that is 64 bit.

rob.ista

Sep 07, 2022

Replying to

Hi James, thanks for reaching out. And no, I've not abandoned ship yet. Running the tiny cluster as a render farm is just too tempting. Nevertheless it's already a challenge to get it running anyway with a number of other apps as well, especially with K3S :) ... And yes, I wish they were 64 bit. I just have 32 of those 2B monsters so that's what I have to work with together with a few (virtual) X86-machines. Indeed when availability gets better, I will expand the cluster with probably 3 8Gb 4B's and a Nvidea Jetson. Meanwhile . . .

It's correct that you have not supported 32-bit officially however 030 and 031 did not exclude that either. In the 030 and 031 the __INI__.py scripts only differentiated between Darwin, Windows and Linux. Only from 032 onwards, Linux 64-bit came in to play making the 32-bit obviously invalid. But anyway, Blender 2.83.5 runs fine on the Raspbian 11 Bullseye 2B's and Python version 3.9.2 too. So it was a bit weird to see that Blender with a full (albeit very slow) GUI did a render-test with the standard cube in about 5 seconds, whereas a Blender 2.83 + CrowdRender 030 on both ends took 28 seconds. That means the obviously the communication overhead is so vast, the "bacth network" version takes a factor >4 compared to the GUI version. I must admit that after swapping back and forth with versions from 030 up to 041, I sometimes got a surprising and unexplained 7.5 seconds which would be somewhat acceptable. After all, the load would be shared between 20+ nodes.

In an attempt to get 041 working on a 2B, I did not only change the code in the __INIT__.py script but of course in a special 041-zip I did also include the folders in a new Linux_aarch32 folder with the pymzq binaries copying them from an older 030 version (which apparently worked). So actually i don't quite understand why I got the pymzq errors earlier since you obviously include them in your install bundle anyway.

So since this is not working well, I assume that the handling of them changed as well from versions 032 onwards until 041. With a Blender 2.83 on the Mac syncing does not happen at all without any error messages in the log to show. I also must say that after flipping between various versions of Crowdrender, the install started to act "weird". See screenprint. I could not explain the cause or got over it. I guess I have to clean ~/library/ApplicationSupport or sth like that.

Strangely enough with a Blender 2.91.1 and CrowdRender 041 sync starts, tries to upload an untitled.blend file unasked, that gives an error on the node "file written by a newer Blender binary." (that's right) followed up by an error "engine 'Crowdrender' not available for scene 'Scene'" and then the Mac abandons the sync again with a fail :(((

All help and tip's highly appreciated. I can do some programming myself but need some guidance where to look :)))

Cheers, Rob

Support Crowdrender!

Raspberry cluster

Terms of use

Privacy Policy