Hi,

hab mal ne kurze Frage, ist ODE besser als Newton?

Hier noch ein Nachtrag, der Downloadlink im Menü deiner Homepage für IrrOde funktioniert nicht, da du das O im Dateinamen klein geschrieben hast... Vielleicht solltest dein File Script nicht so kleinlich sein und einfach die kleingeschriebene Variante vergleichen...

Gruß
Scarabol

_________________
My Toolbox:
- Irrlicht 1.7.1
- Blender 2.49a
- Microsoft Visual C++ Express Edition 2008
- Newton Game Dynamics 2.xx
Regeln zur Programmierung:
Regel 1: Die Programmiersprache hat keine Fehler.
Regel 2: Solltest du doch einen Fehler finden, tritt automatisch Regel 1 in Kraft.

Hallo,

verdammt ... die Sache mit dem großen "O" hat auch im englischen Forum schon mal jemand geschrieben. Vielleicht sollte ich das Ganze einfach in irrode.zip umbenennen. Das mit den großen / kleinen Buchstaben ist halt so eine Linux Sache, mein Script ist nicht kleinlich.

Newton/ODE: ich kann dir auch nicht sagen, ob eine der Engines wirklich besser als die andere ist, vor allem kommt es immer sehr darauf an, wofür du sie benutzen willst. Am besten einfach ausprobieren, evtl. auch PAL (http://www.adrianboeing.com/pal/index.html) mal anschauen ... ich hab es zum Vergleichen unterschiedlicher Engines hergenommen, da sind ein paar Benchmarkprogramme dabei. Es gibt zwei Gründe, warum ich bei ODE bleibe:

- (bis jetzt) für alles ausreichend, was ich damit machen will
- hab schon Erfahrungen damit gesammelt (Marbles (mein erstes Irrlicht Spiel), irrOde)

_________________

Ich brauch die Engine eigentlich nur, um in meinem Weltraumballerspiel die Spieler aus den Stationen und anderen Spieler rauszuhalten. Also Gravitation oder sowas fällt komplett raus, und an Newton nervt mich halt das ich es nicht schaffe die Bodies vernünftig mit den Irrlicht Meshs zu verknüpfen...

Gruß
Scarabol

_________________
My Toolbox:
- Irrlicht 1.7.1
- Blender 2.49a
- Microsoft Visual C++ Express Edition 2008
- Newton Game Dynamics 2.xx
Regeln zur Programmierung:
Regel 1: Die Programmiersprache hat keine Fehler.
Regel 2: Solltest du doch einen Fehler finden, tritt automatisch Regel 1 in Kraft.

Für reine Kollision ist doch ne Physikengine völlig overkill. Das kann man selbst an einem Tag machen ohne sich noch in eine weitere API einarbeiten zu müssen.

Schonmal auf der Irrlicht homepage das Newton Tutorial angeguckt?

_________________
Phenom X4 9950 BE | 6144MB DDR2-800 | GeForce 8800GT 512MB | Asus M3A32-MVP Deluxe | 2TB HDD | 520W Seasonic NT | Soprano Tower | Samsung 22" TFT + Fujitsu-Siemens 17" TFT + Toshiba 42" FullHD LCD | Windows 7 Proessional x64
Behind the Brain

Also ich denke schon, dass ODE für ein Weltraumballerspiel geeignet ist (wenns sowas wie z.B. X-Wing ist), denn imho sollten die Objekte nicht nur kollidieren sondern sich (falls sie kollidieren) auch halbwegs realistisch verhalten. Genau das hat meine früheren Projekte (zu DOS und Win95 Zeiten) immer beendet, ein brauchbares Verhalten hab ich da einfach nicht hingekriegt.

_________________

Ich hab nie das Gegenteil behauptet

Klar sollte man für ein realistisches Verhalten eine Physikengine benutzen, aber oftmals reicht auch schon die bloße Kollisionserkennung ohne realistisches Stoßverhalten. Das meinte ich

_________________
Phenom X4 9950 BE | 6144MB DDR2-800 | GeForce 8800GT 512MB | Asus M3A32-MVP Deluxe | 2TB HDD | 520W Seasonic NT | Soprano Tower | Samsung 22" TFT + Fujitsu-Siemens 17" TFT + Toshiba 42" FullHD LCD | Windows 7 Proessional x64
Behind the Brain

Ist schon klar.

Für viele Spiele reicht es ja auch schon, wenn die Raumschiffe explodieren sobald sie kollidieren, aber ich muss ja auch ein bisschen Werbung für meinen Wrapper machen

_________________

Mal wieder ein Update: hab eine Version mit einem Bugfix hochgeladen: die Landschaft funktioniert jetzt auch, wenn der ITerrainSceneNode nicht an der Position (0,0,0) liegt.

_________________

Neues Update: ich hab ein kleines Demospiel (IrrOdeMarble) eingebaut. Damit kann man sich anschauen, wie einfach es ist, mit Hilfe von Irrlicht, IrrOde und IrrOdEdit ein Spiel zu bauen. Ist nix spektakuläres, aber nett ist es allemal

_________________

Hi,

geniales Projekt kann ich da nur sagen.

Ich habe mich jetzt mal eingehender damit auseinandergesetzt. Jedoch hab ich so ein paar Fragen:

Im Playground Beispiel wird ja mit Trimesh gearbeitet. Wofür ist die Dummy SceneNode gut? Also irgendwie habe ich begriffen das es nich ohne geht, aber was die genau macht versteh ich nicht richtig.

Ich hatte vor eine KollisionsSphere um eine FPS Kamera zu machen, und habe wie beim HelloWorld Sample eine Sphere erstellt und dann in der Hauptschleife um die Kamera positioniert. Jedoch hat das zur Folge das die Sphere sich immer schneller zu drehen anfängt und Kollision gibts auch keine. (Mit geht es darum das die Kamera Objekte wegschieben kann, nicht das die Kamera selbst zurückgeschleudert werden kann)

MFG
FTC

_________________
Cold-Death
Magnon

Hallo,

danke für das Lob. Zu deinen Fragen:

- das Trimesh hat eine Besonderheit: als einziges Geom kann es mit Kindern was anfangen. Man kann einen SceneNode mit schön vielen Polys definieren, da das GeomTrimesh dranhängen, und als Child des Trimesh nochmal einen Node mit weniger Polys laden. Das sollte die Kollisionsabfrage beschleunigen. Du kannst dir ja mal im data Verzeichnis die Modelle "trimesh.3ds" und "trimesh_collision.3ds" anschauen. Das "_collision" Modell ist ein bisschen einfacher, denn die Kollisionen mit den einzelnen Polys des Raktenmotors sind imho nicht wichtig.

- Für FPS Charaktere nimmt man laut opende wiki (http://opende.sourceforge.net/wiki/index.php/HOWTO_upright_capsule) am Besten eine Capsule. Ich hab das zwar noch nicht ausprobiert, aber es sollte so gehen. Allerdings (wenn ich mich recht entsinne) bedeutet ein maxAngularSpeed von "0" in meinem Wrapper, dass dieser Wert deaktiviert ist, du müsstest also nach jedem Step die Winkel per Hand setzen. Dafür gibt es das "CIrrOdeEventStep", das nach jedem "step" Aufruf gepostet wird. Einfach einen IrrODE-Listener für dieses Event definieren und dann die Winkel entsprechend setzen.

Ich hoffe, ich konnte dir helfen.

_________________

Hallo,

ich hab gerade ein neues Update hochgeladen. Der Hauptunterschied ist im IrrOdEdit plugin: wenn man jetzt einen IrrOde scene node klont, dann wird der komplette Baum ab dem node mitgeklont. Spart einen Haufen Arbeit, hätt ich früher einbauen sollen.

Die Kollisionsabfrage zwischen statischen Trimeshes und den meisten anderen Objekten funktioniert in der gcc Version immer noch nicht. Ich hab von der ODE user's group eine mögliche Lösung bekommen: u.U. funktioniert das mit ODE 0.11.1 (im Augenblick läuft IrrODE mit 0.11), falls nicht soll ich die aktuellste Version aus dem SVN probieren. Mit Visual C++ funktionirts (komisch, ist aber so). Das Problem tritt in zwei der Programme auf:

- im IrrOdeMarble demo Spiel fallen ein paar der Hindernisse einfach durch das Trimesh durch, auf dem sie stehen sollten
- IrrOdePlayground ist ziemlich nutzlos, wenn man beim Start auswählt, dass für das Terrain Trimesh statt Heightmap verwendet werden soll.

Komischerweise funktioniert das Ganze bei den VC++ Versionen der Programme.

_________________