Halloween/PLAN.md

# Halloween: interaktives atmendes Grab

Stand: 1. Oktober 2026. Status: Entwurf zur Abstimmung; erste Software mit
Livebild und simulierter Steuerung vorhanden, reale Mechanik noch offen.

## Zielbild

Eine Grabattrappe im Vorgarten atmet langsam. Nähert sich ein Besucher,
stoppt die Bewegung. Nach einer kurzen wechselnden Pause folgen Kratzen,
ein kräftiger Geräuschimpuls, eine kurze Bewegung und Licht. Optional hebt
sich eine Skelett-Hand innerhalb der Attrappe.

Die Weboberfläche zeigt das Livebild, Betriebszustand und Ereignisse.
Bilder und kurze Videoclips lassen sich auf dem Laptop speichern und
manuell prüfen. Die Erkennung meldet Personen oder Bewegungen in definierten
Bereichen; sie identifiziert keine Personen.

## Bisherige Wünsche und Bestand

- Einsatz draußen im Vorgarten; möglichst starker Schreckeffekt.
- Nutzerwunsch für die Graboberfläche: Folie, darüber grobes Gewebe und
  Blätter. Die Attrappe soll ungefähr die Proportionen eines Jugendlichen
  haben; „besenstiellang“ war die erste Größenbeschreibung. Exakte Länge,
  Breite und bewegter Bereich sind noch offen.
- Die Atembewegung soll wie im Referenzvideo mehrere ungleichmäßige,
  örtliche Wölbungen erzeugen. Die Gestaltung darf detailreicher und
  realistischer werden als die Vorlage.
- Am vorgesehenen Standort stehen nach grober Schätzung des Nutzers etwa
  2 m² zur Verfügung. Länge, Breite und Abstand zum Besucherweg sind noch
  nicht gemessen.
- [Originalclip](references/atmendes-grab-original.mp4) als Referenz vom
  Nutzer bereitgestellt; [öffentliche Quelle](https://www.facebook.com/joshua.brawer/videos/1075933321689584/).
- Raspberry Pis 3–5 vorhanden. Raspberry Pi 5 anhand der Platinenbeschriftung
  auf Nutzerfoto bestätigt; vermutlich 8 GB RAM laut Nutzer, noch zu prüfen.
- Der Pi 5 unterstützt laut [Herstellerdaten](https://www.raspberrypi.com/products/raspberry-pi-5/)
  2,4- und 5-GHz-WLAN (Wi-Fi 5/802.11ac). Empfang am Aufstellort und die
  tatsächliche Verbindung sind noch nicht geprüft.
- Aufkleber am Pi zeigt `raspi5WLAN.local` und darunter `_2`; tatsächlicher
  Hostname und Erreichbarkeit sind noch nicht geprüft.
- „2mini“ vorhanden: genaue Bezeichnung noch klären.
- Kamera: Raspberry Pi Camera Module 3 NoIR, anhand der Beschriftung auf dem
  Nutzerfoto identifiziert. Funktion noch nicht getestet; Display eventuell vorhanden.
- LEDs, Servos und Lötwerkzeug vorhanden; weitere Teile können gekauft werden.
- Kameraauswertung soll Hinweise auf kleine Kinder berücksichtigen.
- Der volle Schreck soll nach Auslösung automatisch ablaufen, ohne
  Freigabe für jeden einzelnen Besucher.
- „Voller Schreck“ ist der gewünschte Standardmodus; der Modus soll später
  in der WebUI auf Sanft, Atmosphäre oder Aus umstellbar sein.
- Liveansicht sowie Speicherung von Fotos und Videoclips auf dem Laptop.
- Wunsch nach Prüfung verdächtiger Rückkehr: Ereignisübersicht und manuelles
  Vergleichen der Clips; keine automatische personenübergreifende Identifizierung.

## Erkenntnisse aus dem Referenzvideo

Im etwa 17,5 Sekunden langen Clip ist ein rechteckiger Holzrahmen zu sehen.
Eine längs durch den Rahmen geführte Stange trägt mehrere versetzt befestigte
Kunststoffflaschen. Ihre Lage ändert sich im Video; sie wirken wie leichte
Exzenter, die die Abdeckung an mehreren Stellen unterschiedlich anheben.
Anschließend wird eine dunkle Folie über den Rahmen gelegt. Im fertigen
Aufbau liegen darüber ein grobes helles Gewebe und Blätter; blaue Beleuchtung
verstärkt den Eindruck. Die Abdeckung wölbt sich örtlich, statt als starre
Fläche insgesamt hochzufahren.

Das Video belegt weder Antriebsmodell noch Drehmoment, genaue Abmessungen,
Hub oder wetterfeste Ausführung. Die Flaschen sind eine Anschauung für das
Bewegungsprinzip, noch keine Festlegung für unseren Bau. Die Kombination aus
Folie, Gewebe und Blättern ist nun als gewünschter Aufbau festgehalten.

**Gestaltungsvorschlag für mehr Realismus:** Matte, unregelmäßig fallende
Gewebeschicht statt sichtbarer glänzender Folie; unterschiedlich dichte
Laubstellen und eine flache, nicht symmetrische Kontur. Rahmenkanten,
Antrieb und Kabel werden aus Besucherperspektive verdeckt. Grabmarkierung,
Licht und Geräusche sollen die Illusion unterstützen, ohne die bewegte
Fläche unnötig zu beschweren. Materialoptik bei Tageslicht und bei der
geplanten Nachtbeleuchtung prüfen; lose Blätter und nasses Gewebe gehören
zum Belastungstest.

## Vorgeschlagene Architektur

| Komponente | Aufgabe |
|---|---|
| Pi 5 | Kamera, anonyme Personenerkennung, WebUI, Ereignisse und Clip-Puffer |
| Pi 3 oder 4 (optional) | Effekte, Ablaufsteuerung und lokale Bedienelemente |
| Laptop | WebUI aufrufen, Livebild ansehen, Clips herunterladen |
| Treiber und separate Versorgung | Motoren, Servos und Beleuchtung versorgen |

Der gewählte Auslöser meldet Ereignisse an die Effektsteuerung. Diese
begrenzt Sequenzdauer und Wiederholungen selbst. Bei Kommunikationsverlust
führt sie keine neuen Schreckbefehle aus.

**Architekturentscheidung:** In Phase 3 den vollständigen Ablauf mit einem
Pi und simulierten Ausgängen prüfen. Über einen zweiten Pi nach Integration
von Kamera und WebUI entscheiden, wenn Leitungswege, Aufstellung und Last
bekannt sind. Lokaler Stopp und sichere Abschaltung
der Antriebe dürfen in keiner Variante von WebUI oder WLAN abhängen. Falls
zwei Pis nötig sind, erhält jeder Schreckbefehl eine begrenzte Gültigkeit;
nach Verbindungsverlust bleibt die Effektseite ohne neue Auslösung.

### Software-Stack

Der gesamte Code wird in Python umgesetzt. Vorgeschlagene Technologien:

| Bereich | Vorschlag |
|---|---|
| WebUI / API | FastAPI mit uvicorn |
| Livebild | picamera2 oder gstreamer, je nach Test |
| Personen-/Bewegungserkennung | OpenCV, optional Raspberry Pi AI Kit / Hailo |
| GPIO / Effekte | gpiozero oder lgpio |
| Konfiguration | YAML- oder JSON-Dateien |
| Logging / Clips | Standardbibliothek `logging`, Video mit OpenCV/FFmpeg |

### Code-Struktur

Die Dateien bleiben, soweit sinnvoll, unter 400 Zeilen. Dabei bleibt
Wartbarkeit wichtiger als sture Einhaltung der Grenze. Vorgesehene Module:

- `config.py` – zentrale Konfiguration und Validierung
- `camera.py` – Kamerazugriff und Capture-Puffer
- `detector.py` – anonyme Personen-/Bewegungserkennung
- `events.py` – Ereignisverwaltung und Clip-Speicherung
- `effects.py` – Effektablaufsteuerung, bei Bedarf auf dem Effekt-Pi
- `web.py` – FastAPI-Endpunkte und MJPEG-Livebild in der ersten Version
- `main_controller.py` – Start, Verbindung und Hauptloop auf Pi 5
- `main_effects.py` – bei zwei Pis: Start und Überwachung auf dem Effekt-Pi
- `shared/protocol.py` – bei zwei Pis: Nachrichtenformat zwischen Pis

Der Laptop muss für Liveansicht eingeschaltet sein. Vorgeschlagen ist ein
begrenzter Clip-Puffer auf dem Pi, damit Ereignisse auch ohne Laptop später
abrufbar bleiben. Speicherziel und Löschfrist sind noch offen. Für einen
vollen Speicher ist ein sichtbarer Fehlerzustand vorzusehen; die
Effektsteuerung darf dadurch nicht blockieren.

Für die erste nutzbare Version genügen ein Auslösebereich, ein kurzer
Effektablauf, lokaler Stopp, Betriebsanzeige und ein abrufbarer Ereignisclip.
Hand, Display und weitere Effekte folgen erst nach bestandenem Außentest
dieses Ablaufs.

## Kamera und Nachtbetrieb

Das vorhandene Camera Module 3 NoIR besitzt Autofokus und keinen IR-Sperrfilter.
Mit zusätzlicher Infrarotbeleuchtung ist Nachtbetrieb möglich; ohne Beleuchtung
liefert es in völliger Dunkelheit kein brauchbares Bild. IR-Leuchte, Reichweite,
Position und Reflexionen am Schutzfenster müssen am Aufstellort getestet werden.

Für Pi 5 wird ein Kamerakabel von Standard (15-polig, kameraseitig) auf Mini
(22-polig, Pi-seitig) benötigt. Die Pi-seitige Ausführung des vorhandenen Kabels
ist auf dem Foto nicht sichtbar und bleibt zu prüfen. Wetterschutz und Sichtfeld
sind noch offen. Personenmodelle müssen mit den tatsächlichen Nachtbildern
geprüft werden; NoIR allein garantiert keine zuverlässige Erkennung.

Vor dem Bau am Aufstellort Sichtfeld, Dunkelbild, Gegenlicht und Reflexionen
prüfen. Dabei entscheiden, ob die Kamera zuverlässig auslösen kann oder ob
ein zusätzlicher, noch auszuwählender Sensor den Auslöseimpuls liefert und
die Kamera Bild und Clip aufzeichnet.

Quellen: [Camera Module 3](https://www.raspberrypi.com/products/camera-module-3/)
und [Kamerakabel](https://www.raspberrypi.com/products/camera-cable/).

## Effektablauf und Modi

1. Ruhe: langsames Atmen, schwaches Licht, gelegentliche Geräusche.
2. Annäherung: Atmen stoppt, kurze Stille.
3. Auslösung: Kratzen, kurzer Tonimpuls, begrenzter Ruck und Licht.
4. Optional: leichte Hand hebt sich am Grabrand.
5. Rückkehr in sicheren Zustand, anschließend Sperrzeit.

Modi: Aus, Atmosphäre, Sanft, voller Schreck und Wartung/Test.
Vorschlag: Ohne gespeicherte Auswahl ist „voller Schreck“ der Standard;
eine Änderung in der WebUI bleibt nach normalem Neustart erhalten.
Ein lokaler Stopp muss unabhängig vom Browser funktionieren.
Im Modus „voller Schreck“ startet die Sequenz nach einem gültigen Trigger
automatisch; Sperrzeit und Stopp bleiben wirksam. Nach dem Einschalten erst
Betriebsbereitschaft und einen freien Auslösebereich abwarten. Nur ein neuer
Trigger danach darf eine Sequenz starten; ein alter Zustand löst nichts aus.
Nach Stopp oder Fehler ist ein bewusstes Rücksetzen nötig.

Vor der Umsetzung für jeden Aktor die sichere Ruhelage, mechanischen
Anschlag und maximal erlaubte Laufzeit festlegen. Ein gut erreichbarer
lokaler Schalter soll die Antriebsversorgung unabhängig vom Programm
unterbrechen können; danach darf kein selbsttätiger Neustart erfolgen.
Ein weiterer Trigger während der Sequenz löst keinen zweiten Effekt aus.
Bei unklarem Steuersignal endet die Bewegung.

Körpergröße im Kamerabild ist nur ein unsicherer Hinweis. Abstand, Verdeckung,
Kostüme und Kinderwagen können die Auswertung verfälschen. Eine zuverlässige
automatische Altersentscheidung ist damit nicht möglich. Der Nutzer wünscht
dennoch „voller Schreck“ als Standard mit automatischer Auslösung. Im
vollen Modus können deshalb auch Kinder den vollen Effekt abbekommen.
Die WebUI bietet Sanft für entsprechende Betriebssituationen an. Ob ein
unsicherer Kamerahinweis zusätzlich automatisch auf Sanft zurückschaltet
oder nur als Hinweis angezeigt wird, bleibt vor Umsetzung zu entscheiden.
Keine Freigabe pro Besucher.

## Weboberfläche

- Livebild mit Auslösebereich und optional maskierten Bildbereichen.
- Moduswahl, manuelle Effektknöpfe und klar sichtbarer Stopp.
- Kamera- und Steuerungsstatus sowie letzte Auslösung.
- Ereignisliste mit Zeit, Vorschaubild, Ereignistyp und Clip.
- Bild-/Clip-Download auf den Laptop.
- Einstellungen für Lautstärke, Sperrzeit, Bereiche und Aufbewahrung.
- Lokaler Zugangsschutz; keine öffentliche Internetfreigabe vorgesehen.
- Aufnahmebereich vor dem Einsatz begrenzen und nötige Bildbereiche
  maskieren; Tonaufnahme bleibt standardmäßig aus.

## Phasen mit Abnahmekriterien

### 1. Anforderungen und Hardware klären

- [ ] Hardware- und Sicherheitsplan vor Bau und Aktoranschluss abschließen.
- [x] Kameramodell anhand des Fotos feststellen: Camera Module 3 NoIR.
- [ ] Pi-5-Kabel, Kamerafunktion und Nachtbild mit IR-Beleuchtung prüfen.
- [ ] Sichtfeld und mögliche Auslösung am echten Aufstellort prüfen;
      Kamera- oder Zusatzsensor als Trigger festlegen.
- [ ] Pis, Display, Servos und vorhandene Netzteile konkret erfassen.
- [x] Raspberry Pi 5 anhand des Nutzerfotos identifiziert.
- [ ] RAM, tatsächlichen Hostnamen, Betriebssystem, Netzteil und Kühlung des Pi 5 prüfen.
- [ ] Die grob geschätzten 2 m² am Aufstellort als Länge × Breite und mit
      Abstand zum Besucherweg nachmessen; daraus jugendlich wirkende
      Grabmaße festlegen. Gewicht von Folie/Gewebe/Blättern und Hub messen.
- [ ] Aufstellort, Besucherweg, Wetterschutz, Strom und Netzverbindung klären.
- [ ] Budget, Clip-Aufbewahrung und Reaktion auf unsichere Kamerahinweise
      bei Kindern abstimmen.
- [x] Automatische Auslösung statt Freigabe pro Besucher festgelegt.
- [x] „Voller Schreck“ als Standard, per WebUI umstellbar, festgelegt.
- [ ] Sichere Ruhelage, Bewegungsgrenzen und Stoppkonzept je Aktor festlegen.
- [ ] Akzeptable Auslöseverzögerung, Sperrzeit und Fehlalarmrate festlegen.

Abnahme: konkrete Bauteile, Abmessungen, Grenzen und ein am Einsatzort
plausibler Auslöser sind dokumentiert.

### 2. Mechanischen Prototyp bauen

- [ ] Leichten Rahmen und bewegte Oberfläche konstruieren.
- [ ] Lokale Wölbungen durch eine längs gelagerte Stange mit weichen,
      versetzten Hebepunkten im Tischversuch bewerten.
- [ ] Folie, Befestigung und Blattauflage auch im nassen Zustand prüfen.
- [ ] Abdeckung aus Besucherperspektive bei Tag und Nacht auf sichtbare
      Mechanik, glänzende Stellen und verrutschende Blätter prüfen.
- [ ] Atembewegung mit geeignetem Antrieb auf dem Tisch testen.
- [ ] Schreckimpuls separat auswählen und begrenzen.
- [ ] Anschläge, Abdeckungen und lokalen Stopp einplanen.

Abnahme: wiederholbare Bewegung ohne zugängliche Quetschstellen; keine
Bewegung in den Besucherweg. Dauerbetrieb und Stopp sind praktisch geprüft.

### 3. Effektsteuerung entwickeln

- [x] Einen vollständigen Ablauf zunächst mit simulierten Ausgängen umsetzen.
- [ ] Licht, Ton und Bewegung einzeln anschließen und testen.
- [ ] Modi, Sperrzeit, Sequenzbegrenzung und Fehlerzustände umsetzen.
- [ ] Stopp, Neustart, hängenden Befehl und Verbindungsverlust testen.
- [x] Prüfen, dass nach Start erst ein freier Bereich und danach ein neuer
      Trigger die automatische Auslösung ermöglichen.
- [x] Moduswechsel per Web-API und gespeicherten Modus nach Neustart lokal prüfen.

Abnahme: vollständiger Ablauf funktioniert ohne Kamera und Laptop. Nach
Stopp oder Fehler bleibt der Antrieb aus und startet nur nach bewusstem
Rücksetzen neu.

### 4. Kamera und WebUI ergänzen

- [x] MJPEG-Livebild, Schnappschuss und WebUI im Demo-Modus lokal prüfen.
- [ ] Livebild und geschützten lokalen Zugriff bereitstellen.
- [ ] Person-/Bereichserkennung ohne Identitätsbestimmung einrichten.
- [ ] Gewählten Auslöser mit dem Effektablauf verbinden und Fehlalarme messen.
- [ ] Ereignisse mit begrenztem Vor- und Nachlauf aufzeichnen.
- [ ] Übersicht, Download und automatische Löschung umsetzen.
- [ ] Speichergrenze und sichtbaren Fehler bei vollem Speicher prüfen.
- [ ] Unsichere Erkennung und Sanftmodus sichtbar darstellen.

Abnahme: ein Ereignis erscheint mit passendem Clip, lässt sich herunterladen
und wird nach der festgelegten Frist gelöscht; ohne Laptop gehen vorgesehene
Ereignisse innerhalb der Speichergrenzen nicht verloren.

### 5. Außentest und Erweiterungen

- [ ] Dunkelheit, Beleuchtung, Verkleidungen und Personengruppen testen.
- [ ] Auslösebereich und Fehlalarme praktisch prüfen.
- [ ] Wetterschutz, Kabel und Temperatur im geschützten Aufbau prüfen.
- [ ] Gesamtablauf mehrfach testen und Lautstärke abstimmen.
- [ ] Stopp und Strom-/Netzausfall am aufgebauten Grab erneut prüfen.
- [ ] Optional Skelett-Hand, Display oder weitere Effekte ergänzen.
- [ ] Kurze Anleitung für Aufstellen, Start, Stopp und Abbau erstellen.

Abnahme: zuverlässiger Betrieb am vorgesehenen Ort; Grenzen der Erkennung
sind bekannt und der Betreiber kann jederzeit stoppen oder sanft schalten.

## Offene Entscheidungen für den nächsten Schritt

1. Ist ein Pi-5-kompatibles Kamerakabel und eine IR-Leuchte vorhanden?
2. Wie verteilen sich die grob geschätzten 2 m² auf Länge und Breite, und
   welcher Abstand zum Besucherweg bleibt für das Grab?
3. Welches Budget ist vorgesehen?
4. WLAN oder Kabel am Aufstellort? Wo kommen Netzteile geschützt unter?
5. Clips auf dem Pi vorhalten oder nur bei eingeschaltetem Laptop speichern?
6. Wie lange sollen Aufnahmen bleiben und wer darf die WebUI bedienen?
7. Soll ein unsicherer Kamerahinweis auf kleine Besucher automatisch auf
   Sanft zurückschalten oder in der WebUI nur warnen?
8. Soll die Kamera auslösen, oder soll ein zusätzlicher Sensor auslösen und
   die Kamera nur dokumentieren?
9. Reicht nach dem ersten Test ein Pi, oder begründen Aufbau und Last einen
    zweiten Pi?

## Fortschritt

- [x] Projektregeln und erster Plan angelegt.
- [x] Allgemeines Uploadskript und Anleitung für Projektdateien vorbereitet.
- [x] Erste Kamera-WebUI mit Demo-Feed und simulierter Steuerung erstellt;
      fünf lokale Softwaretests bestanden.
- [x] Optionales Installationsskript für WebUI-Autostart beim Pi-Start und
      Integration in das Uploadskript erstellt; nur lokal geprüft.
- [x] Lokale Git-Versionsverwaltung für Code, Planung und bearbeitbare
      Blender-Szenen vorbereitet; Renderdateien bleiben lokal.
- [ ] Plan abgestimmt und freigegeben.
- [x] Softwareumsetzung begonnen; echte Kamera und Aktoren nicht geprüft.

Die WebUI ist lokal per ASGI und Demo-Bild geprüft. Pi-Kamera, SSH-Tunnel,
Netz, Verdrahtung, Aktoren und Außeneinsatz sind nicht praktisch verifiziert.
Das Upload- und Autostartskript wurde nur lokal geprüft; eine Verbindung zum
Pi, die Unit-Installation und ein Neustart wurden noch nicht getestet.
Einkaufslisten mit konkreten Modellen folgen nach Phase 1.


## Blender-Konzeptvorschau (separat freigegeben)

- [x] Vorgarten, Grabattrappe und kostümierte Besucher als Blender-Szene erstellt.
- [x] 20-Sekunden-Ablauf mit sanfter Familiensequenz und Schreck für Erwachsene animiert.
- [x] Selbst erzeugte Tonspur mit Atem-, Kratz- und Knurrgeräuschen erstellt.
- [x] Drei Vorschaubilder geprüft und Nachtbeleuchtung/Bildausschnitt überarbeitet.
- [x] Vollständiges Video gerendert: 20 Sekunden, 1280 × 720, 24 fps, H.264 + AAC.
- [x] Zwölf Bilder aus der fertigen MP4-Datei dekodiert und visuell geprüft.

Dateien liegen unter `preview/`; Reproduktionsskript: `tools/render_preview.py`.
Die Figuren sind vereinfachte 3D-Modelle in Kapuzenkostümen. Garten, Maße und
Reaktionen sind inszeniert; keine echte Kindererkennung oder mechanische
Funktionsprüfung. Die Freigabe dieser Vorschau umfasst keine Effektsoftware
oder Hardwareinstallation.


### Zweite Bildfassung nach Nutzerwunsch

- [x] Dichte Laubschicht ergänzt, synchron mit der Atembewegung.
- [x] Dunklere Stimmung, rotes Grablicht, kahle Äste und Bodennebel ergänzt.
- [x] Kinder bleiben in der fiktiven Schreckszene bei den Erwachsenen.
- [x] Gelenkige Beinbewegungen und schwingende Ärmel angelegt.
- [x] Drei finale Beispielbilder visuell geprüft; nur Bilder gerendert.
- [x] Acht animierte Beine und synchronisierte Laub-/Grabbewegung geprüft.
- [ ] Laufbewegung im vollständigen Video prüfen, falls später beauftragt.

Ergebnisse: `preview/v2/`. Das ursprüngliche Video und seine Blender-Datei
bleiben erhalten. Die filmische Inszenierung mit Kindern ändert keine
Sicherheits-/Freigaberegeln für den realen Betrieb.


### Dritte Bildfassung: mittige Hand und Laubwirbel

- [x] Hand und verdeckte Austrittsöffnung in die Grabmitte versetzt.
- [x] 110 rotierende Blätter steigen beim Handimpuls auf und fallen zurück.
- [x] Drei Beispielbilder vor, während und nach dem Hochkommen gerendert
      und visuell geprüft. Ergebnisse: `preview/v3/`.
- [ ] Neuer Videorender weiterhin nicht beauftragt.


### Vierte Bildfassung: dunklere Nachtbeleuchtung

- [x] Dunkler Nachthimmel und schwächeres Mond-/Grablicht eingerichtet.
- [x] Fensterlicht und sichtbare warme Hauslaterne als Lichtquellen ergänzt.
- [x] Gerichteter Lichtimpuls, Kontaktschatten, dezente Reflexionen und
      Lichtstreuung im Bodennebel eingerichtet.
- [x] Drei finale Standbilder visuell geprüft; Ergebnisse: `preview/v4/`.
- [ ] Kein neuer Videorender beauftragt.


### Videorender der dunklen Fassung (freigegeben)

- [x] Acht bewegte Beingelenke in der gespeicherten Szene überprüft.
- [x] 20-Sekunden-Video in 720p/24 fps mit Ton fertig gerendert.
- [x] MP4-Metadaten und zwölf dekodierte Bilder einschließlich Schrittstellungen geprüft.

Ziel: `preview/v4/halloween_dark.mp4`, bearbeitbare Szene
`preview/v4/halloween_dark.blend`. Das Renderprofil verwendet acht
EEVEE-Bildsamples und 16 Nebelsamples; Lichtquellen, Schatten und
Reflexionen der Bildfassung bleiben enthalten.

Der vollständige Render erfolgte mit freigegebenem Grafikkartenzugriff.


### Tonergänzung beim Herauskommen der Hand

- [x] Tiefes synthetisches Stöhnen mit kurzem Höhlennachhall ergänzt,
      Beginn bei 13,04 Sekunden, Ausklang bis etwa 16,6 Sekunden.
- [x] Bestehende Videobilder mit neuer Tonspur exportiert; 20 Sekunden,
      720p/24 fps und AAC-Spur geprüft. Ergebnis: `preview/v4/halloween_dark_groan.mp4`.
- [x] Separate bearbeitbare Blender-Datei mit gepackter Tonspur gespeichert.