Det har jeg bygget

At rendere en Blender-animation frame for frame på én computer kan tage overraskende lang tid.

Idéen bag Mr. Blender Render var enkel: hvorfor ikke bruge de computere, der allerede står omkring dig og alligevel ikke laver noget?

Applikationen har en central renderkø, hvor et job kan tilføjes, og de tilgængelige maskiner kan tildeles opgaven.

Hver Node forbinder til hovedapplikationen og venter på arbejde. Når en frame bliver ledig, tager en Node den, renderer den og rapporterer resultatet tilbage til hovedapplikationen. Det gør det muligt for maskiner med meget forskellig ydeevne at arbejde sammen.

En hurtig workstation kan behandle flere frames, mens en langsommere laptop blot bidrager med det, den kan.

Der er ikke noget krav om, at alle maskiner har samme hardware.

Ét renderjob. Flere computere.

Hovedinterfacet giver et overblik over hele renderprocessen:

Renderkø

Tilføj og administrer Blender-renderjobs.

Frame-fordeling

Frames fordeles automatisk mellem de tilsluttede Nodes.

Blandet hardware

PC'er og Macs kan deltage i det samme renderjob.

Live-status

Følg den aktuelle frame, den samlede fremdrift, den forløbne tid og den forventede resterende tid.

Node-overvågning

Se hvilke maskiner der arbejder, hvilken frame de renderer, og hvor meget arbejde de har gennemført.

Lokal rendering

Selve renderingen foregår på de tilsluttede maskiner i stedet for på en ekstern cloud-tjeneste.

Skalerbar derhjemme eller i studiet

Når du tilføjer endnu en computer, får du blot endnu en mulig render-maskine.

Bygget og stresstestet med rigtige maskiner

Jeg har testet systemet med en blandet flåde af tre Macs og to PC'er, alle med forskellige hardwarekonfigurationer og forskellig render-ydelse.

Det var en vigtig del af projektet.

En renderfarm bør ikke forudsætte, at alle maskiner er ens. I et rigtigt studie kan du have en kraftig workstation, en ældre desktop, en MacBook og en maskine, der kun lejlighedsvis er tilgængelig.

Mr. Blender Render er designet omkring netop dette scenarie.

Maskinerne behøver ikke at færdiggøre frames med samme hastighed. De tager blot ledigt arbejde, når de er klar.

Hvorfor bygge en privat renderfarm?

Cloud-rendering er nyttigt, men nogle gange står den hurtigste computer, du har adgang til, allerede lige ved siden af dig.

En privat renderfarm kan udnytte eksisterende hardware, som ellers ville stå ubrugt.

Til en lang animation kan selv en relativt beskeden ekstra renderkapacitet gøre en mærkbar forskel. I stedet for eksempelvis at lade én GPU rendere 2.975 frames kan arbejdsbelastningen fordeles på flere maskiner.

Applikationen ligger derfor et sted mellem et traditionelt Blender-workflow på én maskine og en komplet kommerciel renderfarm.

Den er med vilje lille, lokal og praktisk.

Sådan fungerer Mr. Blender Render

Et typisk workflow ser sådan ud:

1. Opret Blender-projektet Forbered scenen og animationen, som du normalt ville gøre i Blender.

2. Opret et renderjob Hovedapplikationen tilføjer animationen til renderkøen.

3. Forbind Nodes Andre PC'er og Macs på netværket kører Node-applikationen.

4. Fordel frames Ledige Nodes henter frames fra køen.

5. Render parallelt Hver maskine renderer sin tildelte frame ved hjælp af sin egen Blender-konfiguration og GPU.

6. Rapportér resultatet Færdige frames rapporteres tilbage til hovedapplikationen.

7. Gentag, indtil jobbet er færdigt Så snart en maskine er færdig, kan den hente en ny frame.

Det vigtige er, at maskinerne ikke behøver at arbejde i takt. De fortsætter ganske enkelt med at hente arbejde fra køen.

Fra renderkø til renderfarm

En af de interessante ting ved dette projekt var, at den grundlæggende idé faktisk er ret enkel.

En renderfarm behøver ikke nødvendigvis at være et gigantisk datacenter.

Grundlæggende handler problemet om:

Hvordan får man flere computere til at arbejde på den samme sekvens uden at to maskiner renderer den samme frame?

Mr. Blender Render løser dette med en central kø og et system, hvor frames tildeles de enkelte maskiner.

Hovedapplikationen holder styr på de tilgængelige frames og de maskiner, der arbejder. En Node tager en frame, renderer den og rapporterer den som færdig.

Interfacet kan derefter vise status for hele renderfarmen i realtid.

Det gør det også muligt at blande maskiner med meget forskellige ydelsesniveauer. En kraftig desktop kan eksempelvis rendere flere frames, mens en langsommere maskine bidrager i et andet tempo.

Køen sørger ganske enkelt for hele tiden at holde arbejdet i gang.

En lille renderfarm bygget af de maskiner, du allerede ejer

Projektet startede med en meget praktisk idé:

Kan jeg få computerne omkring mig til at arbejde sammen, når jeg skal rendere en Blender-animation?

Svaret blev Mr. Blender Render.

I stedet for at bygge en kompleks cloud-infrastruktur eller leje ekstern GPU-kapacitet omdanner applikationen en samling lokale computere til et lille distribueret renderingssystem.

Hovedapplikationen styrer køen og giver det samlede overblik. Nodes står for selve renderingen.

Fordi systemet er designet til et lokalt netværk, kan det bruges til personlige projekter, animationsarbejde, produktvisualisering, motion graphics, eksperimenter og mindre studiemiljøer, hvor flere computere er tilgængelige.

Bygget med Tauri 2.0

Desktopapplikationen er bygget med Tauri 2.0, hvilket gør det muligt at pakke projektet som en native desktopapplikation til forskellige operativsystemer.

Det var særligt nyttigt til et projekt, der skal kunne kommunikere med både Windows- og macOS-maskiner.

Hovedcontrolleren er i øjeblikket designet omkring et PC-baseret workflow, mens Node-applikationerne kan køre på både PC og Mac.

Den færdige applikation distribueres som native installationsfiler, så projektet ikke behøver at blive kørt fra et udviklingsmiljø.

Udviklingsprocessen var også et eksperiment i AI-assisteret softwareudvikling, hvor Claude blev brugt aktivt gennem implementeringen og kodningen.

Resultatet

Mr. Blender Render er ikke tænkt som en erstatning for en stor kommerciel renderfarm.

Det er noget langt mere praktisk:

en privat renderfarm bygget af de computere, du allerede har.

Til lange Blender-animationer kan hver ekstra render-maskine blive endnu en worker i køen.

Og når renderingen endelig er færdig, kan computerne gå tilbage til det, de egentlig skulle have lavet.

Case / Projektinformation

• Projekt: Mr. Blender Render
• Type: Privat distribueret renderfarm
• Platform: Windows + macOS
• Framework: Tauri 2.0
• 3D-software: Blender
• Arkitektur: Hovedcontroller + Render Nodes
• Rendering: Distribueret frame-rendering
• Netværk: Lokalt netværk
• Udvikling: AI-assisteret udvikling med Claude
• Rolle: Koncept · UX · Design · Udvikling
• Status: Privat projekt / eksperimentelt værktøj