PureBoard

Zaphod hat geschrieben:Wenn du nur ein Spiel machen willst und dich eigentlich nicht auf diesem Level mit der Materie beschäftigen willst, würde ich dir doch eher zur Verwendung eine fertigen Engine raten. Das erhöht die Wahrscheinlichkeit ein Projekt zu ende zu bringen beträchtlich.

Es ist so das ich mich für die Mathematik die da drin steht schon sehr intresiere. Und macht mir irgendwie viel mehr spaß alles selber zu machen, als mit einer fertigen engine zu arbeiten.
Also vielen Dank mal, und ich werd mich umsehn.

//edit:

Wie siehst eigendlich mit so einer Art Hitbox wie bei cs aus? Das dürfte doch nicht so dramatisch große Probleme geben, oder. Man müsste nur irgendwie schaffen OpenGL dazu zu kriegen nich dargestellte Punkte zu berechnen...

Andreas

Die hitbox brauch OpenGL gar nicht erst zu kennen, da es wie gesagt eh keine kollisionsfunktionen mitbringt. Das Problem bleibt aber das gleiche, nur halt mit weniger Polygonen.

jaja das ist klar... aber kann ich mit OpenGL die aktuelle Position eines Punktes herausfinden, oder muss ich das selbst ausrechnen.

Es gibt sicher einen Weg das über OpenGL herauszufinden, aber da wüsste ich jetzt nicht wie. Ist aber sowieso nicht schwer selbst auszurechnen, das ist je eine einfache Rotation+Transformation. Wenn du eine 3d-engine von Grund auf selbst entwickeln willst, dann sollte Matrixrechnung und ihre Anwendung auf 3D Programmierung sowieso schon zu deinem Handwerkszeug gehören.
Da gibt es aber eine Menge guter Bücher zu.

"3D Game Engine Architecture" (Englisch... ob es eine deutsche Ausgabe gibt ist mir nicht bekannt) ist imho durchaus empfehlenswert, auch wenn es wie alle Bücher von Eberly streckenweise etwas sehr Mathematisch und generell sehr trocken ist (man merkt ihm den wissenschaftlich Mathematischen Hintergrund stark an). Das Buch hat auch ein eigenes Kapitel zum Thema Kollisionsfindung.
Sicher lässt sich aber auch was über google finden zu dem Thema.

Ja, daran hab ich am anfang auch schon gedacht. Wäre schön sowas selber zu machen... aber ich bin grad einmal bis zur rotation gekommen...
sin und cos ist für mich kein Problem aber als nächstes in einer engine steht ja 3D - Überlappung / Verdeckung an.
Das ist schon ein größeres Problem. Dachte ich kann das mit einem Z-Achsen sortierten Array machen, hab aber nach fertigsellung gemerk das das so auch nicht gehn kann.
Desswegen hab ich mir gedacht ich mach das ganze in OpenGL...
In der Schule in Mathe sind wir gerade einmal bei gleichungs-lösungs - systeme...
Das was ich an sonnsten kann hab ich mir sebst beigebracht (zB sin, cos). Obwohl das ja auch nicht so extrem ist...

Das heißt Matrix kenn ich nur vom hören. Ich hab im prinzip keine Ahnung was das macht und wie man das nutzt.

So ein Buch über die Berechnung wäre Klasse . Mal sehn ob ich das in Deutsch bekomm...

ps. ja... ich weiß schon das ich das ausrechnen könnte... aber ich dachte wenn OpenGL das so oder so ausrechnet dann würde ich auch ein bischen zeit sparen...

Danke, Andreas.

Die Überlappungen sind genauso viel/wenig ein Problem wie bei OpenGL (ich meinte auch eine Engine die OpenGL nutzt... für einem Softwarerasterizer würde ich heutzutage meine zeit nicht Aufwenden).
Für die generelle Darstellung können dir Überlappungen egal sein, solange du einen Z-Puffer hast und den hast du ja normalerweise.
Die einzige Ausnahme sind transparente Elemente, die müssen vor der Darstellung nach tiefe sortiert werden.

Einzig und allein für das Szenenmanagement werden überlappungen und verdeckungen interessant, aber damit musst du dich auch bei einer ernstzunehmenden OpenGL basierenden Engine beschäftigen, weil OpenGL da natürlich auch keine Funktionalität mitbringt.

Mich interessiert das selbst programmieren eineir Engine immer mahr... (ich meine ohne OpenGL)

Da gibts aber auch noch ein paar Probleme... OpenGL ist ja eine direkte Schnittstelle zur Grafikkarte. Jede Grafikkarte hat ja interne Befehle wie zB eine Poligon darstellung, oder? Kann ich die auch ohne OpenGL ansteuern?

//edit:

bevor ichs vergesse... ist Z-Buffer ein speicher wo die Z-Achsen überlappungen rein kommen? oder irre ich mich da jetzt total?
Ich weiß nur das es verschiedene tiefen gibt... 16 bit, 24 bit, ...

Danke, Andreas

Andreas_S hat geschrieben:Mich interessiert das selbst programmieren eineir Engine immer mahr... (ich meine ohne OpenGL)

Dann ist es ein Renderer, keine Engine. OpenGL und DirectX werden von Engines verwendet. Um den Windows HAL zu umgehen gibt es zwar ein paar Bibliotheken, aber niemand will das, außer man arbeitet an eigener Hardware.

Achso, mit engine meinst du dann eine Bibliothek die eine Softwarerasterizer implementiert. Da gibt es auch ein gutes Buch zu: "3D-Grafik Programmierung" von Marius Apetri, das ist auch auf deutsch.

Die Grafikhardware kannst du dann aber komplett vergessen.

Ein Z-Puffer ist im Prinzip ein 2D Bild, in dem deine Zeichenroutine Pixelweise Tiefeninformationen beim Zeichnen ablegt. Willst du dann ein neues Polygon zeichnen siehst du für jeden Pixel nach, ob er denn auch näher am Betrachter ist als ein schon existierender. Das funktioniert an sich ziemlich gut, skaliert aber nicht besonders gut mit der Auflösung, will heißen, bei sehr hohen Auflösungen ist das eher langsam.

Für dieses Vorhaben würde ich dann aber doch dringend zu einem Buch raten, denn da gibt es sehr viele komplizierte Dinge mit denen man sich beschäftigen muss.

EDIT: DD war mal wieder schneller

Ja ein Buch werd ich mir besorgen sonst wär die sahe viel zu schwer...

Mein größtes Problem ist aber immernoch die Mathematik des Renderers...
Ist in dem Buch auch was über Mathematik?

Ok, Z-Buffer ist eine gute technik. Ist das eine Grafikkarten Funktion oder eine die man selbst machen muss?

Wie macht das denn OpenGL oder DX mit den Spezialfunktionen? Verwenden die diese Bibliotheken? Oder haben die ein eigenes System entwickelt?

Wie schlimm wäre es denn wenn ich DX oder OpenGL zum Polygon zeichnen verwende? Oder ist das nicht möglich?

Andreas