2009-06-02 9 views
2

Ich habe kürzlich einige der Physik-Engine für Simulation und Spieleentwicklung verglichen. Einige sind kostenlos, einige sind Open Source, einige sind kommerziell (1 ist sogar sehr kommerziell $$$$). Havok, Ode, Newton (aka oxNewton), Bullet, PhysX und "rohe" eingebaute Physik in einigen 3D-Engines.PhysX für massive Leistung über GPU?

Irgendwann kam ich zum Abschluss oder Frage: Warum sollte ich irgendetwas außer NVidia PhysX verwenden, wenn ich aufgrund der GPU-Verarbeitung seine erstaunliche Leistung (wenn ich es brauche) nutzen kann? Mit zukünftigen NVidia-Karten kann ich eine weitere Verbesserung erwarten, unabhängig von den normalen CPU-Erzeugungsschritten. Das SDK ist kostenlos und auch für Linux verfügbar. Natürlich ist es ein bisschen Verkäufer Lock-in und es ist nicht Opensource.

Was ist Ihre Meinung oder Erfahrung? Wenn Sie jetzt mit der Entwicklung beginnen würden, würden Sie dem oben zustimmen?

prost

Antwort

4

Haftungsausschluss: Ich habe PhysX noch nie verwendet, meine Berufserfahrung beschränkt sich auf Bullet, Newton und ODE. Von diesen dreien ist ODE bei weitem mein Favorit; es ist am numerischsten stabil und die anderen zwei haben Reifeprobleme (nützliche Gelenke nicht implementiert, legale Gelenk/Motor-Kombinationen, die sich in undefinierter Weise verhalten, & c).

Sie haben in Ihrer Frage auf das Verkäufer-Lock-In-Problem hingewiesen, aber es lohnt sich, dies zu wiederholen: Wenn Sie PhysX als Ihre einzige physikalische Lösung verwenden, können Ihre AMD-Karten Ihr Spiel nicht ausführen (ja, ich weiß es) kann be made to work, aber es ist nicht offiziell oder von NVIDIA unterstützt). Eine Möglichkeit ist es, eine Failover-Engine zu definieren, die ODE oder etwas auf Systemen mit AMD-Karten verwendet. Das funktioniert, aber es verdoppelt Ihre Arbeitsbelastung. Es ist verführerisch zu denken, dass Sie die Unterschiede zwischen den beiden Engines hinter einer gemeinsamen Schnittstelle verbergen und den Großteil Ihres Spielphysik-Codes einmal schreiben können, aber die meisten Ihrer Schwierigkeiten mit der Spielphysik werden im Umgang mit den Eigenheiten Ihres speziellen sein Physik-Engine, die sich für Werte wie Kontaktreibung und Restitution entscheidet. Diese Werte haben keine konsistenten Bedeutungen in allen Physik-Engines und können (meistens) nicht formell abgeleitet werden, so dass Sie im Test nach gut aussehenden, spielbaren Werten suchen. Mit PhysX plus einem Failover machst du alles, was scut zweimal funktioniert.

Auf einer höheren Ebene, ich glaube nicht, dass einer der Stream-Processing-APIs noch vollständig gebacken sind, und ich würde widerwillig zu einem verpflichten, bis zumindest, wie wir die Reaktion der Kunden von Intel haben Larrabee gestaltet die Designs der Menschen.

Soweit ich PhysX als die offensichtliche Wahl für High-End-Spieleentwicklung ansehe, würde ich sagen, dass es vermieden werden sollte, es sei denn, Sie denken nicht, dass AMD-Karten einen erheblichen Anteil Ihrer Spielerbasis ausmachen unwahrscheinlich) oder Sie haben genug Kodierung und QA-Manpower, um zwei Physik-Engines zu testen (plausibler, aber wenn Ihre Firma so wohlhabend ist, habe ich gute Dinge über Havok gehört). Oder, denke ich, wenn du ein Physikspiel mit so hohen Leistungsanforderungen entworfen hast, dass nur die Streaming-Physik dich befriedigen kann - aber in diesem Fall würde ich dir raten, eine Band zu gründen und das Mooresche Gesetz ein Jahr lang machen zu lassen oder zwei.

-1

, wenn alle Ihren Code massiv paralelizable ist, dann gehen für sie!

für alles andere sind GPUs bedauerlich unzureichend.

+0

Er spricht über Spielphysik - die Ausbreitung von mehreren Objekten und ihre Interaktionen miteinander gleichzeitig. Dieses Problem ist inhärent parallel und skaliert, wenn die Anzahl der Objekte zunimmt. Daher sind GPUs eine gute Wahl ... mit Ausnahme des Lock-In-Problems des Anbieters. – muusbolla

1

Der hypothetische Vorteil von zukünftigen Grafikkarten ist gut und schön, aber es wird auch zukünftige Vorteile durch zusätzliche CPU-Kerne geben. Können Sie sicher sein, dass zukünftige Grafikkarten immer freie Kapazitäten für Ihre Physik haben?

Aber wahrscheinlich ist der beste Grund, wenn auch ein wenig vage in diesem Fall, dass Leistung nicht alles ist. Wie bei jeder Drittanbieter-Bibliothek müssen Sie diesen Code möglicherweise für die kommenden Jahre unterstützen und aktualisieren, und Sie werden sicherstellen wollen, dass die Schnittstellen vernünftig sind, die Dokumentation gut ist und über die Fähigkeiten verfügt, die Sie haben benötigen.

Es mag auch mehr mathematische Probleme geben, wie einige APIs, die eine stabilere Gleichungslösung und ähnliches bieten, aber ich werde das einem Experten sagen.

2

Sie finden diese interessant:

http://www.xbitlabs.com/news/video/display/20091001171332_AMD_Nvidia_PhysX_Will_Be_Irrelevant.html

Es voreingenommen ist ... es ist im Grunde ein Interview mit AMD ... aber es macht einige Punkte, die ich denke, sind eine Überlegung wert, in Ihrem Fall.

Aufgrund der Probleme, auf die David Seiler hingewiesen hat, könnte der Wechsel von Physik-Engines in der Zukunft ein großes/unüberwindbares Problem sein ... besonders wenn das Gameplay eng an die Physik gebunden ist.

Also, wenn Sie wirklich Hardware-beschleunigte Physik in Ihrem Motor wollen NOW, für Physx gehen, aber bewusst sein, dass, wenn Lösungen wie die von AMD in diesem Artikel postulierte verfügbar werden (sie absolut werden aber sie sind nicht hier noch), werden Sie mit unangenehmen Entscheidungen konfrontiert:

1) umschreiben Motor (Namen der neuen Cross-Plattform-Hardware-beschleunigter Physik-Engine) zu verwenden, die möglicherweise die Dynamik des Spiels in einem schlechten Weg

Wechsel

2) weiterhin nur mit Physx arbeiten, AMD-Nutzer völlig vernachlässigen

3) versuchen, Physx auf AMD GPUs (blech ...)

Abgesehen von Davids Idee der Verwendung einer CPU-Physik-Engine als Fallback (zweimal die Arbeit und produziert 2 Motoren, die sich nicht identisch verhalten) Ihre einzige andere Option ist reine CPU-Physik.

Aber wie Sachen wie OpenCL Mainstream werden wir sehen, ODE/Bullet/kin beginnen zu integrieren, dass ... IOW, wenn Sie es jetzt mit ODE/Bullet/Kin Sie könnten (wahrscheinlich wird schließlich) die GPU-Beschleunigung für "frei" später (keine Änderungen an Ihrem Code). Es wird sich mit der GPU-Version immer noch etwas anders verhalten (ein unvermeidliches Problem wegen des Schmetterlingseffekts und der Unterschiede in der Gleitkomma-Implementierung), aber zumindest wird die ODE/Bullet/Kin-Community mit Ihnen zusammenarbeiten, um diese Lücke zu verringern .

Das ist meine Empfehlung: Verwenden Sie eine Open-Source-Physik-Bibliothek, die derzeit nur die CPU verwendet und darauf wartet, dass GPUs über OpenCL, CUDA, ATIs Stream-Sprache usw. genutzt werden. und du wirst dir Kopfschmerzen ersparen.

+0

'und nicht identisch verhalten'. Ein Punkt, den ich wiederholen sollte, und einen, den ich in meiner Antwort beschönige. –

0

PhysX arbeitet mit Nicht-Nvidia-Karten, es wird einfach nicht beschleunigt. In der gleichen Position bleiben die anderen Motoren. Das Problem ist, wenn Sie eine physikalische Simulation haben, die nur mit Hardware-Physik-Beschleunigung bearbeitbar ist.

4

Eine frühe Update-Antwort von 2013: Ich entwickle für das, was ich für die drei großen Betriebssysteme halte: Linux, OS X, MS. Ich entwickle auch mit den großen drei Physikbibliotheken: PhysX, Havok, Bullet.

In Bezug auf PhysX habe ich vor kurzem einige Tests mit der neuesten Version 3.2.2 zum Zeitpunkt der Erstellung dieses Artikels durchgeführt.Meiner Meinung nach hat nVidia die Effektivität der Bibliothek stark reduziert. Der größte ist der Mangel an Beschleunigung für starre Körper. Die Lib beschleunigt nur Partikel und Gewebe. Auch diese haben keine Verbindung mit allgemeinen starren Körpern. Ich bin völlig verwirrt, weil nVidia dies tut, da sie eine riesige Marketingkampagne haben, die GPU-beschleunigte Apps vorantreibt und sich auf wissenschaftliche Berechnungen konzentriert, wobei eine große treibende Kraft die Physiksimulation ist.

Während also meine Erwartungen an den König der Physik sim PhysX, Havok und Bullet in dieser Reihenfolge sind, sehe ich das Gegenteil in der Realität. Bullet hat lib 2.8.1 mit einer Auswahl von OpenCL-Unterstützung veröffentlicht. Bullet ist eine relativ kleine Bibliothek mit großzügiger Lizenzierung. Ihr Ziel ist es, Version 3 mit vollständig integrierter OpenCL Starrkörperbeschleunigung zu haben.

Ein Teil der Kommentare sprechen über mehrere Code-Pfade. Meiner Meinung nach ist das keine allzu große Sache. Ich unterstütze bereits drei Betriebssysteme mit minimaler Unterstützung von hartem Code (Threading zum größten Teil und verwende keinen OS-spezifischen Code; verwende C++ - und Standard-Lib-Vorlagen). Ähnlich ist es bei den Physikbibliotheken. Ich benutze eine gemeinsame Bibliothek und abstrahiere eine gemeinsame Schnittstelle. Das ist in Ordnung, weil sich die Physik nicht viel verändert;) Sie müssen immer noch eine Simulationsumgebung einrichten, Objekte verwalten, Iterationen in der Umgebung rendern, wenn Sie fertig sind. Der Rest ist Flash, implementiert in der Freizeit.

Mit dem Aufkommen von OpenCL in Mainstream-Bibliotheken (nVidia Cuda ist sehr nah - siehe Bullet OpenCL-Demos) wird die Physik-Plugin-Arbeit schrumpfen.

Also, von Grund auf neu und nur mit Physik Modellierung beschäftigt? Mit Bullet kannst du nichts falsch machen. Kleine, flexible Lizenz (kostenlos), sehr nah an der Produktion bereit OpenCL, die Cross-Plattform über die großen drei OS und GPU-Lösungen sein wird.

Viel Glück!

1

Ich habe ODE und jetzt mit PhysX verwendet. PhysX macht Gebäude Szenen einfacher und (meine persönliche Meinung) scheint realistischer, jedoch gibt es keine angemessene Dokumentation für PhysX; tatsächlich überhaupt keine Dokumentation. Auf der anderen Seite ist ODE Open Source und es gibt viele Dokumente, Tutorials usw. PS: Mit GPU Beschleunigung hilft mir und meinen Kollegen deutlich; Wir verwenden APEX Zerstörung und PhysX Partikel.

+0

PhysX ist jetzt Open Source. Ein großer Punkt geht also an den PhysX. –