Kapitel 2 — Inspector (Expert View)

WO

Inspector → Presets-Sektion → Save…-Button (Action-Leiste unten).

TECHNISCH

Öffnet ein Popover mit Textfeld und Save-/Cancel-Buttons. Der aktuelle TrainingConfig-Zustand wird als neues benutzerdefiniertes Preset persistiert (JSON-codiert, App-übergreifend gespeichert). Der Save-Vorgang kopiert alle 81 Trainings-Parameter plus die aktuelle Densification-Strategie. Das Preset landet automatisch in der Kategorie Custom, unabhängig davon, von welchem Built-in-Preset es abgeleitet wurde. Leere Namen und reine Whitespace-Eingaben werden verworfen. Schon existierende Namen werden nicht abgewiesen — jedes Preset hat eine eigene interne ID, doppelte Namen sind technisch erlaubt, aber praktisch verwirrend.

WO

Save-Popover → Textfeld „Preset Name".

TECHNISCH

Einfaches Textfeld mit gerundetem Rahmen, breiter Form. Der Wert wird beim Klick auf den Save-Button als Preset-Name übernommen. Keine Längenbegrenzung im UI, aber der gespeicherte Name muss JSON-codierbar und in den UI-Listen darstellbar sein — Emoji und Umlaute funktionieren. Der Inhalt wird beim Öffnen des Popovers automatisch auf einen leeren String zurückgesetzt. Der Save-Button bleibt disabled, solange das Feld nach Trim leer ist. Es gibt kein Auto-Suggest und keine Vorbelegung mit dem Namen des gerade aktiven Presets.

WO

Save-Popover → Cancel-Button (links).

TECHNISCH

Schließt den Popover ohne Speichern. Verwirft den Textfeld-Inhalt — beim nächsten Öffnen wird er wieder durch die Save…-Button-Logik (I1) auf leer zurückgesetzt. Standard-Button-Style, keine Bestätigungs-Dialoge, keine Hotkeys. Die aktuelle TrainingConfig bleibt unverändert, da der Save-Pfad gar nicht ausgeführt wurde.

WO

Save-Popover → Save-Button (rechts, prominenter Stil).

TECHNISCH

Triggert die eigentliche Persistierung. Validiert nochmal nicht-leerer Name (defensiver Check) und schreibt dann die aktuelle TrainingConfig als JSON in den App-Speicher. Schließt anschließend den Popover. Blau hervorgehoben, ausgegraut solange das Textfeld leer ist. Wenn das Speichern fehlschlägt (z.B. weil der App-Speicher voll ist — sehr unwahrscheinlich), gibt es momentan keinen sichtbaren Fehlerdialog; das Preset würde dann beim nächsten App-Start einfach nicht erscheinen.

WO

Inspector → Presets-Sektion → Action-Leiste → Export…-Button.

TECHNISCH

Exportiert das aktuell ausgewählte Preset als .radiancepreset-Datei (intern JSON). Disabled, wenn kein Preset selektiert ist. Beim Klick öffnet die App einen Save-Dialog mit vorgegebenem Dateinamen (Preset-Name + .radiancepreset-Extension). Das gespeicherte Format enthält die komplette TrainingConfig plus Metadaten (Name, Kategorie, ID, Built-in-Flag). Doppelklick im Finder öffnet die App — aber nicht automatisch den Import; der Anwender muss den Import-Button (I6) verwenden.

WO

Inspector → Presets-Sektion → Action-Leiste → Import…-Button.

TECHNISCH

Öffnet einen Datei-Dialog, der nur .radiancepreset-Dateien zulässt (Mehrfachauswahl deaktiviert). Beim Auswählen wird die JSON-Datei geladen, validiert und in die Custom-Kategorie eingefügt — mit neuer interner ID, damit keine Kollisionen mit Built-ins entstehen. Der Import setzt automatisch die Kategorie auf Custom, selbst wenn das exportierte Preset ursprünglich z.B. ein Built-in war. Beschädigte oder mit einer älteren Schema-Version inkompatible Dateien werden stillschweigend abgewiesen, ohne Fehlerdialog (Console-Log gibt aber Auskunft).

WO

Inspector → Presets-Sektion → jede Preset-Zeile in jeder Kategorie.

TECHNISCH

Klick auf eine Preset-Zeile ersetzt alle Felder der TrainingConfig durch die Werte aus dem Preset, merkt sich die ID des aktiven Presets und setzt den Modified-Status zurück. Das Aktiv-Häkchen vor der Zeile erscheint nur, wenn das Preset ausgewählt UND unmodifiziert ist. Sobald ein Wert in der TrainingConfig geändert wird (Slider, Stepper, Toggle in den anderen Inspector-Sektionen), erscheint ein orangenes „Modified"-Badge hinter dem Namen. Eingebaute Presets können nicht überschrieben werden — bei Modifikation muss via Save-Button (I1) eine eigene Kopie angelegt werden.

WO

Rechtsklick auf jede Preset-Zeile → erster Eintrag „Export…".

TECHNISCH

Identische Funktionalität wie I5 (Export…-Button), aber bequemer erreichbar — ohne dass das Preset vorher selektiert sein muss. Exportiert direkt das in der Zeile angeklickte Preset. Funktioniert für alle Preset-Kategorien gleich (Built-in oder Custom), keine Einschränkung. Der Export enthält das Built-in-Flag und die Original- Kategorie, aber beim Re-Import wird die Kategorie wie unter I6 beschrieben auf Custom gemappt.

WO

Rechtsklick auf jede Preset-Zeile → zweiter Eintrag „Duplicate".

TECHNISCH

Klont das Preset in die Custom-Kategorie. Erzeugt eine neue interne ID, hängt „ Copy" an den Namen an und speichert die Kopie. Funktioniert auch für Built-in-Presets — der Klon ist dann editierbar. Das Original bleibt unangetastet. Die TrainingConfig wird Wert-für-Wert kopiert (JSON-Roundtrip), sodass keine Referenz-Bindungen zwischen Original und Kopie bestehen.

WO

Rechtsklick auf eigene Preset-Zeilen → letzter Eintrag „Delete" (rot, destructive).

TECHNISCH

Nur sichtbar für Custom-Presets. Built-ins lassen sich nicht löschen. Der Eintrag ist als destruktiv markiert, erscheint im Kontextmenü rot und wird hinter einem Divider abgesetzt, damit man ihn nicht versehentlich klickt. Es gibt keinen Confirmation- Dialog — ein Klick löscht das Preset sofort. Das gelöschte Preset ist nicht wiederherstellbar (Cmd-Z funktioniert hier nicht — Undo gibt es im aktuellen Build nur für die Bild-Liste, nicht für Preset- Operationen). War das gelöschte Preset gerade aktiv, bleibt die aktuelle TrainingConfig unverändert, nur die aktive Preset-Auswahl wird genullt.

WO

Inspector → Presets-Sektion → jeder Kategorie-Header (Classic, MCMC, SceneClass, Custom).

TECHNISCH

Klapp-Status pro Kategorie mit unterschiedlichem Default: Classic startet aufgeklappt, MCMC, SceneClass und Custom starten zugeklappt. Der Status wird nicht persistiert — bei App-Neustart sind alle Kategorien wieder im Default-Zustand. Der Chevron-Pfeil rotiert animiert. Die Zahl rechts im Header zeigt die Anzahl der Presets in dieser Kategorie. Die Klick-Hit-Area umfasst den ganzen Header-Bereich.

WO

Inspector → Trainingskonfiguration → Camera Alignment (segmentierter Picker oben).

TECHNISCH

Segmentierter Picker mit zwei Optionen: Apple Photogrammetry und Native (Beta). Die Auswahl bestimmt das verwendete SfM-Backend bei der nächsten Kamera-Rekonstruktion. Sie beeinflusst zugleich, welche weiteren Inspector-Elemente sichtbar sind: Native zeigt zusätzlich das FOV-Override (I13), das nur bei EXIF-losen Video- Frames gebraucht wird. Hinweis: für sehr große Outdoor-Aufnahmen kannst du das Ergebnis eines externen Tools (Metashape oder COLMAP) per Workspace-Import einspielen — siehe Kapitel 1 (M5) und Kapitel 9 (Q3, Q6).

WO

Inspector → Trainingskonfiguration → FOV Override (nur sichtbar bei Camera Alignment = Native).

TECHNISCH

Numerisches Textfeld (Range 0-170°), Default 0 = automatische Bestimmung aus EXIF oder Heuristik. Die manuelle Eingabe ist nötig, wenn die Eingabe-Bilder aus einem Video extrahiert wurden, das keine Brennweiten-Metadaten enthält. Typische Werte: iPhone Wide ≈ 73°, DJI Mavic Wide-Crop ≈ 70°, Drohne mit Vollformatsensor ≈ 84°. Der Wert wird auf [0, 170] geclampt — Werte außerhalb werden direkt zurückgestaucht. Wirkt sich nur auf die native SfM-Pipeline aus (Q4/Q5); Apple Photogrammetry ignoriert diesen Wert komplett.

WO

Inspector → Trainingskonfiguration → Densification (segmentierter Picker, immer sichtbar).

TECHNISCH

Schaltet zwischen den beiden Densification-Strategien: Classic (Original-3DGS-Verfahren mit Clone/Split/Prune und Gradienten-Threshold) und MCMC (Stochastic Gradient Langevin Dynamics mit Relocation, NeurIPS 2024). Beim Wechsel von Classic auf MCMC setzt die App die MCMC-spezifischen Felder automatisch auf erprobte Default-Werte (Reg-Weights = 0, MCMC-Cap- Multiplier 3.0, Sample-/Noise-Schedule). Ohne diese automatische Initialisierung litten Sessions mit alten Presets unter dem 1.4.4-MCMC-Collapse-Bug (460K→5 Gaussians, Watchdog-Kill). Die Picker- Auswahl bestimmt zusätzlich, welche Inspector-Elemente sichtbar sind — bei MCMC tauchen I16/I17 auf. Detaillierte Feld-Wirkung in Kapitel 6, T11–T16 (Classic) und T61–T73 (MCMC).

WO

Inspector → Trainingskonfiguration → MCMC Quality (nur bei Densification = MCMC).

TECHNISCH

Schaltet die Gradient-Accumulation auf 2 Schritte (aktiv) bzw. 1 Schritt (inaktiv). Akkumuliert die Gradienten aus zwei aufeinanderfolgenden Kamera-Views, bevor der Optimizer-Step ausgeführt wird. Empirisch (Session 33, V544a) reduziert das den finalen L1-Fehler um ca. 6% (0.0246 mit Quality vs 0.0261 ohne, bei 3-Trial-Average auf Horse-Full-MCMC). Der Preis: verdoppelte Trainingszeit. Bei sehr langen Trainings (200K Iterationen) führt das zu zusätzlichen 10+ Minuten Wartezeit — also nur dann lohnt, wenn die letzten paar Prozent Qualität wirklich gebraucht werden. Wirkt sich nur auf das Training aus, nicht auf das Export-Format oder die Viewport-Darstellung.

WO

Inspector → Trainingskonfiguration → Auto-scale by scene (nur bei MCMC).

TECHNISCH

Wenn aktiv, skaliert die effektive Max-Gaussians- Obergrenze mit der SfM-Init-Point-Count × MCMC-Cap-Multiplier (Default 3.0). Beispiel: SfM liefert 250K Initpunkte, Basis-Cap = 150K, Multiplier 3.0 → effektive Obergrenze = max(150K, 750K) = 750K. Wenn deaktiviert, gilt strikt nur die Basis. War für v1.4.5 eingeführt, weil große Outdoor-Aufnahmen mit über 1000 Frames und entsprechend hoher SfM-Punkt-Dichte mit der starren 150K-Cap-Default die Densification ausgehungert haben — überflüssige Punkte blieben, neue durften nicht entstehen. Default OFF in Custom-Presets, ON in MCMC-Built-ins. Wirkt sich nur zur Trainingszeit aus, nicht im Export.

WO

Inspector → Trainingskonfiguration → GroupBox → Max Iterations.

TECHNISCH

Stepper mit Range 1 000–100 000, Schrittweite 1 000. Bestimmt die Gesamtzahl der Optimizer-Iterationen. Linear korreliert mit der Trainingszeit (Halbierung = ca. 50% Zeit). Empirische Sweet-Spots: 20K (Classic Balanced, L1≈0.028), 40K (Classic Quality, L1≈0.023), 200K (MCMC Full, L1≈0.0246). Über 40K bei Classic bringt im Mittel kaum Verbesserung — Diminishing Returns. Beim Verändern wird, falls die Link-Funktion (I19) aktiv ist, Densify Until proportional mitgezogen (Default-Ratio: 0.5, d.h. Densify-Until = Max/2).

WO

Inspector → Trainingskonfiguration → GroupBox → kleiner Link-Button zwischen Max Iterations und Densify Until.

TECHNISCH

Toggle-Button, der das Verhältnis von Densify Until zu Max Iterations einfriert. Bei Aktiv (Link-Icon hervorgehoben) wird bei jeder Änderung von Max Iterations das Densify Until proportional nachgezogen. Beim Unlink (Link-Plus-Icon) bleiben die Werte unabhängig. Default ist linked, weil das die typische Korrelation widerspiegelt — wenn du das Training auf doppelte Iterationen ziehst, willst du meistens auch die Densification proportional länger laufen lassen. Das Verhältnis wird beim Setzen des Link-Buttons aus dem aktuellen Wert berechnet; ein typisches Verhältnis ist 0.5 (Densify-Until = halbe Iterations-Zahl).

WO

Inspector → Trainingskonfiguration → GroupBox → Densify Until.

TECHNISCH

Stepper mit Range 500–50 000, Schrittweite 500. Bestimmt den Iterations-Index, ab dem keine neuen Gaussians mehr durch Clone/Split (Classic) oder Relocation (MCMC) hinzukommen. Nach Erreichen werden nur noch Position und Farbe verfeinert. Höhere Werte = mehr Gaussians = größere Datei, längere Pro-Iteration-Zeit (+30-60% GPU-Time pro Schritt). Typische Werte: 15K (für 30K Max-Iter), 20K (für 40K), 100K (für 200K MCMC). Bei aktivem Link (I19) automatisch mitskaliert. Wirkt sich anders bei Classic vs MCMC aus: Classic stoppt komplett das Wachstum, MCMC stoppt die Relocation-Logik, aber Sample-/Noise-Adaption läuft weiter.

WO

Inspector → Trainingskonfiguration → GroupBox → SSIM Weight.

TECHNISCH

Slider 0.0–1.0 in 0.05-Schritten, Anzeige als „0.20". Mischt L1-Loss (0.0) und SSIM-Loss (1.0). L1 strafft die Helligkeit pro Pixel, SSIM die strukturelle Ähnlichkeit (Kanten, lokale Statistiken). Default 0.2 ist der Wert aus dem Original-3DGS-Paper (Kerbl 2023) und reverse-engineered als robuster Kompromiss in zahlreichen Sessions. Höhere Werte (0.5+) bevorzugen Detailerhalt, können aber lokale Helligkeitsfehler ignorieren. Niedrigere Werte (< 0.1) führen zu Detail-Verlust an scharfen Kanten. Die SSIM- Berechnung läuft im Shader mit einem 11×11-Gaussian-Window. Performance: Bei 0.0 (nur L1) ist das Training ca. 8-12% schneller, weil die SSIM-Berechnung im Shader übersprungen wird.

WO

Inspector → Trainingskonfiguration → GroupBox → Render Scale.

TECHNISCH

Slider 0.25–1.0 in 0.25-Schritten, Anzeige als „100%". Skaliert die Trainings-Rendering-Auflösung relativ zur Quellbild-Größe. Größter Hebel auf die Performance: 50% reduziert GPU-Zeit um ca. 75% (weil 4× weniger Pixel), 25% um ca. 94%. Der Gradient-Threshold wird automatisch mitskaliert. Unter dem Slider erscheint eine Live-Resolutions-Anzeige in MP (z.B. „2304×1296 (3.0 MP)"). Falls der aktuelle Wert vom empfohlenen abweicht, wird in oranger Schrift „— recommended: 50%" eingeblendet. Die Empfehlung zielt auf ~3 MP effektive Auflösung — der von Apple Silicon GPUs am effizientesten verarbeitbare Bereich. 4K-Quellbilder bekommen z.B. automatisch 25% empfohlen, FullHD-Bilder 100%. Eine Änderung triggert zusätzlich die Buffer-Reallokation.

WO

Inspector → Enhancements → Post-Training Compactification.

TECHNISCH

Aktiviert das V443-Post-Processing: Nach Abschluss der Trainings-Iterationen werden Gaussians mit Opacity unter 0.01 (1% Sichtbarkeit) gelöscht. Empirisch reduziert das die Datei-Größe um ~55-58% bei null sichtbarem Qualitätsverlust — weil diese Gaussians visuell ohnehin nicht beitragen. Die Compactification läuft als GPU-Compact-Pass und dauert je nach Gaussian-Count Sekundenbruchteile bis wenige Sekunden. Beeinflusst die Trainings-Performance nicht. Wenn dieser Toggle aus ist, werden auch invisible Gaussians exportiert — relevant nur, wenn du das Format für ein weiteres Training-Stage gebrauchen willst (Continue Training), sonst Verschwendung von Speicher.

WO

Inspector → Enhancements → MetalFX Spatial Upscaling.

TECHNISCH

Aktiviert Apples MetalFX Spatial Upscaler im Viewport-Renderer. Wenn die Trainings-Auflösung (durch I22 Render Scale) niedriger ist als die Viewport-Größe, skaliert MetalFX das gerenderte Frame ML-basiert auf die Anzeigegröße hoch. Liefert die schärfsten Ergebnisse aller Skalierungs-Optionen, weil das ML-Upscaler-Modell auf scharfe Kanten optimiert ist. Die Renderer-Pipeline wird beim Umschalten live umkonfiguriert — sichtbar sofort, ohne Neustart. Hat Vorrang vor MPS Lanczos (I28): Sind beide aktiv, gewinnt MetalFX. Performance- Overhead im Viewport ca. 1-2ms pro Frame auf M3-GPUs. Wirkt nur auf das Live-Viewport, nicht auf gerenderte Exporte (Orbit-Video, Screenshots) — die werden in voller Quell-Auflösung gerendert.

WO

Inspector → Enhancements → MPS Lanczos Scaling.

TECHNISCH

Aktiviert Apples Metal Performance Shaders mit Lanczos-Resampling als Viewport-Upscaler. Lanczos ist klassisches Resampling mit 8-Tap-Sinc-Filter — schärfer als Bilinear, klassischer Algorithmus ohne ML. Die Renderer-Pipeline wird beim Umschalten live neu konfiguriert. Wird ignoriert, wenn MetalFX (I27) ebenfalls aktiv ist. Minimal-Overhead (<0.5ms pro Frame), aber Qualität liegt unter MetalFX. Anwendung: Fallback für Szenen, in denen MetalFX Artefakte produziert (z.B. starke Linien-Strukturen, die der ML-Upscaler gelegentlich „glattbügelt"). Wirkt wie I27 nur im Live-Viewport, nicht in Exporten.

WO

Inspector → Enhancements → Perceptual Loss.

TECHNISCH

Slider 0.0–0.2 in 0.01-Schritten, Anzeige bei 0.0 als „Off", sonst als „0.05" usw. Aktiviert einen zusätzlichen Loss-Term, der multi-skalierten Gaussian-Blur des Renderings mit dem Ground-Truth-Bild vergleicht (3 Blur-Skalen). Fängt strukturelle Unterschiede ein, die L1+SSIM allein nicht erkennen. V460-Implementierung. Empirisch verbessert ein Wert von 0.05-0.1 den L1-Score in Sessions um ein paar Prozent, kostet aber ~5% Trainingszeit (zusätzlicher Forward-Pass durch die Blur-Kernel). Über 0.15 wird das Training instabil und L1 verschlechtert sich wieder (Loss-Term dominiert die Optimierung). Wirkt während des Trainings, nicht im Post-Processing — trotz Position in der „Enhancements"-Sektion ist das also keine reine Aufwertung im Nachgang.

WO

Inspector → Metriken → Iteration. Read-only.

TECHNISCH

Anzeige im Format „4523 / 40000" — aktuelle Iteration über totale geplante Iterationen. Zählt synchron mit dem Trainings-Loop, der die Werte alle ~30 Iter pushed. Die zweite Zahl entspricht dem Max-Iterations-Wert zum Start-Zeitpunkt; sie ändert sich nicht mehr, auch wenn der Anwender den Stepper danach verstellt — der laufende Lauf nutzt seine eigene Snapshot-Kopie. Wenn die App über das Training-Menü Iterationen draufschiebt (Continue Training +5K/+10K/+20K), erhöht sich der Nenner.

WO

Inspector → Metriken → Loss. Read-only.

TECHNISCH

Float-Wert mit sechs Nachkommastellen (z.B. „0.024385"). Misst den kombinierten L1+SSIM-Loss (Mix kontrolliert über I21 SSIM Weight) plus optional Perceptual Loss (I29) und andere Regularizer. Skala ist nicht absolut, sondern szenenabhängig — verlangt für die meisten Vergleiche denselben Datensatz. Typische Endwerte bei guten Konfigurationen: - Classic Quality 40K iters: 0.022–0.025 (Horse, Truck, Garden) - MCMC Full 200K iters: 0.024–0.028 - Outdoor Drohne 30K: 0.030–0.060 (geometrie-bedingt schlechter) - Indoor Apartments: 0.018–0.025

Werte über 0.10 nach 5K Iterationen deuten auf SfM-Probleme (schlechte Kamera-Posen) hin — abbrechen und SfM neu rechnen.

WO

Inspector → Metriken → Learning Rate. Read-only.

TECHNISCH

Scientific-Notation-Anzeige (z.B. „1.60e-04"). Aktuelle Lernrate für die Position-Parameter (3DGS hat sechs unabhängige LRs für Position, SH-DC, SH-Rest, Opacity, Scale, Rotation — angezeigt wird hier die Position-LR als repräsentative Größe). Default-Anfangswert 1.6e-4, der über einen Exponential-Decay bis ~1.6e-6 am Trainingsende absinkt. Der Verfall ist über das LR-Schedule-Feld in der Trainings- Konfiguration (T-Feld in Kap. 6) anpassbar. Wenn die LR ungewöhnlich hoch bleibt (z.B. 1e-3 oder mehr nach 10K Iterationen), könnte das auf eine fehlerhaft geladene Konfiguration hinweisen.

WO

Inspector → Metriken → SH Degree. Read-only.

TECHNISCH

Ganzzahl 0-3. Spherical-Harmonics-Grad für die Farb-Repräsentation. Beginnt bei 0 (nur die DC-Komponente, d.h. richtungs-unabhängige Farbe pro Gaussian — also nur eine RGB-Konstante) und steigt im Verlauf des Trainings progressiv auf 3 an. Der Standard-Schedule hebt den Grad bei 1000/2000/3000 Iterationen um je 1. SH-3 entspricht 48 Farb-Koeffizienten pro Gaussian (3 RGB-Channels × 16 SH-Basisfunktionen). Höherer SH-Grad = mehr richtungs-abhängige Reflexion (glänzende Oberflächen sehen unter verschiedenen Blickwinkeln korrekt unterschiedlich aus), aber auch mehr Speicher und langsameres Training.

WO

Inspector → Metriken → Gaussians. Read-only.

TECHNISCH

Aktuelle Anzahl der Gaussians im Modell, formatiert mit Locale-Separator (z.B. „524.318"). Wachstum: - Classic: startet bei den SfM-Init-Punkten (typisch 50K-300K), wächst durch Clone/Split bis kurz vor Densify Until, dann statisch bis Trainingsende (modulo Pruning) - MCMC: Sample-Punkte werden hinzugefügt bis zum MCMC-Cap, dann nur noch Relocation

Healthy Endwerte: - Classic Quality: 400K-700K (Horse 524K, Garden 800K) - MCMC Full: exakt auf dem Cap (Default 150K, mit Auto-Scale Multiplier × SfM-Count je nach Szene 500K-1.5M)

Bei MCMC fällt die Zahl auf < 60% des Caps → Anomalie (Collapse-Indikator, deutet auf zu aggressive Regularizer hin).

WO

Inspector → Metriken → GPU Memory. Read-only.

TECHNISCH

Schätzung des Gaussian-Buffer-Speicherverbrauchs als Gaussian-Count × 616 Bytes (formatiert im Memory-Style). 616 Bytes ist die empirische Größe eines voll ausgestatteten Gaussians (Position, Skalierung, Rotation, Opacity, SH-Koeffizienten Grad 3, Gradient- Akkumulator). Die Anzeige erfasst nicht den Renderer-Overhead (Tile-Buffer, Sort-Buffer, Backward-Buffer) — der reale GPU- Speicherbedarf liegt typisch 2-3× über diesem Wert. Bei 500K Gaussians: angezeigt ~290 MB, real ~700 MB. Bei 1.5M Gaussians: angezeigt ~880 MB, real ~2.5 GB. Auf M3 Max mit 64+ GB Unified Memory unkritisch, auf M3 Pro mit 18 GB schon ein Limit.

WO

Inspector → Metriken → Speed. Read-only.

TECHNISCH

Iterations-pro-Sekunde mit einer Nachkommastelle („24.3 it/s"). Berechnet vom Trainer als gleitender Durchschnitt über die letzten ~100 Iterationen. Typische Werte: - Quick Preset (1K iters): 80-120 it/s (kurz, kein steady-state) - Classic 20K @ 1.0 Render Scale (Truck-Szene, M3 Max): 25-35 it/s - Classic 20K @ 0.5 Render Scale: 80-120 it/s - MCMC 200K @ 0.5 Render Scale: 25-50 it/s (langsamer wegen Relocation) - Bei 1M+ Gaussians und voller Auflösung: < 10 it/s

Sinkende Speed im Verlauf des Trainings ist normal — mehr Gaussians = mehr Compute pro Iteration. Plötzliche Einbrüche (z.B. von 30 → 5 it/s) deuten auf GPU-Thermal-Throttling oder konkurrierende Apps hin.

WO

Inspector → Metriken → Elapsed. Read-only.

TECHNISCH

Bereits vergangene Zeit als „4:23" (m:ss) oder „1:23:45" (h:mm:ss). Format-Switch ab 1 Stunde. Misst nur die reine Trainings-Zeit, nicht die vorgelagerten Phasen (SfM-Berechnung, Bild- Import). Bei Pause/Resume läuft die Uhr weiter — ist also wall-clock, nicht CPU-Zeit.

WO

Inspector → Metriken → ETA. Read-only.

TECHNISCH

Geschätzte Restzeit als „17:42" oder „1:12:35". Berechnung: (Max Iterations − aktuelle Iteration) / Iterationen-pro- Sekunde. Zeigt „–", wenn die Speed gerade null ist (ganz am Anfang oder bei Pause). Die Schätzung wird nicht an die typische Verlangsamung gegen Trainingsende angepasst — gerade bei MCMC und Classic mit großen Densify-Until-Werten neigt das Training dazu, langsamer zu werden, weil immer mehr Gaussians ins Bild kommen. Real bleibt es typischerweise 10-20% über der Anfangs-ETA.

WO

Inspector → Verlust-Diagramm → linker Label-Bereich „Current: 0.0287". Read-only.

TECHNISCH

Float-Wert des letzten Loss-Sample-Punkts, formatiert mit vier Nachkommastellen. Identisch mit I31 (Loss in der Metrics-Sektion), nur hier kompakter formatiert. Quelle ist die Loss- History — eine Liste, die pro ~30 Iterationen einen Eintrag bekommt. Nur endliche Werte werden in die Liste aufgenommen — NaN/Infinity (sehr selten, im Falle eines Gradient-Explosion-Bugs) werden gefiltert.

WO

Inspector → Verlust-Diagramm → rechter Label-Bereich „Min: 0.0245" (grün). Read-only.

TECHNISCH

Minimum aller jemals gesehenen Loss-Werte des aktuellen Trainings-Laufs. Wird live aus der Loss-History rekomputiert — keine separate Persistenz. Wird mit grüner Schrift dargestellt, weil „Min" = „Best so far". Die gestrichelte grüne Linie am unteren Chart-Rand markiert diese Y-Position visuell. Bei Continue-Training- Sessions startet die Mindest-Verfolgung neu — die alte History wird in der UI durch die neue ersetzt (nicht angehängt). Wenn das aktuelle Training schlechter als das vorhergehende läuft, kann die Min-Anzeige also größer sein als das vorherige Endergebnis.

WO

Inspector → Verlust-Diagramm → zweites Chart darunter (orange). Read-only.

TECHNISCH

Linien-Diagramm der Gaussian-Anzahl über die Trainings-Iterationen. Quelle: die Gaussian-Count-History (Liste von (Iter, Count)-Paaren, gefüllt vom Trainer alle ~30 Iter). Y-Skala dynamisch zwischen Minimum und Maximum der History. Bei Classic- Strategie sieht die Kurve typischerweise so aus: stetig steigend bis Densify Until, dann flach (mit kleinen Pruning-Schwankungen). Bei MCMC: steiler Anstieg bis Cap, dann horizontale Linie (Relocation hält die Zahl konstant). Wenn die Kurve fällt trotz aktivem Training, prunt die Densification zu aggressiv — Indiz für falsche Defaults oder ein bekannter MCMC-Collapse-Bug (v1.4.4-Hotfix-Thema).