3D-Spiel

[Matthias K.]

Hallo zusammen!
Ich überlege mir ein etwas größeres 3D-Spiel mit Java zu entwickeln.
Dabei möchte ich keine 3D-Bibliotheken nutzen, sondern meine eigene entwickeln.
Der Grund ist das Verständnis um die 3D-Programmierung und die uneingeschränkten Rechte,
sowie die Möglichkeit etwas besonders leistungsfähiges zu entwickeln.
Die Darstellungsklassen des Spiels sollen Körper darstellen, die sich aus beliebig vielen
Flächen zusammensetzen, auf diese Bilder projezieren und alles nach einem Fluchtpunkt
ausrichten. Für diesen Teil und das Überprüfen, ob sich Körper berühren, habe ich schon eine
Lösung.
Jedoch möchte ich auch etwas Physik in das Spiel einbauen.
Ich denke da an das Verhalten von fallenden Körpern - das Rotationsverhalten.
Wie realisiere ich, dass z.B. ein Würfel einen Berg hinunterrollt?

Kennt sich irgendwer mit diesem Teil der Mechanik aus? Oder gibt es Bibliotheken die
dies können?

Bin dankbar für jede Hilfe.

Gruß,
Matthias

 

[muckelzwerg]

Du musst Dich in das Thema einarbeiten, lernen wie 3D-Grafik funktioniert, wie Physikengines funktionieren und DANN kannst Du entscheiden, ws Du von Hand machst und wofür Du Bibliotheken verwendest.
Ist nicht böse gemeint, aber wühl Dich mal in die Themen rein und in ein paar Monaten oder vielleicht schon Wochen, sieht das alles wieder ganz anders aus.

Sowas

Dabei möchte ich keine 3D-Bibliotheken nutzen, sondern meine eigene entwickeln.
Der Grund ist das Verständnis um die 3D-Programmierung und die uneingeschränkten Rechte,
sowie die Möglichkeit etwas besonders leistungsfähiges zu entwickeln.

liest man ziemlich oft. Allerdings kommt da meist gerade keine besonders leistungsfähige Software heraus.
Genauso ist das Verständnis von "3D-Programmierung" nunmal das Verständnis der üblichen Werkzeuge.
Noch eine Ebene Tiefer ist es "Das Verständnis der zugehörigen mathematischen Transformationen".
Dafür brauchst Du nur Papier und Stift.
Wenn Du was zu "3D-Programmierung" lernen willst, schnapp Dir ein Buch über OpenGL, vielleicht noch mit einer CD dazu und leg los.
Da Grafikkarten und Software stark aufeinander abgestimmt sind, wirst Du ohne das Verständnis dieser Werkzeuge, ziemlich sicher nichts "besondes Leistungsfähiges" entwickeln.

 

[Matthias K.]

Hi muckelzwerg,
danke für deine Antwort. Ein guter Tipp, jedoch geht es mir vor allem, um die Mathematik,
die hinter dem Fallverhalten von Körpern steckt.
Ich benötige Klassen, die das Fallverhalten berechnen oder eine Idee/Ansatz um diese Klassen
selbst zu entwickeln.

Zur 3D-Bibliothek:
Zugegeben habe ich mich noch nicht besonders mit den vorgefertigten Bibliotheken
beschäftigt. Nur das, was ich bis jetzt gesehen habe, reicht mir nicht wirklich aus.
Ich möchte selbst ein Programm entwickeln, was keinen Pixel zu viel füllt und wenn nur
der gesamte Bildschirm gefüllt wird, schlägt dies glaube ich nicht so sehr auf die Grafikkarte.
Bei transparenten Körpern wird es dann schon interessanter.

Gruß,
Matthias

 

[muckelzwerg]

Sorry, ich hab keinen Plan, was Du meinst.
Die Gesetze fürs Fallen findest Du in der Physik-Formelsammlung und z.B. bei Wikipedia.
Das ist doch sowieso nur eine feste Beschleunigung in eine bestimmte Richtung.
Die schiefe Ebene findest Du auch "überall".
Der Ansatz um solche Klassen zu entwickelt ist einfach "Physikbuch" kaufen.
Dann bastelst Du damit ein wenig rum und machst dann das, was fast alle machen -> PhysX, Havok, ODE, Bullet, Tokamak, Newton ... oder eine andere Engine verwenden.

Was für "vorgefertigte" Bibliotheken meinst Du denn?
Willst Du erstmal einen eigenen Grafikkartentreiber schreiben, oder wie soll das ganz von alleine gehen?
Was hast Du denn bisher gesehen, was Dir nicht ausreicht?
Weißt Du, wie eine Grafikkarte funktioniert?
Weißt Du, wie eine Renderingpipeline bspw. die von OpenGL aufgebaut ist?
Weißt Du, welche Shading-Verfahren zum Einsatz kommen und wie sie berechnet werden?
Weißt Du, was in Bibliotheken wie OpenGL alles an Optimierung steckt?
Weißt Du, wie Transparenz implementiert ist?
...

Überleg Dir mal Folgendes:
Die ganzen Ziele, die Du hier ansprichst, haben sich die Entwickler solcher Bibliotheken ganz am Anfang bereits gestellt.
Und herausgekommen ist das, was wir heute als Werkzeuge für 3D-Programmierung verwenden.
Wenn Du sagst, dass Dir das alles nicht reicht, ok. Aber dann müsstest Du das doch alles kennen, oder nicht?
Dann würdest Du doch eher uns Vorträge geben, wie Du es besser gemacht hast, anstatt zu fragen, wie es funktioniert.
Stattdessen sagst Du aber, dass Du Dich bisher kaum damit beschäftigt hast.
Da stehen die Chancen doch ganz gut, dass in diesen ominösen Bibliotheken vielleicht der ein oder andere Trick zur Optimierung schon implementiert ist.

 

[Matthias K.]

Hi,
wie gesagt, ich möchte mein Programm so optimieren, dass nur jeder Pixel (ohne Transperenz)
einmal gefüllt wird.
Und ich meine nicht die Berechnung von z.B. Fall-Geschwindigkeiten, sondern meine ich z.B.:
Ich Spanne einen Körper aus n Vektoren und berechne seinen Schwerpunkt.
Nun lasse ich ihn, wie eine Kiste einen Berg hinunter fallen.
Wie ändern sich nun die Spann-Vektoren?
Das ist meine Frage.

 

[Marco13]

Physically Based Modeling , Kapitel "Rigid Body Dynamics". Keine Angst, sowas wie das mit dem Trägheitstensor (siehe Anhang) muss man nicht undbedingt im Detail nachvollziehen

 

[muckelzwerg]

Wie gesagt, Du kannst davon ausgehen, dass derartig simple Ansprüche wie "jeder Pixel wird einmal gefüllt" in allen Grafikumgebungen erschlagen bzw. besser gelöst sind.
Eigentlich ist das für eine 3D-Szene auch kein passendes Kriterium und hat eigentlich keinen Bezug zu effizientem oder ineffizientem Rendering.
Einen Software-Renderer zu schreiben ist eine gute Übung. Aber der Gedanke "ich mach was Besseres" ohne überhaupt tieferen Einblick zu haben, was es schon gib, der ist freundlich formuliert "optimistisch".
Solange Du mit gewöhnlicher PC-Hardware arbeitest, wirst Du beim Software-Rendering immer gegen die hardwarebeschleunigte Variante auf der Grafikkarte verlieren, wenn Du keine abstrußen Spezialfälle bearbeitest.
(3D-Spiel != abstruser Spezialfall)



"Klassen" die das Fallverhalten berechnen finden sich in den Physikengines, die ich Dir geschrieben habe.
Hast Du die mal angeschaut? Sind die nicht gut? Tun sie nicht was Du willst?
Wo ist das Problem?
Die Berechnungsverfahren verschiedener Physiklöser finden sich in der Doku oder in entsprechenden Papers.
Kaufman et al. haben z.B. was zu frictional dynamics, was zu Deiner schiefen Ebene passen könnte.
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.84.8659&rep=rep1&type=pdf
Von Chris Hecker gibts was fürs Game Developer Magazine
Rigid Body Dynamics - Chris Hecker's Website
Für Constraints zwischen fallenden Körpern, musst Du Dir anschauen, wie die Joints gemacht werden. Speziell Ragdoll-Algorithmen sind da interessant.

 

[Landei]

Da muss ich muckelzwerg beipflichten. Wie hast du programmieren gelenrnt: In dem du eine bestehende Sprache verwendet hast, oder in dem du eine eigene Sprache entworfen hast? Sicher ist das Schreiben einer eigenen Sprache eine exzellente Übung, aber erst wenn man programmieren kann. Genauso ist es mit 3D und Physik.

 

[Matthias K.]

Hi,
danke für die schnellen Antworten.
Ich werde mal versuchen alles durchzuarbeiten.
Das mit der eigenen 3D-Bibliothek ist vor allem für Lernzwecke.
Wenn ich in der Lage bin, einen eigene derartige Bibliothek zu entwickeln,
kann ich diese Kenntnisse in anderen Programmiersprachen ebenfalls realisieren.
Mal sehen, wie weit ich komme und mal sehen, wie viel Leistung am Ende benötigt wird.

Gruß,
Matthias

 

[muckelzwerg]

Wenn Du einen Renderer schreiben willst, schau Dir existierende Renderpipelines an.
Es gibt genug Beschreibungen im Internet und in fast jedem OpenGL-Buch ist das auch dabei. Da findest Du die wesentlichen Bestandteile und kannst mal ein paar Sachen nachbauen.
Da wirst Du jede Menge Stellen finden, bei denen Du denkst "ja klar, geht eigentlich nicht wirklich anders"
und vermutlich jede Menge Stellen, bei denen Du denkst "oh cool, das wäre mir nicht eingefallen".
Wenn Du aber sehr oft denkst "häh? warum machen die nicht ... das ist doch viel einfacher" dann wird es spannend.

Letztlich hängt aber alles daran, dass die gewohnte Pipeline eben auf der Grafikkarte implementiert und optimiert ist. Du kannst mit Shaderprogrammen einige Stellen überschreiben, aber das Gesamtbild bleibt.
Und wenn Du es tatsächlich schaffst einen Software-Renderer zu schreiben, der annähernd gleiche Qualität wie aktuelle Grafikkarten bringt und dabei noch schneller ist ... brauchst Du wohl nicht mehr arbeiten gehen.

Eine andere (leichtere) Übung ist ein Raytracer. Da lernst Du schon einiges über Shading und kannst schöne Bilder erzeugen.

 

[Empire Phoenix]

Raytracer performant umzusetzen ist aber auch eine wissenschaft.

Aber ich empfehle dir dringenst besthende biliotheken aka lwjgl oder gar jme(was dann eine vollwertige gamenengine wäre) zu benutzen. Weil um diese effizient zu benutzen brauchste schonmal ein-zwei jahre einarbeitung, und physic wird da nur oberflächlich bei gekratzt, sonst sinds durchaus noch 2 Jahre mehr.

 

[Kr0e]

Sei mir nicht böse, ich respektiere solche Vorhaben, aber das was du da als One-Man Projekt gedacht hast, ist so nciht durchführbar. Also nicht in angemessener Zeit, ok vlt in 5-8 Jahren. Aber dann gibts vlt schon kein openGL mehr

Jeder Schritt in Richtung vorwärts basiert auf dem Letzten. Die Technik auf der heute die 3D Engines basieren, ist shcon verdammt ausgereift. Generationen von Entwicklern haben sich darüber Gedanken gemacht und haben entwickelt wie sosnt was. Da iwas besser/schneller machen zu wollen zeugt von mangeldem Wissen(oder gar Respekt) in Bezug auf die existierenden Projekte.

IMHO musst du nicht selbst in der Lage sein, eine 3D Engine zu programmieren. Du musst in der Lage sein, existierende Bibliotheken zu nutzen und zu kennen.

Ich meine dafür gibt es doch diese ganzen unzähligen Projekte... Stell dir mal vor, jede Firma müsste immer alles von der Pike auf selbst machen. Sachen wie Eclipse, OSGi, jMonkeyengine, Bullet-Physics, Maven, Swing... Oder gar die Programmiersprache ?!

Da würde doch nie iwas produktives rauskommen.

Und spätestens wenn dich einmal in Libs wie jME3 oder Ardor3D eingearbeitet hast, willst du sowas nicht mehr missen. Vorallem wenn du siehst, was hinter diesen 30 Zeilen steckt, die bei jME3 z.B. ausreichen, um physikalische Quader mit einer kugel zu beschießen...

Die Mathematik die bei einer Physikengine z.B. benötigt wird, geht weit über das hinaus, was man im Physik Bachelor lernt. Vlt findet man bei Google hier und da ein paar kryptische Codesegmente zum thema RigidBodyDynamisc aber das heißt noch lange nicht, dass du auch verstehst, was da vorgeht.

-
Chris

 

[Marco13]

Nun, natürlich stimmt das, aber die Intention an sich ist ja nicht vollkommen verkehrt. Man sollte nur nicht davon ausgehen, dass man irgendeinen Erfolg damit haben wird. Aber mal zu versuchen, beim berühmten Bresehnham angefangen über eine eigene Matrix-Klasse und Cohen-Sutherland-Clipping bis zum Pixel auf dem Bildschirm zu gehen (eben kurz gesagt: Mal den Foley "runterprogrammieren" ) liefert einige Einsichten (und sei es nur, dass man auf diesem Weg nicht weit kommt). Und die verlinkten Siggraph Course Notes zu Rigid Bodies kann man tatsächlich recht schnell zu einem umherfliegenden Würfel zusammenbasteln (die Kollisionserkennung ist dann aber nochmal ein Thema für sich).
Natürlich wird seit 40 Jahren an Rendering geforscht, und auch nur in Erwägung zu ziehen, man könnte ein Polygon mit einer for-Schleife in Java schneller füllen als die Grafikkarte das (mit OpenGL) kann wirkt... ja, naiv, aber das ist wohl gar nicht das Ziel. Und nebenbei...: Sowas wie jPCT java 3d engine bilinear filtering texture bump mapping gouraud demo download free jpct api animation skeletal erreicht in Software auch mehr, als manche mit der JME zustande bringen würden. Wie viele Mannjahre da drin stecken, kann man aber nur schwer einschätzen.

 

[muckelzwerg]

Phoenix ja klar, aber in Bezug auf die typische 3D-Programmierung ist es relativ einfach. Im wesentlichen hast Du eie Shaderfunktion und ein bisschen was zur Kollision.
Dass es wirklich rennt ist ja eher allgemeine "Programmierer Mathematik".
Bei einem Rasterizer muss man schon etwas länger arbeiten, bis da mal was Vergleichbares zu sehen ist.
Zudem kann man bei Raytracing oder Radiosity auch sehr schöne offline Bilder erzeugen. Die brauchen halt länger, sehen aber schon sehr geil aus, auch wenn man gar nicht sooo viel daran gearbeitet hat.


Der Ansatz sowas selbst zu machen, ist eigentlich sogar sehr gut. MIR stößt nur echt sauer auf, dass die bestehenden Dinge dabei ignoriert werden.
Da rennt man dann lauter Wege nach, die schon vor Jahren als ineffizient abgehakt wurden. Und dabei gibt es noch genug ineffiziente Wege, die noch nicht gegangen wurden. (fail better next time)
Es ist doch sinnvoller, sich bestehende Systeme anzuschauen (deshalb OpenGL und keine 3D-Engine) und kennenzulernen, was es alles gibt.
Man schafft sich dadurch die Grundlagen drauf, lernt die Spielzeuge kennen, mit denen man es bei dem Thema zu tun hat und kann dann Stück für Stück entscheiden, ob und wo man etwas verbessern kann.
Zum Lernen der Grundlagen ist ein Selbstmachen auch nicht schlecht. Aber auch da emfpiehlt es sich erst nachzubauen und dann mal weiterzusehen.

Sonst ist das wie "So, jetzt back ich mal eine bessere Sachertorte, als die Aktuelle. Ich hab zwar keine Ahnung vom Konditorhandwerk und wie sie schmeckt weiß ich auch nicht, aber egal."

 

[Matthias K.]

Hi,
danke für alle Antworten.
Ich hab jetzt noch ein paar Fragen zu OpenGL:

Wie projiziert man 2D-Bilder auf eine Fläche (z.B. auf eine Seite eines Quaders)?
Kann man mit OpenGL eine Lichtquelle erzeugen,
sodass alle Körper einen Schatten werfen (z.B. eine Sonne simulieren)? -> Hab gerade
nichts zum testen da.

Gruß,
Matthias

 

[Kr0e]

Nein OpenGL berechnet keine Schatten. Das musst du mit Stencil Buffern emachen oder ShadowMaps. Allerdings sehen ShadowMaps hässlich aus, dafür verurscahen die aber auch nicht ansatzweise soviel Overhead wie StencilShadows.

Zur ersten Frage: Dafür gibt es Texturen. Aber lies doch bitte ein Buch oder Tutorials und stelle hier speizelle Fragen. Du hast ja nichtmal Basiswissen, also wäre es sowieso sinnfrei hier Codes für Schattenerzeugung etc. zu posten da du damit ja ncihts anfangen könntest...


Nimm dir vlt mal die NeHe (NeonHelium) Tutorials vor. Ist zwar in C geschrieben, aber das sollte man sowieso früher oder später beherrschen (z.B. für JNI).

-

 

[Matthias K.]

Hi,
sehr gut! Jetzt habe ich zu allem Berge von Tutorials.
Hab mich jetzt für OpenGL entschieden. Macht einen sehr guten Eindruck.
Außerdem kann man es auch mit i os verwenden.

Danke für die Hilfe! :toll:

Gruß,
Matthias

 

[EgonOlsen]

Das:

Hab mich jetzt für OpenGL entschieden. Macht einen sehr guten Eindruck.

passt nicht zusammen mit dem:

wie gesagt, ich möchte mein Programm so optimieren, dass nur jeder Pixel (ohne Transperenz) einmal gefüllt wird.

Wenn du letzteres erreichen willst, musst du deinen eigenen Rasterizer schreiben und sowas wie einen S- oder Span-Buffer implementieren. Aber das hat man vor 15 Jahren gemacht, als alles auf langsamen CPUs lief und Füllrate kostbar war. Selbst jPCT (die Basis des Softwarerenderers da drin ist "nur" etwa 12 Jahre alt) macht das nicht mehr bzw. nur noch als Approximation, weil es heutzutage keinen Sinn mehr ergibt. Wenn du diesen Anspruch hast, läufst du in die völlig falsche Richtung. Füllrate wird mit Abstand dein kleinstes Problem sein.