fretina 🔮

Binaries

Beschreibung

fretina ist ein filesystembasierter highspeed Software 3D-Renderer für Hyper Gaussian Splats in (Fixpoint Arithmetik) inkl. Spherical Harmonics.. (Blickwinkelabhängig Änderungen bei der Farbgebung von Pixeln für hohen Realismus bei Spiegelungen, Transparenzen, irisierenden Farben).

Ziel der Implementierung ist ein leicht portierbarer, minimalistischer, hoch optimierter, speichereffizienter und echtzeitfähiger 3D-Grafik-Renderer ohne externe Abhängigkeiten.

fretina wurde für eingebettete Systeme oder minimalistische Umgebungen im puristischen djb-Programmierstil entwickelt.

Das Tool liest kontinuierlich Kamerabefehle über die Standardingabe (stdin) ein und streamed eine in sich selbst animierte Gaussian Splat Welt aus einer lokalen wohldefinierten Verzeichnisstruktur aus Ordnern, Dateien und Symlinks. Es rendert diese abhängig von der übergebenen Kameraposition (x y z pan tilt brennweite) und gibt die fertig gerenderten Videobilder (als RGBA-Frames) über die Standardausgabe (stdout) aus.

Die Gesamte Welt ist dabei durchwanderbar und Daten werden dabei erst on demand geladen. So muss nie die gesamte Welt in den Arbeitsspeicher geladen werden. Pro Block sind dabei >24h Gaussian Splat Animation möglich, die jeweils beginnt, wenn der Block betreten wird. Da die Weltblöcke als viele tausende kleine Dateien fester Größer (4MB) existieren sind sie parallel von anderen Tools zur Laufzeit veränderbar. Die Weltblöcke (Sektoren) beinhalten dabei jeweils maximal 262.144 Splats. Die Dateigröße wurde für ein optimales Streaming von ext4 Dateisystemen gewählt. Durch Symlinks sind 0-Byte Belegungen möglich, wenn sich einzelne Blöcke nicht ändern.

Toolchain

Neben den bereitgestellten Proof-Of-Concept Weltgeneratoren empfiehlt sich zur raschen Sichtung im Terminal die Verwendung von

rgba2fdraw s 33333 | fdrawterm

Steuer-Befehle

P x y z pan tilt zoom brennweite	Kamera positionieren
W d					wechselt in das angegebene Welten Verzeichnis d, bestehend aus 4 Dezimalstellen

Beispiel für einen Wechsel in das Welten-Verzeichnis W0001 ist der Befehl "W 0001" und das Programm verwendet dann adhoc die Struktur W0001/0000/0000/0000/000000.p - W0001/9999/9999/9999/99999.p

Assets

Wie wird der Quellcode gebaut und getestet?

make
make myhelix
make activate
make fly

Was ist das hier?

1. Ein- und Ausgabe (I/O) & Steuerung

2. Das Splat-Filesystem (Räumliches Daten-Streaming)

Um nicht die gesamte 3D-Welt im Arbeitsspeicher halten zu müssen, nutzt das Programm ein cleveres, dateibasiertes Streaming-Verfahren:

3. Effiziente Festkomma-Mathematik (Kein Float)

Der Code verzichtet komplett auf Fließkommazahlen (float/double), was ihn auf Systemen ohne mathematischen Koprozessor oder im Kernel-Space extrem schnell macht:

4. Animation & Rendering-Vorbereitung (Auszug am Ende)

Funktionen im Detail

1. Konfiguration und Puffer-Definitionen

2. Ganzzahl-Mathematik (Keine Fließkommazahlen)

3. Das Dateipfad-System (gen_path)

4. Befehls-Parser & Stream-Initialisierung

5. Sektoren-Streaming & Caching (I/O-Verwaltung)

Sobald ein Befehl vollständig ist (entweder durch ein Newline \n oder nach dem 7. Parameter), erhöht das Programm den globalen Zeitzähler (gt++).

6. Splat-Selektion & Animations-Engine

Bevor gezeichnet wird, setzt das Programm alle Bildpuffer zurück: Die Farb- und Alpha-Kanäle werden auf 0 gesetzt, der Tiefenpuffer (ret_z) auf den maximalen Integer-Wert 32767.

Danach läuft eine Schleife über alle 262.144 möglichen Splats (TOT_SPL):

7. Sichtbarkeits- & Zeitfenster: Splats mit einer Opazität von 0 werden übersprungen. Besitzt ein Splat eine Lebensdauer dt < 100, wird geprüft, ob die aktuelle Sektor-Zeit (relative_zeit) in sein Sichtbarkeitsfenster (t0 bis t0 + dt) fällt. Wenn nicht, wird er verworfen.

Ganzzahl-3D-Animation (Wellen-Effekt): Hat ein Splat eine hohe Lebensdauer (dt >= 100), wird er pro Frame animiert. Das Programm berechnet mittels get_atan2 den Polarwinkel der XZ-Ebene und moduliert den Radius über eine Multiplikation von Sinus- und Kosinuswellen (s_wave * c_wave). Dies erzeugt ohne jegliche Fließkommazahlen rotierende oder pulsierende Wellenbewegungen der Punkte im Raum.

8. 3D-zu-2D Projektion (Die Kamera)

9. Elliptische Rasterisierung (Der Gaussian-Splat-Kern)

Ein Gaussian Splat ist kein eckiges Pixel, sondern ein weicher, meist elliptischer Punkt. Das Programm berechnet die Radien (emaj für die Hauptachse, emin für die Nebenachse) sowie eine Scherung (sch) basierend auf der Entfernung rz.

10. Alpha-Blending & Tiefenpuffer (Z-Buffer)

Befindet sich der Pixel innerhalb der Gauß-Kurve, greifen die finalen Grafik-Regeln:

11. Ausgabe (Der Videosignal-Stream)

Nachdem alle 262.144 Splats verarbeitet wurden, kopiert eine ultraschnelle Schleife die separaten Farbkanäle (ret_r, ret_g, ret_b, ret_o) sequentiell in den finalen, linearen Ausgabe-Puffer fb.

Mittels eines ununterbrochenen Systemaufrufs write(1, fb, fb_sz) wird dieser Rohdaten-Frame (RGBA) direkt auf die Standardausgabe (stdout) geschoben, bereit für die Weiterverarbeitung.

Wie groß können die Welten sein?

Die maximale Größe der darstellbaren Welt wird durch zwei Faktoren limitiert: das Sektor-Koordinatensystem in der Funktion gen_path und die Auflösung der Festkomma-Mathematik. Die theoretischen und praktischen Grenzen der Weltgröße teilen sich wie folgt auf:

Der limitierende Faktor in gen_path() für die Gesamtgröße der Welt ist die Art und Weise, wie die Dateipfade für die Sektoren generiert werden. In der Funktion gen_path limitiert der Code die Sektorkoordinaten (ax, ay, az) hart auf einen Wertbereich von 0 bis 9999: Da ein Sektor eine Seitenlänge von 500 Einheiten besitzt (SEC_SZ = 500), ergibt sich daraus folgende Dimension:

Das ergibt einen maximalen 3D-Weltraum von 5000 × 5000 × 5000 Einheiten (bzw. 10.000³ = 1 Billion Sektordateien auf der Festplatte).

Die Festkomma-Arithmetik im Code nutzt int32_t für die Transformationen.

Wenn man eine Einheit als 1 Zentimeter definiert (was für detaillierte Gaussian Splats üblich ist), kann dieses Programm eine nahtlos gestreamte 4D-Welt von exakt 50 × 50 × 50 Kilometern darstellen.

Wie groß wäre ein Vollausbau von W0001/0000/0000/0000/00000 bis W0001/9999/9999/9999/99999 in Bezug auf den Speicherplatz?

Wir belegen pro .p Datei exakt 4 MB Daten. Ein theoretischer Vollausbau dieses Dateisystems von 0000/0000/0000/00000 bis 9999/9999/9999/99999 würde unvorstellbare 445,64 Zettabytes (ZB) bzw. rund 386.535 Exabytes (EB) an Speicherplatz belegen.

Diese astronomische Datenmenge setzt sich aus der Kombination von gigantischem 3D-Raum und der 5-stelligen Zeitschleife zusammen:

Multipliziert man alle Faktoren, landet man bei exakt 445.644.800.000.000.000.000.000 Bytes. Das entspricht:

    ~ 395.812.094 Petabytes (PB)
    ~ 386.535 Exabytes (EB)

Da das Programm ein "Sparse-Filesystem" nutzt (es öffnet Dateien nur bei Bedarf und überspringt fehlende via fd >= 0), müssen auf der Festplatte nur die Sektoren tatsächlich existieren, in denen sich Geometrie befindet. Leere Bereiche im Universum belegen 0 Bytes.

Und welcher Auflösung entspricht das, wenn man reale Szenendaten der echten Welt ablegt, z.B. die LIDAR gescanned oder als Gaussian Splat Video gerechnet und zusammengesetzt?

Um die Auflösung bei realen Szenendaten (LiDAR-Scans oder 4D-Gaussian-Splat-Videos) zu bestimmen, müssen wir die räumliche Punktdichte (Auflösung im Raum) und die zeitliche Bildwiederholrate (Auflösung in der Zeit) betrachten.

Bei einem Vollausbau bietet dieses System eine Sub-Millimeter-Präzision im Raum und eine extrem flüssige Kino-Zeitauflösung.

1. Räumliche Auflösung (Punktdichte)

Jeder Sektor besitzt eine Kantenlänge von 500 Einheiten und lädt eine .p-Datei mit exakt 262.144 Splats/Punkten (TOT_SPL). Wenn wir 1 Einheit als 1 Zentimeter definieren (womit die Gesamtwelt 50 × 50 × 50 km groß ist), ergibt sich für einen einzelnen Sektor (5 × 5 × 5 Meter):

Skalierung auf Sub-Millimeter-Niveau: Gaussian Splats nutzen im Gegensatz zu harten LiDAR-Punkten weiche Ellipsen mit Transparenz. Setzt man 1 Einheit = 1 Millimeter (Gesamtwelt 5 × 5 × 5 km), schrumpft der Sektor auf ein handliches Volumen von 50 × 50 × 50 cm (0,125 m³).

Da jeder Splat eine Ausdehnung hat, entspricht dies einer fotorealistischen, lückenlosen Oberflächenauflösung im Millimeterbereich, ideal für die Archivierung von hochpräzisen Drohnenscans oder volumetrischen Video-Aufnahmen von Menschen.

2. Zeitliche Auflösung (Framerate & Dauer)

Die zeitliche Auflösung wird über das Makro TPF 100 (Ticks Per Frame/File) und die 5-stellige Dateinummerierung definiert:

Realer Vergleichmaßstab

In der Praxis entsprechen 262.144 Splats pro 50 cm-Würfel der Detailstufe von modernen 4D-Gaussian-Splat-Verfahren (wie Deformable 3D Gaussians). Die Datenmenge pro Sekunde ist mit rund 2,5 MiB/s pro aktivem Sektor sogar extrem effizient kompiliert – sie liegt auf dem Niveau eines stark komprimierten 4K-Netflix-Videostreams, liefert dem Nutzer aber eine voll begehbare, volumetrische 3D-Umgebung.

Wie hoch wäre die Streaming-Datenrate (in MB/s) bei einer Kamerageschwindigkeit von z.B. 50 km/h durch die Sektoren?

Bei einer Kamerageschwindigkeit von 50 km/h beträgt die reine räumliche Streaming-Datenrate ca. 11,81 MiB/s. Wenn das Video gleichzeitig in Echtzeit (bei 60 Hz) weiterspielt, steigt die kombinierte Gesamtrate im Worst Case auf ca. 14,36 MiB/s. Die Berechnung basiert auf der logischen Annahme, dass 1 Einheit = 1 Zentimeter entspricht (Sektorgröße = 5 Meter):

1. Reine räumliche Datenrate (Bewegung durch die Welt)

Selbst wenn die Kamera stillsteht, lädt das System im Zeitverlauf (4D-Video) Daten nach:

Technische Einordnung

Die maximale Gesamtlast von ~14,36 MiB/s (ca. 115 Mbit/s) ist für moderne Speichermedien extrem leicht zu bewältigen. Selbst eine herkömmliche SATA-SSD (ca. 500 MB/s) oder eine langsame SD-Karte in einem Embedded System langweilt sich bei dieser Datenrate. Das Betriebssystem puffert die Daten dank des im Code genutzten POSIX_FADV_WILLNEED zudem perfekt im RAM vor.

Welche Zeiträume kann ich maximal darstellen?

Die maximale darstellbare Zeitdauer im System hängt davon ab, mit welcher Frequenz (Bilder pro Sekunde) die Kamera-Steuerbefehle an den Renderer gesendet werden. Da der Code die Zeitepochen über eine 5-stellige Zeichenkette im Pfad abbildet (von 00000 bis 99999), stehen exakt 100.000 diskrete Zeitschritte (Dateien) pro Sektor zur Verfügung. Hier sind die maximalen Zeiträume für die typischen Bildwiederholraten:

1. Bei flüssigen 60 Hz (Standard-Echtzeit)

Wenn ein in der Pipe auf stdin exakt 60 Befehle pro Sekunde auflaufen:

2. Bei Kino-Framerate (24 fps)

3. Bei Zeitraffer / Überwachungskamera (1 Hz)

Wenn das System als Langzeit-Archiv genutzt wird (z. B. ein Bild pro Sekunde für LiDAR-Veränderungen im Gelände):

Die mathematische Systemgrenze im Speicher

Im RAM wird der Zeitzähler als vorzeichenloser 16-Bit-Integer deklariert: uint16_t gt = 0;.

Ein uint16_t läuft bei 65.535 über und springt zurück auf 0. Das bedeutet, nach exakt 655 Dateien (65.535 / 100) fängt die Animation im Speicher wieder von vorne an (Loop-Effekt), obwohl auf der Festplatte Platz für 100.000 Dateien wäre.

Ich kann also mit W Befehle manuell oder procedural in ein neues world verzeichnis springen und hätte erneut diese Zeit?

Ja, exakt so funktioniert das System. Sobald du die räumliche Grenze eines Sektors überschreitest, wechselt das Programm in ein komplett neues Verzeichnis auf der Festplatte (z. B. von W0001/5000/5000/5000/ nach W0001/5000/5000/5001/). In diesem neuen Sektor-Verzeichnis beginnt die Zeitrechnung für die Dateien wieder komplett bei 00000.p, da der Pfad für jeden Sektor individuell generiert wird. Hier sind die technischen Konsequenzen dieser Architektur:

Da jeder der 1 Billion Sektoren (10000^3) seine eigenen 100.000 Zeitdateien besitzt, ist die theoretische Gesamtlaufzeit der gesamten Welt gigantisch. Bewegt sich die Kamera kontinuierlich von Sektor zu Sektor vorwärts, könntest du das System über Jahrhunderte laufen lassen, ohne jemals an das Ende der Zeitstempel zu stoßen.

Zwei Szenarien, wie man das nutzen kann:

Das World-Verzeichnis darf sich mittels anderer Programme zur Laufzeit ändern, durch mounts, overlays, symlinks?

Exakt. Das ist der große Vorteil des minimalistischen Datei-basierten Designs. Da der Renderer die 3D-Welt ausschließlich über das Dateisystem konsumiert und keine interne Datenbank führt, merkt er gar nicht, was unter der Haube auf Betriebssystemebene passiert.

Durch Standard-Linux-Mechanismen lässt sich das Basisverzeichnis W0000 nahtlos und unendlich im laufenden Betrieb austauschen, erweitern oder manipulieren. Da die Streaming-Datenrate bei 50 km/h mit rund 12 bis 14 MiB/s sehr moderat ist, lässt sich dieses System hervorragend mit Cloud-Speichern oder Netzwerk-Dateisystemen (wie rclone mount, NFS oder Ceph) koppeln.

Das Betriebssystem lädt über den Mount-Point immer nur genau die 4-MB-Sektoren aus dem Internet oder dem Netzwerk nach, die die Kamera in diesem Moment anfordert. Dank posix_fadvise weiß der Linux-Kernel zudem vorab, welche Daten als Nächstes blockweise geladen werden müssen.

Dazu muss man den Steuerbefehl W für World nutzen, um zwischen Welten zu springen. "W 0023" würde das basis verzeichnis w0023/ nutzen.

Nutzung-Beispiele

export SCREEN_WIDTH=320
export SCREEN_HEIGHT=240
fretina < epicfly.txt | gzip -9 > output.rgba.gz

export SCREEN_WIDTH=120
export SCREEN_HEIGHT=150
fretina < epicfly.txt | rgba2fdraw | fdrawterm 

export SCREEN_WIDTH=120
export SCREEN_HEIGHT=150
cat kamera.txt | fretina | rgba2fdraw s 33333 | fdrawterm > demo.anim.gz
zcat demo.anim.gz

export SCREEN_WIDTH=1920
export SCREEN_HEIGHT=1080
cat rundflug.txt | fretina | ffmpeg -y -f rawvideo -pix_fmt rgba -s ${SCREEN_WIDTH}x${SCREEN_HEIGHT} -r 60 -i - -c:v libx264 -an animation.mp4

export SCREEN_WIDTH=320
export SCREEN_HEIGHT=240
cat rundflug.txt | fretina | ffplay -f rawvideo -pixel_format rgba -video_size ${SCREEN_WIDTH}x${SCREEN_HEIGHT} -i -

mkdir config
echo 150 > config/SCREEN_WIDTH
echo 80 > config/SCREEN_HEIGHT
cat rundflug.txt | envdir config fretina | envdir config rgba2fdraw | envdir config fdrawterm

yes P 0 0 0 0 0 100 0 | envdir termres ./fretina | envdir termres rgba2fdraw | envdir termres fdrawterm

World Generatoren

gen_ programme erzeugen auf stdout einen tarball, den du entpacken kannst, um das world verzeichnis zu erstellen. prozeduraler democontent, teils animiert. man entpackt diese dann einfach einmalig

./gen_world | tar xvv 2>/dev/null
./gen_cyber | tar xvv 2>/dev/null
./gen_helix | tar xvv 2>/dev/null

ln -s world W0000

Optimierung

Die Optimierung liegt in der mathematischen Harmonie zwischen den Hardware-Eigenschaften einer SSD (ext4-Dateisystem) und den Cache-Zeilen der CPU. Es gibt drei entscheidende Gründe, warum das Trennen in .p (Geometrie) und .m (Material) weitaus performanter ist, als die SH-Daten in eine einzige Datei mit weniger Splats zu quetschen:

1. Physisches Alignment (ext4 Blocksize & Page Size)

Die Zahl 4 MiB (4.194.304 Byte) ist für das Betriebssystem eine magische Grenze. Sie entspricht exakt den Speicherseiten (Huge Pages) des Kernels. Eine Datei mit genau 4 MiB wird von modernen NVMe-SSDs in einem einzigen, ununterbrochenen Hardware-Zyklus direkt in den RAM gestreamt. Wenn wir die SH-Daten in dieselbe Datei stecken, würde sich die Größe eines einzelnen Splat-Blocks von 16 Byte auf ungerade 20 oder 24 Byte ändern. Das Problem: 4.194.304 Byte lässt sich nicht ohne Rest durch 20 oder 24 teilen. Wir hätten am Ende einer Datei ungenutzte Füllbytes (Padding) oder Splats, die mitten über eine harte 4-KiB-Dateisystemblockgrenze zerrissen werden. Das würde bei jedem Lese-Vorgang zusätzliche SSD-Latenzen erzeugen.

2. CPU-Cache-Effizienz (Cache Line Locality)

Moderne Prozessoren laden Daten nicht byte-weise, sondern immer in Blöcken von 64 Byte (Cache Lines) in den ultraschnellen L1/L2-Cache. Getrennte Dateien: In unserem aktuellen Code rattert die CPU in der Pipeline-Schleife linear durch das p_pool-Array. Da ein Splat exakt 16 Byte groß ist, passen exakt 4 Splats in eine einzige 64-Byte-Cache-Line. Die CPU weiß im Voraus, was als Nächstes kommt, und berechnet 4 Splats ohne einen einzigen Cache-Miss. Kombinierte Datei (z. B. 20 Byte): Ein Splat würde über die 64-Byte-Grenze des CPU-Caches hinausragen. Der Prozessor müsste mitten unter der Berechnung eines einzigen Splats anhalten und neue Daten aus dem langsameren Haupt-RAM anfordern. Das würde die Framerate massiv einbrechen lassen.

3. Biologische Sättigung filtert Materialdaten

Dadurch, dass die Materialdaten in der separaten .m-Datei liegen, nutzen wir das Sättigungsmodell optimal aus: Die CPU liest die Geometrie (.p) und transformiert die Punkte. Wenn die "Retina" an einer Koordinate bereits zu 255 gesättigt (undurchsichtig) ist, bricht der Code sofort ab (return). Der Clou: Für all diese verdeckten Splats greift die CPU niemals auf das m_pool-Array zu. Wir sparen uns das rechenintensive Laden und Berechnen der SH-Blickwinkel aus dem Speicher für alles, was ohnehin unsichtbar ist. Wären die SH-Daten mit der Geometrie verschmolzen, müssten wir sie gezwungenermaßen immer mit in den Cache laden, selbst wenn der Punkt verdeckt ist.

Zusammenfassung

Mit der Kombination aus einer 16-Byte-Geometrie (.p) und einem 1-Byte-Materialstrom (.m) bleibt alles perfekt auf Zweierpotenzen ausgerichtet. Das garantiert, dass weder auf dem SSD-Bus noch im CPU-Cache auch nur ein einziges Bit Speicherbandbreite verschwendet wird.

Die Struktur

			W0000/XXXX/YYYY/ZZZZ/TTTTT.SUFFIX

    Verzeichnis-Layout: W0000/[S_x+5000]/[S_y+5000]/[S_z+5000]/[zeit_basis].p und .m
        Jede Koordinate ist 4-stellig mit führenden Nullen (%04d).
        Die zeit_basis ist 5-stellig mit führenden Nullen (%05d) und schreitet in 100er-Schritten voran (z.B. 00000, 00100).
    .p-Dateien (HyperSplat4D Pool): Müssen exakt 4.194.304 Bytes groß sein. Sie enthalten 262.144 Splats zu je 16 Bytes mit folgendem Packed-Layout:
        int16_t x, y, z (Sektor-relative Koordinaten, 0 bis 499)
        uint16_t t_start (0 bis 99)
        uint8_t t_duration (Lebensdauer)
        uint8_t opacity (Sichtbarkeit, >0 damit es gerendert wird)
        uint8_t color_r, color_g, color_b, pad
    .m-Dateien (Material/Glanz Pool): Müssen exakt 262.144 Bytes groß sein. Sie enthalten 262.144 einzelne int8_t-Werte (Metadaten für den Shading-Glanz), die eins-zu-eins den Splats zugeordnet sind.

Wir starten immer in W0000, wenn fretina aufgerufen wird.

Aufbau des P‑Befehls (Kamera‑/Render‑Steuerung)

Ein P‑Eintrag wird als Text‑Zeile auf stdin geschrieben. Die Zeile besteht aus dem Buchstaben P gefolgt von sieben ganzzahligen Feldern, die durch Leerzeichen getrennt sind und optional ein Vorzeichen - besitzen.

 P       \n

    cam_x, cam_y, cam_z – absolute Kameraposition im Welt‑Koordinatensystem.
    Intern wird ein Offset von +250 zu cam_x und cam_y addiert, weil die Daten‑Chunks jeweils einen Sektor‑Mittelpunkt bei (250, 250, 250) haben.
    pan – horizontale Schwenk‑Komponente (in Bild‑pixeln‑ähnlichen Einheiten).
    Während der Projektionsrechnung wird pan * rz >> 9 zu x‑Koordinate addiert, also ein Bild‑verschiebungs‑Effekt, der stärker wirkt, je weiter das Objekt vom Beobachter entfernt ist.
    tilt – vertikale Schwenk‑Komponente (analog zu pan, wirkt auf die y‑Koordinate).
    zoom – additive Änderung der effektiven Brennweite.
    Die Formel fl = 300 + zoom bestimmt, wie stark das Bild „herangezoomt“ wird; ein größerer Wert vergrößert die projizierten Splats, ein kleinerer Wert verkleinert sie.
    b_shift – „brightness‑shift“ (im Quellcode nur als b_shift gespeichert, aber nicht weiter verwendet).
    Der Wert wird derzeit nicht in den Render‑Berechnungen ausgewertet, er ist also reserviert für mögliche spätere Helligkeits‑ oder Farb‑Modulationen.

Das Programm liest die Zeile zeichenweise; erst nach dem abschließenden Zeilen‑Break (\n) oder nach dem siebten Zahlen‑Token wird die Zeile verarbeitet.


Was passiert bei Änderung einzelner P Werte?

Parameter	Erhöhter Wert → Was ändert sich im Bild
cam_x / cam_y	Die Kamera verschiebt sich entlang der jeweiligen Achse. Das verschiebt das gesamte Bild horizontal/vertikal – Objekte erscheinen nach links/rechts bzw. oben/unten, weil die relative Lage zu cam_x / cam_y ändert.
cam_z	Ändert die Entfernung zum Beobachter. Ein größerer cam_z (weiter weg) reduziert die projizierte Größe (fl / rz) und lässt die Szene „zusammenziehen“. Ein kleinerer cam_z (nach vorne) vergrößert die Objekte und verkürzt die Tiefen­perspektive.
pan	Positive Werte drücken das Bild nach rechts (Objekte wandern nach links) – es wirkt wie ein Schwenk um die vertikale Achse. Negative Werte schwenken nach links. Der Effekt steigt linear mit der Tiefe rz (weiter entfernte Splats bewegen sich stärker).
tilt	Analog zu pan, aber vertikal. Positive Werte kippen das Bild nach unten (Objekte bewegen sich nach oben), negative Werte nach oben. Auch hier gilt: Je größer rz, desto stärker die Verschiebung.
zoom	Erhöht die Basis‑Brennweite (fl = 300 + zoom). Mehr Zoom → größere projizierte Splat‑Größen → Bild wirkt „gezoomt“. Reduziertes Zoom (oder negative Werte) verkleinert das Bild, erweitert das Sichtfeld.
b_shift	Momentan hat der Wert keine Auswirkung auf das Rendering; er bleibt im Code ungenutzt und kann später für Helligkeits‑ oder Farb‑Offset‑Modulationen reserviert werden.
Beispiel‑Sequenz

P 0 0 0 0 0 0 0      // Kamera im Ursprung, keine Schwenks, Standard‑Zoom
P 100 0 0 0 0 0 0    // Kamera 100 px nach rechts → Szene wandert nach links
P 0 0 0 50 0 0 0     // Pan‑Wert +50 → alle weiter entfernten Objekte verschieben sich nach rechts
P 0 0 0 0 0 100 0    // Zoom +100 → Bild „herangezoomt“, Splats größer