Physik-Engine Havok 2014.1 auf Quadcore-CPU mit Leistungssprung, Gameplay-Physik auf dem Vormarsch

34
Special Carsten Spille Als bevorzugte Quelle auf Google hinzufügen
Havok Physics Middleware GDC Europe 31

Der Middleware-Entwickler Havok hat auf der GDC Europe in Köln am Montag einen Überblick über die Entwicklung seiner Physik-Schnittstelle gegeben und gewährte dabei einen (vagen) Ausblick auf die künftige Entwicklung. Klar ist, dass die von Intel übernommene Firma sich auch weiterhin auf die CPU als Kernpunkt für Optimierungen der Multi-Plattform-Middleware konzentriert.

Auf der Kölner "Gamescom-Begleitmesse" für Spieleentwickler, der GDC Europe, hat der zu Intel gehörende Middleware-Entwickler Havok einen Ein- und Ausblick in die Entwicklungen seiner Physik-Schnittstelle gegeben. Man hat dabei klar gemacht, dass auch künftig die CPU das zentrale Element für die Physikberechnungen bleibt – Gründe seien neben der geforderten Multi-Plattform-Fähigkeit auch die einfachere Fehlersuche. Dennoch wolle man sich neuen Entwicklungen wie beispielsweise Physikberechnungen auf GPUs und massiv-mehrkernigen Prozessoren nicht verschließen. Doch auch auf herkömmlichen x86-CPUs sei noch eine Menge Optimierungspotenzial vorhanden.

Spiel-Physik, und damit meint Havok in diesem Falle vor allem den optischen Augenschmaus, weniger auch Gameplay-relevante Elemente, wirke dank der grafischen Weiterentwicklung moderner 3D-Welten inzwischen auch nicht mehr so fehl am Platze, wie sie das im Grafik-Korsett von vor zehn Jahren tat. Ein Beispiel dafür gab es im Video. Daher und aufgrund der allgemeinen Leistungsfähigkeit von PCs sei es für Spiele-Entwickler zunehmend interessant, auch aufwendige Effekte wie beispielsweise eine Stoffsimulation einzubinden.

Mit Optimierung zur Gameplay-Relevanz

Doch auch die Gameplay-relevanten Physikberechnungen seien im Kommen, so Havok-Sales-Engineer Steve Ewart weiter. Dank umfassender Optimierungen wie auch der enormen Leistungsfähigkeit moderner Mehrkernprozessoren seien nun auf immer mehr Geräten Objekte mit Physiksimulation in nennenswerter Anzahl – er sprach von einer vierstelligen Zahl – möglich. Reine Optik-Physik könne zwei Größenordnungen umfangreicher ausfallen. Dazu kommt, dass sich zum Beispiel Partikeleffekte leichter skalieren lassen. Von einer hohen möglichen Zahl an Physikobjekten profitiert automatisch auch die potenzielle Einbindung als Gameplay-Element.

Havok Physics Middleware GDC Europe 14 Havok Physics Middleware GDC Europe 14 Im Zuge der fortschreitenden Optimierungen habe man die neue Physik-Engine – Havok spricht von 2014.1 – quasi von Grund auf neu entwickelt. Im Gegensatz zum alten, nach wie vor verfügbaren 2012er-Modul seien insbesondere der Speicherverbrauch und die Multithreading-Fähigkeiten verbessert worden. Im direkten Vergleich zeigt ein interner Havok-Benchmark, dass der Leistungszuwachs beim Sprung von einem auf vier Threads im alten Modul bei gerade einmal Faktor 1,5 liege. Havok Physics 2014.1 dagegen erreicht knapp Faktor 3, also nahezu das Doppelte. Interessant an dieser auch in der Bildergalerie enthaltenen Grafik ist auch, dass der Zuwachs bei Physics 2012 von drei auf vier Threads nur noch marginal ausfällt, das 2014er-Modul dagegen nur langsam in der Skalierfähigkeit nachlässt.

Die Havok-Demos haben wir in einem separaten Video nochmals für Sie eingebunden.

Realistisch bleiben

Bei aller Euphorie über verbesserte Optimierungen und die dadurch entstehenden Möglichkeiten müsse man aber auch den Blick für das Wesentliche wahren. Beispielsweise könne man zwar mit derselben Genauigkeit Ragdoll-Physik anbieten, wie auch für die Animationssysteme genutzt werden, doch es stelle sich die Frage, ob es wirklich nötig sei, Ragdolls bis ins letzte Fingerglied zu simulieren.

Ein weiterer Aspekt dieses Themenkomplexes ist die Berechnungsgenauigkeit. Dies sei ein vergleichbares Problem, wie dass des als nachträglicher Effekt eingefügten Film-Grains (Körnung). Bei hoher Basisqualität der Grafik wirke das Bild dadurch schmutzig und unruhig, aber nicht besser.

Havok Physics Middleware GDC Europe 18 Havok Physics Middleware GDC Europe 18 Derzeit werden in allen für Spiele genutzten Physik-Middlewares hauptsächlich die Standard-FP32-Berechnungen genutzt. Doch es gibt Probleme – besonders bei nicht lokal begrenzten Physik-Simulationen. In einer kurzen Demo zeigte Ewart, wie unterschiedlich sich eine mit denselben Parametern gefütterte Rigid-Body- Simulation in verschiedenen Entfernungen verhält. Eine Ragdoll-Simulation begann bei 10 Kilometern "Welt-Entfernung" unnatürlich zu zittern, bei 15 km bewegte sich auch einer der Zylinder augenfällig seltsam. Einige Nicht-Spiele-Entwickler, die allerdings naturgemäß eine höhere Präzision benötigen, arbeiteten bereits mit 64 Bit Genauigkeit – diese kostet auf aktuellen x86-CPUs mindestens 50% der Leistung (halber DPFP-Durchsatz, auf den meisten GPUs noch weitaus weniger). Aus diesem Grunde ist wohl auch nicht mit einer baldigen Umsetzung von FP64-Physik in Spielen zu rechnen. Ähnliches sagte auch Physx-Entwickler Nvidia bereits vor Jahresfrist.

Bildergalerie

34
    • Kommentare (34)

      Zur Diskussion im Forum
      • Von PCGH_Carsten Volt-Modder(in)
        Ich brauche, nachdem SSE2/AVX/AVX2 angerissen wurden, nun also keine Falschbehauptung mehr im Artikel beheben, ja? Danke.
      • Von PCGH_Carsten Volt-Modder(in)
        Ich brauche, nachdem SSE2/AVX/AVX2 angerissen wurden, nun also keine Falschbehauptung mehr im Artikel beheben, ja? Danke.
      • Von oldsql.Triso Volt-Modder(in)
        Als Resultat dürfte NV vllt. seinen CPU-PhysX-Part verbessern Ansonsten soweit nichts Neues wie ich finde, aber gute Entwicklung!
      • Von Brehministrator BIOS-Overclocker(in)
        Zitat von nembob
        Schon mal was von SSE gehört? Dabei handelt es sich um einen erweiterten Befehlssatz, mit dem man acht 128-Bit breite Register in der CPU ansprechen kann. Mit SSE kannst du Vektor- und Matrixoperationen meist schneller durchführen, als wenn du die Berechnungen von der FPU durchführen lässt. Da die Register aber nur 128Bit groß sind kannst du entscheiden, ob du vier 32Bit floats oder nur zwei 64Bit double reinlädst. Wenn man double verwendet braucht man also offensichtlich doppelt so viele Rechenzyklen. Es gibt zwar mittlerweile auch AVX mit 256Bit aber auch da kannst du doppelt soviele floats reinladen wie doubles. Außerdem gibt es AVX erst seit 2011 mit der Sandy Bridge bzw. Bulldozer Architektur, wodurch die Legende gar nicht mal so alt sein kann. Will man double precision Operationen mit Hilfe von OpenCL auf der GPU berechnen, muss man sogar bei aktuellen Grafikkarten mit Leistungseinbußen rechnen.
        Als Quelle füge ich mal diesen Benchmark ein:
        AnandTech Portal | Floating point peak performance of Kaveri and other recent AMD and Intel chips

        Ansonsten einfach mal ein bisschen über SSE informieren und selber damit rumprobieren.
        Ich kenne die Vektorisierungsbefehle im Prinzip (benutze sie nicht explizit, da ich kein Assembler schreibe ). Ich wusste nicht, dass man die doppelte Anzahl an Operanden in die Register laden kann, wenn man mit Single Precision arbeitet. Das ist natürlich ne coole Sache. Wieder was dazu gelernt, danke
      • Von nembob Schraubenverwechsler(in)
        Zitat von Brehministrator
        Was soll immer diese alte Legende, dass auf einer x86-CPU Single-Precison-Berechnungen (32 Bit Float) schneller wären als Double Precision (64 Bit)? Dem ist nicht so, wie man in unzähligen Internet-Quellen nachlesen kann, und auch sehr einfach selbst feststellen (ich arbeite als Programmierer in der Theoretischen Chemie). Da alle heutigen PC-CPUs Double Precision in Hardware ausrechnen, braucht das etwa gleich viele Zyklen wie Single Precision. Lediglich der Speicherverbrauch ist offensichtlich doppelt so hoch (was manchmal zu weniger effizienter Cache-Ausnutzung führen kann).

        Bitte diese Falschaussage oben im Artikel korrigieren (oder eine Quelle für diese Behauptung einfügen).


        Schon mal was von SSE gehört? Dabei handelt es sich um einen erweiterten Befehlssatz, mit dem man acht 128-Bit breite Register in der CPU ansprechen kann. Mit SSE kannst du Vektor- und Matrixoperationen meist schneller durchführen, als wenn du die Berechnungen von der FPU durchführen lässt. Da die Register aber nur 128Bit groß sind kannst du entscheiden, ob du vier 32Bit floats oder nur zwei 64Bit double reinlädst. Wenn man double verwendet braucht man also offensichtlich doppelt so viele Rechenzyklen. Es gibt zwar mittlerweile auch AVX mit 256Bit aber auch da kannst du doppelt soviele floats reinladen wie doubles. Außerdem gibt es AVX erst seit 2011 mit der Sandy Bridge bzw. Bulldozer Architektur, wodurch die Legende gar nicht mal so alt sein kann. Will man double precision Operationen mit Hilfe von OpenCL auf der GPU berechnen, muss man sogar bei aktuellen Grafikkarten mit Leistungseinbußen rechnen.
        Als Quelle füge ich mal diesen Benchmark ein:
        AnandTech Portal | Floating point peak performance of Kaveri and other recent AMD and Intel chips

        Ansonsten einfach mal ein bisschen über SSE informieren und selber damit rumprobieren.
      • Von Brehministrator BIOS-Overclocker(in)
        Was soll immer diese alte Legende, dass auf einer x86-CPU Single-Precison-Berechnungen (32 Bit Float) schneller wären als Double Precision (64 Bit)? Dem ist nicht so, wie man in unzähligen Internet-Quellen nachlesen kann, und auch sehr einfach selbst feststellen (ich arbeite als Programmierer in der Theoretischen Chemie). Da alle heutigen PC-CPUs Double Precision in Hardware ausrechnen, braucht das etwa gleich viele Zyklen wie Single Precision. Lediglich der Speicherverbrauch ist offensichtlich doppelt so hoch (was manchmal zu weniger effizienter Cache-Ausnutzung führen kann).

        Bitte diese Falschaussage oben im Artikel korrigieren (oder eine Quelle für diese Behauptung einfügen).
      Direkt zum Diskussionsende
  • Print / Abo
    Apps
    PCGH Magazin 08/2026 PC Games 08/2026 play5 08/2026 N-Zone 08/2026 Linux Magazin 08/2026 LinuxUser 08/2026 Raspberry Pi Geek 09/2026
    PC Games Hardware PC Games Linux Magazin Raspberry Pi Geek Computec Kiosk