Du bist nicht angemeldet.

Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!

Unterschiedliche Fortbewegungsgeschwindigkeit

Werbeanzeige

Mastermind

unregistriert

51

08.08.2010, 17:37

Hör doch auf rumzulabern.

Vielleicht können wir uns verständigen dass z.B. Bullet von "cleveren Leuten" geschrieben wurde, die es besser können, als jeder von uns beiden und siehe da:

http://bulletphysics.org/mediawiki-1.5.8…pping_The_World

Zitat


Here's the prototype:

btDynamicsWorld::stepSimulation(
btScalar timeStep,
int maxSubSteps=1,
btScalar fixedTimeStep=btScalar(1.)/btScalar(60.));

The first parameter is the easy one. It's simply the amount of time to step the simulation by. Typically you're going to be passing it the time since you last called it

Bullet maintains an internal clock, in order to keep the actual length of ticks constant. This is pivotally important for framerate independence. The third parameter is the size of that internal step.

The second parameter is the maximum number of steps that Bullet is allowed to take each time you call it. If you pass a very large timeStep as the first parameter [say, five times the size of the fixed internal time step], then you must increase the number of maxSubSteps to compensate for this, otherwise your simulation is “losing” time.

...

It's important that timeStep is always less than maxSubSteps*fixedTimeStep, otherwise you are losing time. Mathematically,

timeStep < maxSubSteps * fixedTimeStep


Sei die Framerate nun bei 100% Maschinenauslastung nun gerade so dass die Gleichheit gilt, also 1/framerate = maxSubSteps * fixedTimeStep. Nun passiere irgendwas, was die framerate sinken und den timestep damit wachsen lässt, beispielsweise, ein neuer Prozess wird gestartet. Du verlierst nun zunächst die Echtzeiteigenschaft (s.o.). maxSubSteps erhöhen bringt nichts, da das System ja ausgelastet ist (siehe NachoMans Post) es bleibt dir also nur auf die Echtzeit zu pfeifen (das Spiel läuft in Zeitlupe, ist das kein "GodMode"?) Oder die fixedTimeStep hochzudrehen (und dadurch Genauigkeit zu verlieren).


Das ist bei allen mir bekannten Echtzeit/Gaming-PhysikEngines (bullet, ODE, Newton) so.


Du hast immer einen Tradeoff. Hubraum kann man durch nichts anderes ersetzen.

BlueCobold

Community-Fossil

Beiträge: 10 738

Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer

  • Private Nachricht senden

52

08.08.2010, 19:27

Wenn Du lesen und verstehen würdest von was ich rede, dann wäre Dir aufgefallen, dass Du gerade Dinge erzählt hast, der mit dem von mir beschriebenen Problem rein gar nichts zu tun haben. Und das hat auch nichts mit einer internen Anzahl von maxSubSteps zu tun.
Die Echtzeit-Eigenschaft (dauerhaft! und nur das ist im übrigen relevant, da kurzzeitiger Verlust von Echtzeit ausgeglichen werden können muss) zu verlieren ist ein ohnehin schlechtes Zeichen (falls dies der Fall auf optimalen Ziel-System ist), welches darauf hindeutet, dass Du zu viel Zeit für Deine Berechnungen benötigst und somit nur auf gewissen Maschinen sinnvoll einsetzbar ist (oder Du eine höhere System-Anforderung benötigst).
Wenn Du nicht genug Rechenzeit bekommst um die Berechnungen so laufen zu lassen, dass sie den Zeitverlust kompensieren können, dann spricht *nichts* dagegen das Spiel langsamer laufen zu lassen und ich habe auch *nie* behauptet, dass man das nicht darf. Ich habe lediglich gesagt, dass es eine ganz schlechte Idee wäre eine Simulation nur in jedem Frame zu berechnen, da so viele Events wie z.B. Kollisionen oder Bewegungen verschluckt werden und zu Chaos führen, sobald die Framerate extrem sinkt.
Teamleiter von Rickety Racquet (ehemals das "Foren-Projekt") und von Marble Theory

Willkommen auf SPPRO, auch dir wird man zu Unity oder zur Unreal-Engine raten, ganz bestimmt.[/Sarkasmus]

Mastermind

unregistriert

53

08.08.2010, 19:51

Zitat

Ich habe lediglich gesagt, dass es eine ganz schlechte Idee wäre eine Simulation nur in jedem Frame zu berechnen


Lüg doch nicht. Du hast gesagt dass die Simulationen von "cleveren Leuten" auch mit Frameraten von 1 FPS zurecht kommen. Das würde bedeuten, dass die Anwendung so extrem GPU limitiert ist, dass die GPU zwar nur 1 FPS raushauen kann aber die CPU in dieser Sekunde immer noch Zeit hat, die 30 bis 60 Substeps zu berechnen, die eine Physikengine nun mal pro Sekunde benötigt um einigermaßen genau zu arbeiten.

Also entweder du kennst andere Physikengines als ich oder du hast sehr seltsame Anwendungsfälle.

BlueCobold

Community-Fossil

Beiträge: 10 738

Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer

  • Private Nachricht senden

54

08.08.2010, 19:56

Ey wie bist Du denn drauf? Erstens nicht kapieren oder lesen was ich sage, bzw. den Kontext total ignorieren und mich zweitens als Lügner bezeichnen? Zudem kannst Du scheinbar nur in Begriffen wie CPU und GPU denken, obwohl es da noch viel mehr Komponenten gibt, die eine niedrige Framerate verursachen können.
Aber das is mir zu dumm, ehrlich. Mach was Du willst, denk was Du willst. Aber halt die Finger still, wenn Du nur flamen willst.
Viel Spaß noch im Topic.
Teamleiter von Rickety Racquet (ehemals das "Foren-Projekt") und von Marble Theory

Willkommen auf SPPRO, auch dir wird man zu Unity oder zur Unreal-Engine raten, ganz bestimmt.[/Sarkasmus]

Mastermind

unregistriert

55

08.08.2010, 20:00

Zur Klärung: Das "Lüg doch nicht" bezog sich darauf dass du zunächst was anderes behauptet hast, als da steht, nicht dass das was da steht nicht wahr wäre.

Werbeanzeige

Ähnliche Themen