Der Physikthread steht auf tpHighest, und der Renderthread auf tpNormal. Selbst wenn der Rechner durchs Rendern in die Knie geht sorgt diese Konstellation dafür dass meine Newtonwelt alle 15ms aktualisiert wird, und genau das war mein Ziel. Die generelle Renderperformance ist durch das Threading zwar gesunken, aber lieber ein paar Frames weniger und dafür dann die Garantie dass meine Physik unter jeder Grafiklast gleich arbeitet. Ob das so für ein kommerzielles Spiel brauchbar ist bezweifle ich (ich zeige da mal symbolisch auf das Gerangel als bekannt wurde dass D3 nen Frame-Limiter hat), aber in meinem Falle handelt es sich ja um eine Physikdemo, und da kommts eben genau auf die korrekte Physik an. Obs dann mit 100 oder mit 60 FpS läuft ist zweitranging, besonders wenn (heute gabs ne neue Beta-SDK Version mit neuen Kollisionsprimitiven für Reifen *freu*) das Fahrzeug sich so realistisch verhält wie momentan.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Ah, das habe ich mir fast gedacht. Der Physikengine ist es natürlich egal, ob die Updates synchron zur Systemzeit laufen - aber so hältst du das Design recht einfach. Was die Renderperformance angeht, ist es mir ohnehin ein Rätsel, wie manche Leute über ein paar Zahlen aufregen können, wichtiger ist vielmehr, dass die Applikation auf der Bandbreite der Geräte der Zielgruppe getestet wird und überall akzeptabel läuft (man muss Doom3 auch tatsächlich zugute halten, dass es bereits im ersten Release überhaupt keine Probleme machte, was ansonsten doch eher die Ausnahme als die Regel ist).

Ich bin übrigens auch schon gespannt auf das nächste Newton Release, dessen Ansatz, häufig benötigte Funktionalität in Containerklassen zusammenzufassen, ziemlich anwenderfreundlich ist. In ODE gibt es zwar auch für "fast alles" eine Lösung (und zur Not kann man es auch selbst erweitern - übrigens sogar aus Delphi, da eine Schnittstelle existiert, eigene Colliderfunktionen hinzuzufügen), zusammenstöpseln muss man sich dann aber das meiste selber.

OT: Weißt du eigentlich, ob auch ein kommerzielles Interesse hinter der Entwicklung von Newton steht (offensichtlich ist es ja auch in 3DGS integriert), oder ist es ein reines Hobby des Entwicklers (eventuell auch ein Nebenprodukt einer anderen Applikation)?

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/

Ich gehe mal davon aus dass es früher oder später auch was kommerzielles wird, aber momentan wohl eher ein "Testbett" für neue Methoden. Denn so ziemlich alles was in Newton integriert wurde gab es in dieser Form (implementationtstechnisch) noch nicht. Mal abgesehen davon dass Newton ja als einzige Engine ein echtes Columb-Friktionssystem beinhaltet, hat Newton auch eine bisher noch nie genutzte Kollisionstechnik die der Macher demnächst auch auf der SIGGRAPH vorstellen darf. Anfänglich war die Sache wohl eher ein Test ob eben diese Kollisionsmethode gebräuchlich ist, aber es hat sich anscheinend rausgestellt dass man damit sehr gut ankommt und dieses System numerisch auch leicht stabilisierbar ist. Auch in Sachen Berechnung konvexer Hüllen scheint Julio ne eigene Methode entwickelt zu haben, denn selbst bei Modellen jenseits von 10.000 ist die Berechnung dieser Hülle blitzschnell. Aber ich schweife wieder aus

Kurz gesagt : Ob es von Newton eine kostenpflichtige Variante gibt weiß noch keiner, aber wenn dann wird diese wohl nur für kommerzielle Zwecke kostenpflichtig. Zumindest im internen Forum hat Julio nämlich bereits Andeutungen in Richtung "Konkurrenz" gemacht.

3DGS : Die Sache wird nichts mehr. Es gab (jemand externes macht den momentan noch) ein Newton-Modul für 3DGS, aber die Macher vom 3DGS vertreiben anscheinend eine Pro-Version die eine andere Physikengine nutzt. Und da sie mit der Pro-Version Geld verdienen wohl haben sie den Macher von Newton recht unfreundlich darauf hingewiesen er solle das mit dem Newton-Modul bitte lassen. Deren Nachteil ist dann aber unser Vorteil, denn Newton wird dann halt komplett für C++ entwickelt und ist damit auch für uns nutzbar.


Ich darf ja nicht so viel verraten, aber im Endeffekt ists ja Werbung für Newton. Momentan gibts im neuen SDK jede Menge toller Sachen mit denen man rumspielen kann. Der Vehikel-Container ist jetzt fast final, man kann also für Reifen Materialien festlegen und so unterschiedliche Fahreigenschaften auf unterschiedlichem Untergrund festlegen. Ausserdem werden für Reifen jetzt Chamfer-Zylinder verwendet, und ich muss zugeben dass sich der Karren in meiner Fahrzeugdemo jetzt verdammt realistisch verhält (momentan versuche ich, was man ja selbst machen muss, ne Gangschaltung einzubauen. Das ist aber nicht sonderlich leicht). Primitiven gibts insgesamt 6 unterschiedliche, und dazu dann noch konvexe Hüllen. In Sachen Ragdolls hat sich auch was getan, nämlich nachdem es mir missfiel dass man für Ragdolls nur Boxen verwenden konnte; dass hat sich jetzt auch geändert und man kann für Ragdolls alle vorhandenen Primitiven nutzen. Im übrigen wird Newton auch bald ein eigenes (getrenntes) "nur-kollision"-System haben, so dass man mit Newton nicht zwingend Physik berechnen muss, sondern es auch nutzen kann um nur Kollisionsabfragen zu nutzen.
Releasetermin gibts wie gewohnt keinen, aber die aktuelle Version ist zumindest sehr stabil und alle von mir bisher monierten Probleme scheint der Macher gefixt zu haben. Lange kanns also nicht mehr dauern. Wenn dann das nächste Release da ist, gibts von meiner Seite auch zwei Demos : Die Fahrzeugdemo, aber aufgeborht, und einen "NewtonPlayGround" in dem man sich austoben kann. Wenn gewollt kann ich dazu auch mal Screenshots posten.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Ich hab' mich eh nicht zu fragen getraut .


Na ja, ist ohnehin ein unsympathisches Programm. Soweit ich weiß, kostet übrigens auch die "normale" Edition, bei der in allen erstellten "Programmen" das Logo eingeblendet ist, Geld. Ich hätte mir allerdings eher vorgestellt, dass Julio Jerez eventuell von kommerziellen Nutznießern gesponsort wird, wo er doch ohnehin kein Geld dafür verlangt hat - aber da war ich wohl zu idealistisch. Ich würde es schade finden, wenn Newton selbst kommerziell würde, kann es aber verstehen.


Da bin ich auch schon gespannt drauf. Deine Newtondemos sind sowohl visuell als auch technisch sehr ansprechend - um so mehr, wenn man bedenkt dass du dich noch gar nicht so lange mit Newton befasst hast.

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/

OnTopic:
In der CT in der auch Delphi7PE dabei war, ist ein Artikel zu "Perfomancesteigerung mittels Threadprogrammierung". Eventuell für euch nochmal ganz interessant. Und da wird (@Mars) auch davon gesprochen, dass man eine Perfomance steigerung auf Einprocessorsystemen erreicht werden kann. (Vorallem natürlich im Bezug auf Netzwerksachen etc.)

EDIT: Nicht die CT sondern die "Entwickler 2/2004" wars.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

@Performancesteigerung auf Einprozessorsystemen
Nachdem ich durchaus einige tiefergehende Einblicke in die Betriebssystemprogrammierung hatte, möchte ich Folgendes anmerken: Das Problem ist, dass aktuelle Prozessoren eine streng sequentielle Ablaufsteuerung haben (Aufweichungen in geringem Maße, wie das vorher angesprochene "Vorwegnehmen" bestimmter Begehle, die sich bereits in der Instructionpipeline befinden, mal außen vor gelassen). Das Zusammenspiel von Mehrprozessorsystemen auf Intel kompatibler Architektur (massiv parallele Systeme mögen ganz andere Techniken zur Verfügung stellen) und geeignetem Betriebssystem funktioniert über sogenannte IPIs (Interprozessorinterrupts), mit denen die verschiedenen Aufgaben zugeteilt werden (die Umsetzung ist unterschiedlich, meist ist es wieder ein Prozessor, der die Aufgaben an die anderen Prozessoren verteilt, nachdem "er" sie gebootet hat) - auf einem Singleprozessorsystem basiert die Threadverwaltung aber auf einer Zeitscheibe, die man auch selbst, eventuell mit weniger Verwaltungsoverhead als das Betriebssystem (da man ja genau weiß, was man braucht), implementieren könnte, wenn man einen Hook auf den Timerinterrupt legen könnte (im Gegensatz zum Abfangen der WM_TIMER Message). Am Ende hat man dann zwei quasi parallele Prozesse + den Overhead der Threadumschaltung, der unter Windows aber insofern mehr oder weniger vernachlässigbar ist, als die Zeitscheibe auf 10ms basiert, was für den Prozessor eine halbe Ewigkeit ist - es ist so aber auch nicht möglich einen Thread etwa millisekundengenau mit der Änderung einer Variable zu synchronisieren, die von einem anderen Thread geändert wird (der von mir aus irgend eine Schnittstelle pollt).
Mit Hyperthreading, das dem Betriebssystem selbt ja zwei physikalisch existierende CPUs vorgaukelt, mag die Sache etwas anders aussehen, wirklich interessant wird es aber erst, wenn der Prozessorkern tatsächlich zwei parallele Befehlsströme ausführen kann (und damit meine ich jetzt nicht nur das Cachen von zwei Instructionpipelines), oder natürlich, wenn tatsächlich mehrere Prozessoren vorhanden sind.

Es kommt halt drauf an, was man unter Performancesteigerung versteht: eine langwierige Routine wird nicht schneller werden, selbstverständlich ist es aber praktisch mehrere Programme bzw. Programmteile parallel laufen zu lassen, auch wenn dadurch ein kleiner Verwaltungsoverhead (z.B. durch Umschaltung auf Programmteile die zur Zeit ohnehin nichts zu tun haben) entsteht.

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/

Ich wollte um Gottes willen auch nix anderes behaupten.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Nachdem sich eine hier ein interessante Diskussion entwickelt hat, schlage ich das Thema mal für den nächsten Themenabend vor.

Oje, ich hoffe du hast dich durch das im Nachhinein etwas angeberisch wirkende Posting (war aber echt nicht beabsichtigt) nicht einschüchtern lassen. Selbstverständlich ist das auch nur meine Meinung, und eine Diskussion in einem Themenabend wäre auch keine schlechte Idee, insbesondere als es im Zhg. mit interaktiver 3D-Grafik mehrere Ansatzpunkte gibt, in denen Multithreading vom Design her Sinn machen dürfte, als auch gerade leistungsgierige 3D-Fanaten durchaus Geld in Mehrprozessorsysteme investieren dürften. Ich erinnere mich an einen kleineren Hype um Zweiprozessorsysteme, als es unter Windows NT einen mehrprozessorfähigen Quake 3 Port gab (u.a. gab es eigene Platinen, die man zwei Celeron Prozessoren aufrüsten konnte).

Als einziges Thema halte ich es allerdings fast für etwas mager, weswegen ich eher "Leistungssteigerung mit Consumerhardware" vorschlagen würde, wo man sich dann darüber unterhält, wie man aus leistbarer Hardware im Hinblick auf 3D-Grafikl besonders leistungsfähige Systeme zusammenstellen kann (was bringen Raid0 Platten, Wasserkühlung, mehrere Prozessoren, zusammengestöpselte Grafikkarten, wie kann man normale (loosely coupled) Netzwerke zur Leistungssteigerung einsetzen, ...)

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/