3d engine
-
H.L.T.O schrieb:
Naja, definiere eine Engine?
Um es kurz zu machen: Code, der OpenGL oder DirectX "initialisiert" und dann Dreiecke oder Quader anzeigen kann ist keine Engine (für mich). Ohne Speicher-/Texturen-/Sonstwas-Verwaltung, Optimierungsalgos á la BSP, PVS, Octrees bzw. generell SGM ist es doch nur Code, der ein paar API-Aufrufe macht...
-
0x00000001 schrieb:
Zum Thema Portals:
Wie erkenne ich, welche Geometrie durch welche Portals verbunden wird?
Angenommen, ich habe meinen Level, und da setze ich dann im Editor Rechtecke oder was auch immer rein, was die Portals darstellen soll. Dieser Teil soll noch manuell sein. Ich habe mir überlegt, wie man die Geometrie dann automatisch zuweisen könnte, es ist aber sehr kompliziert, mein Gehirn war nicht ausreichend um den Algorithmus fertigzudenken, geschweigedenn ihn zu codieren.Ich hoffe, ich habe richtig verstanden, worauf du hinaus willst: Du hast die Portale gesetzt, und nun möchtest du die gesamte Polymenge in Untermengen aufteilen, so das es in keiner Untermenge zwei Polys gibt, die auf verschiedenen Seiten eines Portals liegen?
Bye, TGGC (Der Held ist zurück)
-
Meine Fragen sind zum Beispiel:
Warum gibt es in 3d engines immer einen Treiber, wozu ist der gut und vor allem: Der Treiber ist in allen engines die ich kenne immer eine dll, auch wenn das ganze übrige Projekt statisch gelinkt ist, warum?
Wie ist eine richtige 3d engine gemacht? Kommuniziere ich mit dem Treiber? Mit dem HAL oder mit Direct3D?
Was bsp und pvs ist, weiss ich ungefähr, aber wozu ist ein octree gut? Und ist dieser Algorithmus überhaupt gut, denn ich habe gelesen, dass ein ABT (Ich weiss übrigens auch nicht was das ist) besser sein soll?
-
@TheTester
Gut jetzt weiss ich was ein Portalsystem ist
Ich glaube jedoch das ein Portal nicht immer eine Tür sein muss. 
@Sgt. Nukem
Jetzt weiss ich auch was eine Engine ist
Ich programmier mir mal selber eine @godlikebot
Du programmirst keine Treiber. Das machen die Grafikkartenhersteller. Du programmierst "nur" mit der Grafik API.
-
H.L.T.O schrieb:
Du programmirst keine Treiber. Das machen die Grafikkartenhersteller. Du programmierst "nur" mit der Grafik API.
Ja, das die Grafikkartenhersteller Treiber herstellen ist mir klar, aber viele engines haben auch noch interne Treiber. Bei Genesis3D und Destiny3D war das jedenfalls so. Und bei Crystal Space gibt es sowas auch (glaub ich).
-
h.l.t.o
*******Gut jetzt weiss ich was ein Portalsystem ist Ich glaube jedoch das ein
Portal nicht immer eine Tür sein muss.ok ok ich korrigiere mich. Die Hauptbedingung für ein Portalsystem ist die Zerlegung der "Welt" in unabhängige Zonen die durch "Portale" verbunden sind. Bei einem 3d shooter sind das die Räume und die "Portale" im allgemeinen sind konvexe Polygone durch die man von einem Teil in einen anderen Teil sehen kann.
Der Hauptvorteil is schon mal das die Räume unabhängig sind. Du kannst halt ne Baumähnliche/Graphenähnliche Struktur aufbauen und dort sind die Ganzen Räume und welche Verbindungen sie zu welchen anderen haben eintragen. Is der Vorteil, bist du in Raum A und die "Tür" ist zu, brauchst du nichts anderes mehr rendern. So das eigentliche Problem bei den Portalen ist das Clipping wenn wir von einem Teil in einen anderen durch ein Portal sehen. Wobei das Portal dann so eine Funktion wie ein "Sichtfeldbeschneider" (mir is kein anderes Wort eingefallen) ist.tschöö
tt
-
TGGC schrieb:
Du hast die Portale gesetzt, und nun möchtest du die gesamte Polymenge in Untermengen aufteilen, so das es in keiner Untermenge zwei Polys gibt, die auf verschiedenen Seiten eines Portals liegen?
Bye, TGGC (Der Held ist zurück)
genau. Das Problem dabei ist, dass die Level absolut beliebig kompliziert sein können. Man kann nicht einfach eine Ebene durch ein Portal legen und dann alle Polys davor und dahinter trennen. Es kann sein, dass ein Portal in einer Tür hängt und neben der Tür eine Einbuchtung ist die theoretisch schon in den anderen Sektor reinreicht, da aber eben nicht hingehört.
Ich hab mir mal überlegt, dass ich mich Polygon für Polygon durchhangele, bis ich von einem Portal zum anderen gekommen bin. Das ist aber nicht nur schwierig sondern auch ziemlich unzureichend, da nicht alle Polygone zusammen hängen müssen.
Naja die einfachste Lösung wär halt dass der Mapper die Portals setzt und die Sektoren dann manuell zuteilt. Ich muss mich jetzt mal erkundigen wie das in D³ gemacht wird, der Editor wurde ja schon "veröffentlicht".
-
Die obengenannte Problembeschreibung ist der Lösungsansatz. Zwei Polys gehören zum selben Sektor, wenn es eine Weg zwischen beiden gibt, der komplett im "bespielbaren" Raum liegt. (Bespielbarer Raum, soll das sein, wo der Spieler bzw. die Kamera immer drin ist.) Man kann das zum Beispiel lösen, indem man den bespielbaren Raum in lauter kleine Stücke zerlegt (und auch an den Potalen zerschneidet!). Dann baust du einen Graph auf, welche "Raumstücke" welche anderen berühren, wobei die Berührung an einer Portal nicht zählt! Dann hast du einen Graph, der in einzelne Teile zerfällt. Mit etwas Graphentheorie ist es nun kein Problem, die einzelnen Teil zu identifizieren und die angrenzenden Polys einem Sektor zuzuordnen.
Bye, TGGC (Der Held ist zurück)
-
Mit Graphen hab ich noch nicht so viel gemacht, bin nur ein Erstsemester. Aber ich denke ich weiß, was Du meinst. Ich werds mir mal durch den Kopf gehen lassen.
-
Kannst Du in ein paar kurzen Sätzen erklären wie Du den "begehbaren Raum" finden würdest?
Ich würde einfach anfangen, Würfel aneinander zu Reihen bis ein Hinderniss kommt, und das dann in alle Richtungen, bis der ganze Level voll von virtuellen Würfeln ist. Die Polygone werden dann in die Würfel einsortiert (da wo sie halt grad sind).
Aber die Methode ist irgendwie unzureichend, umständlich und auch noch langsam...deswegen siehe Satz 1
