Planet
navi homePPSaboutscreenshotsdownloaddevelopmentforum

Custom Query (296 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (25 - 27 of 296)

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
Ticket Resolution Summary Owner Reporter
#27 fixed Physics Engine bensch patrick
Description

The goal is to implement an engine, that will calculate a congruent physical state on the world. In a first step, implement a simple PhysicsEngine and make a test level, where you are able to play around with the physics - this testlevel is curcial for development, because it will motivate you and your programmer friends…
This task is one of the most important parts in orxonox, the earlier it is implemented, the earlier the other modules in orxonox can be finished. If you need an example of a working physical engine, have a look at HalfLife2 :)
The rest of this document is written in german, ask us for translations, if needed.

  • Konkrete Anwendungszwecke
    • Fallende Koerper: freier Fall nach den physikalischen Gesetzen ACHTUNG: Aufschlag am Boden: kollisionsdetektion
    • Impulserhaltung: stoss von Koerpern. Hebelgesetz mit Rotation etc. ACHTUNG: Daempfung nicht vergessen sonst unendl. bewegung UND: Elastizitaet wichtig, sonst wird zu viel Energie in stoessen uebertragen und die Bewegung erscheint unreal.
    • Traege Beschleunigung, Steuerung von Player-Entities
    • Primitive Teilchen-Systeme: Objekte aus mehreren Teilen, die auseinanderbrechen koennen. Zerfall nach den Gesetzen der Physik
    • Kamera gekoppelt an Spieler mitterls einer unsichtbaren "Feder" →Kamera ist ein physikalisches Objekt
    • "schockwelle" bei explosion: objekte geringen gewichtes wird ein impuls radial weg vom explosionszentrum zugefuegt.
    • gravitationsrackete: oeffnet einen gravitationsschlund, der alles einsaugt, dass dumm und/oder langsam ist.
    • Physikalisches Antriebssystem fuer Flugkoerper
      • leistung (kWatt) → beschleunigung
      • aktivierung-delay
  • Ansprueche an die Physics engine:
    • Physikalische Koerper (z.B. WorldEntities) modelieren. Physikalische Eigenschaften beruecksichtigen wie:
      • Masse
      • Traegheit (moment)
      • Geschwindigkeit/ Beschleunigung
      • Schwerpunkt
      • (Dreh)impuls
      • Daempfung von bewegung, z.B. Luftwiderstand (damit bewegung nicht inf.)
      • Energie (Kinetisch/Potentiel)
      • Position (Localtion/Position)
      • Orientation (Location/Position)
    • Materialeigenschaften (Body):
      • material/fluid/field/nothing (enum)
      • "quetsch-koeffizient" bei kollisionen (impulserhaltung), der direkt in schaden umgerechnet werden koennte.
      • Breakable:
        • strength (0.0 - 1.0)
        • force Limit (0.0 never breack)
        • torque Limit
    • Fake Eigenschaften wie (Body):
      • isMoveable
      • isDestroyable
      • physikalische interaktion aktivieren/deaktivieren (flag?)
    • Umwelteigenschaften:
      • daempfung von bewegung (damit nicht unendl. bewegung)
    • Interaktionen
      • Kopplung von Objekten durch Federn/(=Kraftfelder)
  • Implementierung
    • Zentrale liste der Objekte (entities?) in class World
    • Zentrale Berechnung der physikalischen interaktionen vor jedem Spielzug (vorzugsweise eine Methode wie void World::collide())
    • berechnung der aenderung des momentanen zustandes pro objekt, dass muss so einfliessen, dass das objekt dann in der neuen situation wieder gerendert werden kann.
    • bestimmte interaktionen herausfiltern/deaktivieren (z.B. interagieren zwei Haeuser nicht miteinander etc.) - isA - Methode?
  • Offene Fragen
    • Relationen/Umrechnung von Kollision/Impulsweitergabe(erhalung)/Schaden
    • genauigkeit der Berechnungen ↔ rechenaufwand → interpolation
    • bestimmte interaktionen herausfiltern/deaktivieren (z.B. interagieren zwei Haeuser nicht miteinander etc.) - isA - Methode?
#31 fixed vertex-arrays bensch bensch
Description

Models are put through to the Graphicscard much faster, if they are packed into vertex-arrays

  • Problem:
    • add Vertices/Normals/Texture Coordinates to an Array.
    • pack array into a glList
  • Interface:
    • returns: glList or Array
#32 fixed Gui-Fork bensch bensch
Description

The Gui must fork after haven run, that means it must have an option to start without GTK even if it was compiled with it.

  • Idea:
    • The gui represents a Data-Structure, that handles many different Options.
    • The gui parses the ini-file, and also writes it.
    • easy to use interface
  • Interface:
    1. read-in, manipulate, save, fork, (end first process), read-in, start Game
    2. read-in, if gui not wanted, start Game.

the sense is:

  1. GTK will not interfere with SDL
  2. only one thread is working during playing of the Game.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
Note: See TracQuery for help on using queries.