Blender VSE versehentlich benutzt

• Aras wusste nicht einmal, dass Blender einen Video Sequence Editor (VSE) hat, trug aber nach einem Besuch im Blender HQ rund zwei Monate lang in Teilzeit zu Verbesserungen bei Performance und Qualität für Blender 4.1 bei
• Die auffälligste Änderung ist die Reaktionsfähigkeit der Timeline: Im Sprite-Fright-Projekt, in dem etwa 3000 Strips sichtbar sind, wurde die Scroll- und Panning-UI von rund 15 fps auf über 60 fps verbessert
• Auf ffmpeg basierende RGB↔YUV-Konvertierung, Audaspace-Audio-Resampling, Bildtransformation und -filterung sowie die Verarbeitung von VSE-Effekten erhielten Multithreading, SIMD und vereinfachte Mathematik
• Auf drei Blender-Studio-Datensätzen wurde die finale Renderzeit von VSE-Filmen auf dem PC des Autors etwa halbiert; das Rendering von Sprite Fright sank von fast 13 Minuten auf 7 Minuten
• Insgesamt wurden 37 Pull Requests geprüft und zusammengeführt; die Änderungen für Blender 4.1 fließen derzeit ein, weitere VSE-Arbeiten sollen ab Blender 4.2 folgen

---

Wie es zur Mitarbeit am Blender VSE kam

• Aras reiste wegen Unite 2023 von Unity nach Amsterdam und besuchte in seiner freien Zeit das Blender HQ
• Dort fragten Francesco und Sergey, ob er zum VSE beitragen wolle, woraufhin er begann, am Video Sequence Editor von Blender zu arbeiten
• Obwohl er sich mit Videoschnitt, Timelines, Sequencern, Color Grading, ffmpeg und Audio-Mixing kaum auskannte, begann er mit relativ unumstrittenen Performance-Optimierungen
• Nach etwa zwei Monaten Teilzeitarbeit entstand ein Paket von Verbesserungen für Blender 4.1
  • Blender 4.1 ist nun in der Beta und kann über die normalen Daily Builds heruntergeladen werden

Timeline-Zeichnung und Reaktionsfähigkeit der UI

• Die VSE-Timeline ist der Bereich am unteren Rand des Bildschirms; im vollständig herausgezoomten Gesamtprojekt Sprite Fright edit sind auf einmal etwa 3000 Strips sichtbar
• Zuvor blieb die UI allein beim Scrollen oder Pannen in dieser Timeline bei etwa 15 fps
• Nach den Änderungen läuft sie mit über 60 fps
  • Zugehöriger PR: #115311
• Der Flaschenhals war eine Struktur, die Draw Calls an die Grafik-API in Einheiten von jeweils zwei Dreiecken übermittelte; im Superluminal-Profiler floss die meiste Zeit in die Funktionen für „Beginn des Zeichnens eines Quads“ und „Ende des Zeichnens eines Quads“
• Dabei wurden auch Fehlfunktionen bei der Anzeige von Audio-Wellenformen behoben und die UI überarbeitet; die Wellenformanzeige ist nun standardmäßig aktiviert
  • Zugehöriges Issue: #115274

Verbesserungen bei Qualität und Geschwindigkeit der Scope-Anzeigen

• Das VSE bietet übliche Scope-Anzeigeoptionen wie Bildhistogramm, Waveform und Vectorscope
• Das Histogramm wurde zuvor pixelig und mit sehr starker Sättigung gezeichnet, wird nun aber mit glatteren Polygonen, Raster und geringerer Sättigung dargestellt
  • Zugehöriger PR: #116798
• Die Parade-Option der Waveform hatte das Problem, zu schnell zu sättigen, und wurde nach Einführung von Multithreading 15-mal schneller
  • Zugehöriger PR: #115579
• Das farbige äußere Hexagon des Vectorscope war stark pixelig; dafür wurde das aktualisierte Design des Vectorscope im Bildeditor übernommen
  • Zugehöriger PR: #117738
• Auch die Option Zebra Stripes zur Anzeige überbelichteter Bereiche wurde 2- bis 3-mal schneller
  • Zugehöriger PR: #115622
• Er ergänzt, dass alle Scopes sowie die Scopes des Bildeditors irgendwann per GPU-Compute-Shader verarbeitet werden sollten

Optimierung der ffmpeg-RGB↔YUV-Konvertierung

• Blender verwendet für das Lesen und Schreiben von Audio und Video hauptsächlich die Bibliotheken von ffmpeg
• Intern nutzt Blender dabei nicht das ffmpeg-Kommandozeilentool, sondern Code-Bibliotheken wie libavcodec; libswscale ist für die RGB↔YUV-Konvertierung von Filmframes zuständig
• libswscale unterstützt Multithreading bei Konvertierungen, läuft aber vollständig single-threaded, wenn man einfach sws_getContext() und sws_scale() verwendet
• Um Multithreading zu nutzen, muss beim Initialisieren der Parameter "threads" gesetzt werden; daher mussten sws_alloc_context(), av_opt_set_int() und sws_init_context() direkt verwendet werden
• Außerdem nutzt sws_scale() intern kein Multithreading, sodass stattdessen sws_scale_frame() nötig war; dabei kam auch ein Problem bei der Erzeugung von AVFrame ans Licht
• Dadurch wurde die RGB→YUV-Konvertierung beim Schreiben von Filmdateien deutlich schneller
  • Zugehöriger PR: #116008
• Auch beim Lesen von Filmdateien wird nun multithreaded YUV→RGB-Konvertierung verwendet und das vertikale Spiegeln in denselben Arbeitsschritt integriert
  • Zugehöriger PR: #116309

Audio-Resampling

• Beim Rendern von Videos im VSE zeigte sich, dass fast die Hälfte der Zeit für das „Erzeugen von Video- oder Audioframes“ innerhalb der von Blender verwendeten Audiobibliothek Audaspace verbraucht wurde
• Der Flaschenhals war nicht die Audio-Kodierung, sondern das Mischen vor dem Kodieren; der Großteil entfiel auf Resampling, wenn in einem 48-kHz-Film Audiostrips mit etwa 44,1 kHz gemischt waren
• Audaspace hatte zwei Resampling-Modi
  • Wiedergabe innerhalb von Blender: Linear Resampler mit linearer Interpolation zwischen Samples
  • Film-Rendering: ein Resampler auf Basis von Julius O Smith’s algorithm
• Die Resampler-Qualität wurde verglichen, indem ein synthetischer Ton mit ansteigender Einzelfrequenz resampelt und anschließend das Spektrogramm betrachtet wurde
  • Ziel war ein Ergebnis mit möglichst wenigen zusätzlichen Frequenzen, ähnlich der Einstellung „best“ in Audacity
• Das Preview-Resampling von Audaspace war rechnerisch schnell, erzeugte aber viele zusätzliche Frequenzen, während das Rendering-Resampling im Spektrogramm eine gute Qualität zeigte
• Für Audaspace wurde eine neue mittlere Resampling-Qualität ergänzt; nach Ansicht des Autors liefert sie nahezu das gleiche Ergebnis, ist aber etwa dreimal schneller
• Blender verwendet diese mittlere Einstellung nun beim Rendern
  • Auf einem Windows-PC mit Ryzen 5950X sank das Rendering von 2000 Frames aus Sprite Fright von 92 Sekunden auf 73 Sekunden
  • Zugehöriger PR: #116059

Bildtransformation und -filterung

• Strips im VSE, die visuelle Ergebnisse erzeugen, etwa Bilder, Filme, Text oder Szenen, können Position, Rotation, Skalierung und Zuschnitt anwenden
• Diese Transformationen arbeiten, indem das vom Strip erzeugte Bild in ein neues Bild transformiert wird; die Verarbeitung lief bereits zuvor multithreaded auf der CPU
• Dass dies nicht auf der GPU, sondern auf der CPU geschieht, liegt daran, dass es bislang keine GPU-Implementierung gibt und derzeit für Renderfarmen ohne GPU noch ein CPU-Fallback nötig ist

• Korrektur von Half-Pixel-Fehlern

  • Im bisherigen Code gab es mehrere Fehler um ein halbes Pixel, die sich oft gegenseitig aufhoben oder unsichtbar blieben, in bestimmten Situationen aber sichtbar wurden
  • Beim 16-fachen Vergrößern eines kleinen Bildes verschob der Bilinear-Filter das Bild um ein halbes Originalpixel, wodurch die Hintergrundfarbe Magenta hineinsickerte
  • Umgekehrt trat beim exakten Verkleinern eines Bildes auf die Hälfte das Problem auf, dass der Bilinear-Filter überhaupt keine Filterung anwandte
  • Diese „off by something“-Fehler bei Bilinear und anderen Filtern wurden behoben
  • Zugehöriger PR: #116628

• Behandlung transparenter Ränder bei Bilinear

  • Im VSE vor Blender 4.0 gab es drei Filteroptionen: Nearest, Bilinear und Subsampled3x3; nur Bilinear fügte rund um das Ergebnisbild eine Transparenz in der Breite eines halben Original-Texels hinzu
  • Dieses Verhalten fiel beim Vergrößern von Medien deutlich auf, und niemand erinnerte sich daran, warum es diesen Unterschied überhaupt gab
  • Im Bilinear-Filtercode des VSE wurde dieses Verhalten des „Blendens in Transparenz“ entfernt
  • Da die bisherige Transparenzbehandlung bei reiner Rotation an den Kanten eine Art Antialiasing erzeugte, wird stattdessen auf die Randpixel des Zielbilds Transparency Anti-Aliasing angewandt
  • Zugehöriger PR: #117717

• Cubic-, Box- und Auto-Filter

  • Für normale Strip-Transformationen im VSE gab es keine Cubic-Filteroption; sie existierte nur im speziellen Transform-Effect-Strip
  • In Blender bedeutet „Bicubic“ tatsächlich einen Cubic B-Spline-Filter und entspricht den Mitchell-Netravali-Koeffizienten B=1, C=0
  • Der Autor beschreibt dies als eine Wahl „ohne Ringing, aber mit viel Blur“
  • Ins VSE wurden zwei Arten von Cubic Filtering aufgenommen
  • Zugehörige PRs: #117100, #117517
  • Der Filter „Subsampled 3x3“ in Blender 3.5 war in Wirklichkeit ein fest auf 3x3 kodierter Box-Filter und begann bei Verkleinerungen in anderen Verhältnissen zu versagen
  • Dieser Filter wurde durch einen angepassten Box-Filter statt eines festen 3x3-Filters ersetzt
  • Zugehöriger PR: #117584
  • Weil Nutzer nun zwischen mehr Filtern wählen müssten, wurde als Standard für VSE-Strips eine Auto-Filteroption ergänzt
  • Zugehöriger PR: #117853
  • Ohne Skalierung oder Rotation: Nearest
  • Bei Vergrößerung um mehr als das Doppelte: Cubic Mitchell
  • Bei Verkleinerung um mehr als das Doppelte: Box
  • Andernfalls: Bilinear

• Verbesserungen bei der Filter-Performance

  • Auch die Bildfilterung selbst wurde schneller
  • Entfernung virtueller Funktionen in inneren Schleifen, teilweise SIMD für Bilinear-Filterung: #115653
  • Vereinfachung der Cubic-Filterung und Ergänzung von SIMD: #117100
  • Vereinfachte Mathematik für den Box-Filter: #117125
  • Ein Problem wurde behoben, bei dem die Optimierung zum Überspringen von Elementen unterhalb eines vollflächigen, einfarbigen Bildes bei Skalierung nicht funktionierte: #117786
  • Auf dem PC des Autors sank in einem 3840x2160-Projekt mit einem auf das Doppelte vergrößerten 1920x1080-Bild und Bilinear-Filterung die vollständige Darstellung der Sequencer-Vorschau von 36,8 ms auf 15,9 ms
  • Zusätzlich gibt es eine interaktive Seite zum Vergleich von Upsampling-Filtern: aras-p.info/img/misc/upsample_filter_comp_2024

Optimierung von VSE-Effekten

• In den realen Filmdatensätzen von Blender Studio wurden Effekte zwar nicht stark genutzt, dennoch wurden VSE-Effekte anhand der im Code sichtbaren Stellen optimiert
• Die meisten Änderungen bestanden aus der Einführung von Multithreading
  • Glow-Effekt: Multithreading eingeführt, 6- bis 10-mal schneller #115818
  • Wipe-Effekt: Multithreading eingeführt, übermäßige trigonometrische Berechnungen beim Clock Wipe vereinfacht, 6- bis 20-mal schneller #115837
  • Gamma-Cross-Effekt: Die frühere Methode mit komplexer Tabelle und Interpolation zur Vermeidung eines einzigen Quadratwurzelaufrufs wurde ersetzt, dadurch 4-mal schneller #115801
  • Gaussian-Blur-Effekt: Doppelte Berechnungen vermieden, dadurch 1,5-mal schneller #116089

Änderungen bei der finalen Renderzeit

• Auf Grundlage von drei Datensätzen aus dem Blender Studio wurde die finale Renderzeit von VSE-Filmen auf dem PC des Autors etwa halbiert
• Das Rendering von Sprite Fright edit sank von fast 13 Minuten auf 7 Minuten
• Der Autor hofft auf weitere Beschleunigungen und formuliert es sinngemäß so, dass „dreimal noch einmal Faktor zwei“ ziemlich gut wäre

Arbeitsweise und nächste Schritte

• Neben den für Nutzer sichtbaren Änderungen gab es auch Pull Requests für zusätzliche Tests, Refactoring und Aufräumarbeiten; insgesamt wurden 37 Pull Requests abgeschlossen, geprüft und zusammengeführt
• Der Autor bewertet, dass sich ein solches Arbeitspensum in einem „echten Job“ wohl nur schwer hätte erreichen lassen
  • Bei Unity zwischen 2015 und 2022 hätte er in derselben Zeit wohl etwa 30 % der obigen Arbeiten geschafft, möglicherweise sogar weniger
  • Beim „urzeitlichen“ Unity um 2010 herum wäre es vielleicht noch möglich gewesen, ergänzt er
• Faktoren wie Unternehmensgröße, Prozesse, Erwartungen, Kommunikation und Politik könnten dazu führen, dass dieselbe Arbeit in einem bezahlten Unternehmensumfeld eher langsamer wird oder unterwegs gestrichen wird
• Er hofft, dass Blender nicht eine Größen-, Komplexitäts- und Workflow-Stufe erreicht, bei der Prozesse Menschen eher ausbremsen und demotivieren, statt ihnen zu helfen
• Da Blender 4.1 nun Beta ist, gilt es funktional als abgeschlossen, und die VSE-bezogenen Änderungen für 4.1 fließen derzeit in die Release Notes ein
• Die Arbeit an Blender 4.2 beginnt, und er plant, auch danach weiter am VSE zu arbeiten, ohne festen Plan
  • Der Fortschritt ist im Forenbereich Weekly Updates zu sehen

[GN⁺]

Meinungen auf Hacker News

• Wenn es ein „richtiger Job“ gewesen wäre, hätte ich so etwas wohl nicht geschafft.
  Wenn in meiner Karriere etwas schiefgelaufen ist, dann diese Spaltung: Bei einem unbezahlten Projekt, bei dem ich völlig eigenartige Mathematik selbst lösen musste, schaffe ich in zwei Monaten mehr als sonst in zwei Jahren; bei bezahlten Projekten sind die Ergebnisse dagegen meist durchschnittlich.
  Ich habe wirklich hart versucht, die Mitte zu finden, aber es gelang mir nicht. Als sich letztes Jahr die Möglichkeit ergab, für etwas bezahlt zu werden, das ich zuvor kostenlos gemacht hatte, konnte ich es am Ende überhaupt nicht mehr anfassen.

  • Du bist nicht allein. Ich habe mein ganzes Leben lang Ähnliches erlebt, und deshalb zweifle ich an allem, was Leute über Motivation sagen, etwa an der Vorstellung, dass nur Profit und Lohn dafür sorgen, dass Arbeit erledigt wird.
    Dann stieß ich auf Marx’ Entfremdungstheorie, und vieles ergab deutlich mehr Sinn. Er ging von der Beobachtung aus, dass Arbeit eine Tätigkeit ist, der gesunde Menschen überwiegend nachgehen, meinte aber, man dürfe das nicht damit verwechseln, für andere zu arbeiten und vom Produkt der eigenen Arbeit entfremdet zu sein.
    https://en.m.wikipedia.org/wiki/Marx's_theory_of_alienation
  • Die besten oder interessantesten Dinge, die ich bisher gemacht habe, waren keine bezahlten Arbeiten.
  • Projektmanagement tötet diese Art von Arbeit komplett ab.
    Manche Orte haben ein gutes System mit einem Puffer von ein bis zwei Wochen, in dem man alles Mögliche machen kann, und das mildert dieses Problem.
  • Die erfüllendsten und wirkungsvollsten Arbeiten waren allesamt solche, für die ich kaum oder gar nicht bezahlt wurde. Inzwischen fühlt sich das wie etwas Unvermeidliches an und macht Softwarearbeit ein wenig deprimierend.
  • Das ist ein ziemlich interessantes Phänomen, und ich denke, es kommt vor allem von der Teamgröße und der Notwendigkeit, Geld zu verdienen.
    Bei Passion Projects wird man nicht bezahlt, also sind die Erwartungen niedrig, man ist zu nichts verpflichtet und kann im Grunde frei tun, worauf man Lust hat. Dadurch wählt man eher Dinge, die einen selbst interessieren und Wirkung haben, etwa neue Technologien oder Tools zu erkunden, die einen reizen.
    Sobald Geld ins Spiel kommt, kommen die Erwartungen der zahlenden Person hinzu, und neue, unbekannte Ansätze werden schwieriger, weil sie mit höherer Wahrscheinlichkeit scheitern.
    Am Ende, wenn Geld auf dem Spiel steht, meiden Menschen meiner Meinung nach zu große Risiken, selbst wenn es potenziell bessere Lösungen gibt, und bevorzugen vorhersehbare Ergebnisse.

• Wirklich beeindruckend, und es ist auch klar, dass der Autor des Originalbeitrags nicht einfach von der Straße ins Blender-HQ spaziert ist. Die langjährige Erfahrung bei Unity dürfte ziemlich geholfen haben, diesen Bereich zu verstehen.
  Diese Änderung [1] fand ich besonders gut. Beim Optimieren der Bildverarbeitungsschritte wurden sehr viele tabellenbasierte „Optimierungen“ entfernt und einfach durch Gleitkommaberechnungen ersetzt, was auf der Maschine des Autors etwa viermal schneller war. Großartig.
  [1]: https://projects.blender.org/blender/blender/pulls/115801/fi...

  • Nicht nur das: Wenn man sich den Diff ansieht, wurden 100 bis 150 Zeilen Code durch 3 Zeilen ersetzt. Solche Pull Requests kann man wohl nur erträumen.
  • Es ist zwar eine gute Optimierung, aber ich frage mich, ob return c * c; wirklich eine gute Näherung für sRGB-Gamma ist.

• Mir gefällt seit einigen Jahren besonders, wie Aras plötzlich in verschiedene Open-Source-Grafikprojekte hineinspringt, enorme Performance-Steigerungen und Verbesserungen erzielt und dann zum nächsten beliebigen Grafikprojekt weiterzieht, um dasselbe zu wiederholen.

  • Er hat auch mit Gaussian Splats herumgespielt und erstaunliche Ergebnisse erzielt.
    https://github.com/aras-p/UnityGaussianSplatting

• Ich würde so etwas gern auch bei meinem Musikplayer MusicBee machen.
  Wenn er denn Open Source wäre. Der Entwickler fasst ihn inzwischen kaum noch an; er war immer komplett kostenlos, und ich verstehe nicht, warum er nicht Open Source ist.
  Es gibt so viele kleine Ärgernisse, kaputte, langsame oder seltsame Kleinigkeiten, die ich in meiner Freizeit unbedingt beheben würde.
  Und jetzt auf etwas anderes wie FooBar umzuziehen, wäre viel zu aufwendig. HQPlayer habe ich auch ausprobiert, aber UI/UX war so furchtbar, dass ich nicht wechseln konnte.

  • Wie Steven schon 2013 mehrfach sagte, gebe es in absehbarer Zeit keine Pläne, MusicBee als Open Source zu veröffentlichen.
    Den Quellcode freizugeben, wenn er das Projekt nicht mehr fortführen möchte, sei eine der Optionen, die er in Betracht ziehen würde; aber es sei ein Hobbyprojekt, das er mache, weil Programmieren ihm Spaß macht, und es werde niemals professionell betrieben werden.
    In seinem Hauptjob verbringe er genug Zeit mit Personalführung und wolle das hier nicht auch noch tun. Wer sich Sorgen mache wie „Was, wenn er von einem Bus überfahren wird?“, solle besser eine andere App verwenden.
    https://web.archive.org/web/20170721042120/https://getmusicb...
  • Weil ein Softwareprojekt in dem Moment, in dem man es zu Open Source macht, zu einem Projekt zur Menschenverwaltung wird.
  • Um Code als Open-Source-Projekt zu schreiben, ist ein viel höherer Reifegrad erforderlich, als viele denken. Es ist deutlich mehr Arbeit, als ein Programm einfach nur gut zum Laufen zu bringen.
  • Es gibt eine Alternative: Man schreibt das Ganze komplett als Open Source neu.
  • MusicBee war die einzige Software, die ich nach dem Abschied von Windows weiterhin vermisst habe.
    Wenn sie gepflegt worden wäre, hätte ich erwogen, sie unter Wine laufen zu lassen; inzwischen habe ich aber das Konzept eines Musikmanagers ganz aufgegeben und spiele die Alben, die ich höre, einfach mit mpv ab. Und ich höre immer albumweise. Playlists lehne ich ab.

• Seit 2020 nutze ich Blender VSE für sämtliche Videobearbeitung, und es ist wirklich schön zu sehen, wie es besser wird.
  Angesichts von Stabilität und Funktionsumfang hielt ich es bereits für den besten Videoeditor unter Linux. Dass man alle bestehenden Animationswerkzeuge von Blender verwenden kann, ist ebenfalls ein Vorteil.

• VSE braucht wirklich viel Liebe. Ich wollte für meinen Podcast alle Tools als Open Source verwenden, aber als ich in Blender eine mp4-Sequenz mit Chroma Key gerendert habe, dauerte das bei einem 1,5-Stunden-Video 10 Stunden
  Am Ende bin ich zur kostenlosen Version von DaVinci Resolve gewechselt

  • Blender VSE hat derzeit beim Video-Rendering keine GPU-Beschleunigung, daher erledigt die CPU die gesamte Arbeit
    Außerdem kann es nicht wie DaVinci Resolve überspringen, wenn kein Re-Encoding nötig ist, sondern rendert jeden Frame einzeln. Wenn das verbessert wird, würde das der Performance und Effizienz von Blender stark helfen
  • Das Multi-Threaded-Rendering von Blender hat das Problem, dass es für VSE-Workloads nicht gut skaliert. Es konzentriert sich darauf, einzelne Frames aufzuteilen, und nutzt mehrere Kerne daher nicht gut aus
    Früher habe ich mit einem Plugin [1] experimentiert, das mehrere Render-Jobs an unterschiedlichen Stellen der Timeline als separate Prozesse startet, und das konnte das Rendering deutlich beschleunigen
    Inzwischen bin ich auch unter Linux zu Resolve gewechselt, weil ich Blackmagic-Kameras verwende und es dafür besser passt
    [1] https://github.com/AkBKukU/blenderSubprocessRender
  • Ich habe VSE in einem Projekt verwendet. Es war schmerzhaft, aber ich habe das Ergebnis fertiggestellt, und damals war es definitiv der beste kostenlose Software-Videoeditor
    Jetzt arbeite ich an einer neuen Version in Final Cut Pro

• Irgendeinen Teil des 3D-Programms Blender schneller zu machen, dürfte ziemlich schwierig sein. Es ist schon mit Abstand die am schnellsten startende 3D-Anwendung, und auch die GUI reagiert am schnellsten
  Houdini liegt zwar auf Platz zwei, aber nicht knapp dahinter

  • Überraschenderweise gibt es noch viele leicht erreichbare Optimierungen
    Vor ein paar Jahren habe ich am Code des „blobby“-Generators herumgearbeitet und ihn durch Hinzufügen von Multithreading deutlich langsamer gemacht. Sobald man den Multithreading-Overhead überwunden hatte, wurde es zwar schneller, aber soweit ich mich erinnere, fiel das nicht wirklich in typische Nutzungsszenarien, also habe ich es aufgegeben. Sicher habe ich dabei auch einige Fehler gemacht
  • Ich habe mir Teile des Codes angesehen und denke, dass es noch viel Raum für Verbesserungen gibt. Wie im Artikel erwähnt, gibt es überraschend viel Code, der im Namen der Optimierung sehr komplex aufgebaut ist, aber mit ähnlicher Wahrscheinlichkeit tatsächlich langsamer macht
    Texture Painting zum Beispiel macht pro Pixel etwa drei Pointer-Indirektionen und ruckelt auch auf meinem PC ziemlich
  • Bei den Animationstools gibt es enorm viel Verbesserungspotenzial, und offenbar wird tatsächlich daran gearbeitet. Auch der Umstieg auf Vulkan scheint stark helfen zu können

• Es hieß: „Wussten Sie, dass Blender eine Sammlung von Videobearbeitungstools hat? Ich wusste es nicht :)“, aber die meisten, die mit Blender Animationen erstellen, dürften das wissen
  Denn es ist die grundlegende Methode, gerenderte Frames in eine Videodatei zu verwandeln

  • Man kann Frames direkt als Videodatei rendern (ffmpeg-Optionen), und Anfänger oder Gelegenheitsnutzer machen das vermutlich oft so
    Man kann auch den Compositor verwenden, um eine vorab gerenderte Frame-Sequenz in eine Videodatei zu verwandeln
    Allerdings bevorzugen die meisten vermutlich andere Programme wie Resolve für den Videoschnitt, und VSE scheint in der schmalen Nische „einfaches Schneiden ist nötig, aber keine Transformationen, Titel oder Effekte“ zu liegen und daher nicht viel genutzt zu werden
    Es wäre schön, wenn jemand Transformationen und Effekte weiter verbessern und irgendwann auch 3-Punkt-Schnitt hinzufügen würde

• Ah, es war Aras. Er ist großartig. Ich meine mich zu erinnern, dass sein voller Name „Really Great Aras“ war
  Er ist stark in Graphics Coding und Ähnlichem, und beim Programmieren scheint er auch einen guten Flow-Zustand zu haben
  Der Text ist angenehm und unterhaltsam zu lesen. Es fühlt sich an, als würde man jemandem beim Reden zuhören. Auch Sätze wie „However!“ mittendrin
  Ich kann auch den Teil am Ende gut nachvollziehen, dass man in einem normalen Unternehmen unter Standardkultur und Prozess-Erwartungen auf 30 % Produktivität gedrückt wird. Die Kosten dafür, Mitarbeiter auf „ihre Aufgabe“ festzunageln, beinhalten tatsächlich enorme Produktivitätsverluste
  Ich hoffe, dass Techniker durch solche Beispiele weiter lernen, Menschen und Aktivitäten besser zu organisieren, diesem Lernen vertrauen und beginnen, hohe Produktivität/hohe Immersion in reale Organisationsformen zu integrieren
  Wie der Artikel andeutet, könnte die Arbeit in der Tech-Branche dadurch mehr Spaß machen. Vielleicht fast so viel Spaß wie das Herumspielen mit Technik

• Ergänzend zu https://projects.blender.org/blender/blender/pulls/116089: inline wirkt sich vor allem zuerst auf die One Definition Rule aus
  Einfach gesagt: Wenn man eine Funktion in einem Header definiert und sie aus mehreren .cc-Dateien aufruft, bekommt man Linker-Fehler, sofern man sie nicht als inline markiert
  Die Auswirkung auf tatsächliche Inline-Optimierung reicht von „keine“ über „der Compiler könnte sie wegen der Art der Verknüpfung anders gewichten“ bis „wird tatsächlich als Hinweis verstanden“, und bei Link-Time-Optimierung gelten ähnliche Überlegungen
  Wenn man dem Compiler ein deutlich stärkeres Inline-Signal geben will, ist es besser, die Funktion in einem anonymen Namespace zu definieren, besonders wenn sie nur innerhalb der Datei verwendet wird, in der sie definiert ist
  Die ursprüngliche Absicht, diese Funktion mit inline zu versehen, könnte ein Versuch gewesen sein, echte Inlining-Optimierung zu erreichen. Ein messbarer Gewinn ist nicht offensichtlich, aber auch nicht unmöglich