Hallo,

durch Empfehlung bin ich auf Eurer Seite gelandet und habe mir schon diverse Tutorials angeschaut. Auch weiterführende Links habe ich mir angeschaut (vor allem das Zeux von SULACO macht einen sehr guten Eindruck).
Bei meinem Projekt handelt es sich um eine Weltraumsimulation mit Wirtschaftsteil. Wenn ich nun versuche das Gelesene in meinem Projekt anzuwenden, sind mir aber noch diverse Sachen unklar:
Muß ich wirklich bei jedem Renderdurchgang die _komplette_ Szene übergeben? (glbegin(gl_quads); gltexcoord2f(0,0); ...)Wenn es sich um ein paar texturierte Flächen geht, mag das ja noch gehen, aber wenn es viele Polygone werden bricht doch die Leistung ein, oder? Wenn ich nun ein Universum darstellen will (was bekanntermaßen recht groß ist) wäre dann folgender Ablauf korrekt (stark vereinfacht)
- manuell (ohne OGL) feststellen welche Objekte sichtbar sein könnten,
- alle sichtbaren Objekte komplett übergeben
- die Kiste rendern lassen?
Wäre das korrekt? Das hieße ja weiterhin:

Da sind meinetwegen ein Planet, ein Mond, und 3 Raumschiffe und ne Raumstation. Schätzen wir mal (hab noch keine Vorstellung) das wir bei ca. 1000 Dreiecken rauskommen. Ich kann doch nich im Ernst dafür jedesmal je 3 Vertices, Texturangaben, Beleuchtungszeux übergeben, und das noch bei hoffentlich 60 FPS? Oder ist das wirklich so? Ich hatte jetzt gehofft, dass ich die Szene übergebe und dann durch Matrizen-Voodoo die Szene um mich herumrechne um die Bewegung meines Schiffes umzusetzen (war ja bei OGL so, gell? Die Welt dreht sich um mich. )

Auch viele Beispiele setzen den Betrachter in den Koordinatenursprung und bewegen alle Objekte um diesen Punkt herum. In meinem Beispiel müßte ich ja noch die absoluten Weltkoordinaten (Schiffsposition, Planetenposition, Raketenpostition...) in GL-Koordinaten umrechnen, oder? Das wäre dann wohl einer der Hauptaufgaben der Engine, oder?

Das von mir angestrebte Projekt ist ja nun nix ungewöhnliches (zumindest das Grundprinzip). Ich hatte ja eigentlich gehofft, dass ich ein Tutorial in der Richtung finde um dieses dann zu kapieren und zu erweitern, ich blieb aber erfolglos. Hat evtl. noch jemand einen Tip für mich für eine Anleitung oder ein GL-Grundgerüst bei dem beschrieben wird, wie absolut positionierte Gegenstände im Raum platziert werden und diese dann in Zeichenkoordinaten umgerechnet und dargestellt werden?


Ich vermute dass ich mir gleich eine ziemlich heftige Aufgabe ausgesucht habe und daher auch Hilfe überlese, weil mir noch Grundlagen in Sachen 3D mit OGL fehlen (ich vermisse ja auch bei der ganzen Sache die "Kameraposition". Aber scheinbar gibts sowas bei OGL nicht, weil sich ja die Welt um uns dreht.... )
Wenn also jemand einen Hinweis hat, was mir bei meinem Vorhaben helfen könnte, dann wäre ich Euch unheimlich dankbar.

Grüße, DNA

_________________
Heute code ich, morgen debug ich, und übermorgen caste ich die Königin auf int.
http://www.2ndmoon.de

Hi,

also erstmal ein herzliches Hellau hier bei DGL

Deine Bedenken wegen der Leistung sind größtenteils unbegründet. Solange du keine ATI Rage oder Riva TNT verwendest (Obwohl es mit denen theoretisch auch geht. Vor allem mit der Riva), brauchst du dir am Anfang keine Gedanken um die Geschwindigkeit machen. Es gibt spezielle, sehr einfache Techniken, die wie Display-Listen deine Objekte im Grafikkartenspeicher speichern. Dadurch werden diese Polygone sehr viel schneller gerendert. Das Zauberwort heißt VBO. Wie gesagt, einfach so eine Art Display-Liste. Bloß ein bisschen anders. Wird aber vom Treiber meist genauso gehandhabt.

Ja, es ist definitiv nicht verkehrt, vorher zu überprüfen, welche Objekte sichtbar sind. Wenn du einen Weltraum darstellen willst, solltest du dir mal Celestia anschauen. Das stellt das Universum dar und zwar mithilfe von OpenGL Und zwar recht schön und flott.

Du kannst auch mithilfe von OpenGL überprüfen, welche Objekte sichtbar sind. AFAIK führen die nVidia-Treiber automatisch eine Sichtbarkeitsprüfung bei Display-Listen durch. Somit könnte man sich die im Prinzip sparen. Ich sage deswegen im Prinzip, weil du natürlich schauen solltest, dass deine Anwendung auf allen Katen halbwegs Performant läuft.

Heutige Grafikkarten vertragen locker einige Tausend Dreiecke pro Sekunde. Solange diese auch noch im Speicher der Grafikkarte liegen (Wie Display-Listen, VBOs...) geht sogar noch viel mehr.

Was meinst du mit absolut positionierten Gegenständen? Positionieren geht mit glTranslatef Und zwar sehr gut *g*

Gruß,
Frase

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."

ja dem ist so, die welt dreht sich um uns. das genügt, man muss dann nur die richtigen gedanken haben, damit alles klappt

zu deinen bedenken mit den openGl aufrufen: Schau Dir mal Tutorials zu den Themen Display Listen und Vertex Buffer an. Darin kannst du Renderbefehle kapseln, die dann besonders schnell gerendert werden können ohne daß Abertausende an Prozeduraufrufen über den Prozessor gehen müssen - wäre ja schlimm, wenns derartiges nicht gäbe

Ätschibätsch War schneller ^^

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."

pfffrr... wenn ich mal ne antwort auf ne frage hab.... *grml*

DGL bietet dir in der Hinsicht noch mehr Material:

1: Es gibt 2 Tutorials die sich mit Kamerabewegung befassen. (Unter Mathematisches)
2: Wie man rausfindet was tatsächlich zu sehen ist ist mit den richtigen Datenstrukturen gar nicht soooo schwer. Hier mal eine kleine Auswahl:
http://wiki.delphigl.com/index.php/Tech ... stechniken

3: Mit dem Positionieren von Sachen in der Szene haben so ziemlich 95% anfänglich Probleme, vorallem, wenn Sie einfach mal drauflospositionieren. Die Szene die du beschrieben hast, kannst du ja erstmal zusammenkürzen auf folgendes: Planeten sind Kugeln (Siehe Wiki: gluSphere) und Raumschiffe etc. sind Würfel.
Dann schreibst du dir mal auf (so richtig mit Papier) wo die dinger hinsollen in deiner Welt.
Und dann machst du dir folgende 4 Dinge Klar:
- Was immer du Zeichnest wird am aktuellen Koordinatenursprung gezeichnet
- mit glRotate änderst du die Ausrichtung der Achsen des Koordinatensystems
- mit glTranslate verschiebst du den Koordinatenursprung bezüglich der aktuellen Achsausrichtung
- glTranslate und glRotate kannst du wieder rückgängigmachen indem du entgegen rotierst/verschiebst. Oder du nutzt glPushMatrix/PopMatrix um wie das Koordinatensystem "von vorher" wiederherzustellen.

Zu allen Befehlen findest du in unserem Wiki exclusiv deutsche Beschreibungen. Und hier im Forum wird dir geholfen.

Noch was: Die beschriebene Szene zu bauen ist kein Problem, das schaffst du in 2 Wochen...wenn du dich dafür interessierst. 1000000 Polygone zu rendern schaffst du auch locker...das schafft jeder, und nur deine Grafikkarte wirds dir übelnehmen...die macht dann überstunden.
Was bei deinem Ziel (die Idee hatte ich auch mal...habs dann aber "verschoben"... ) die meiste zeit in anspruch nehmen wird ist die Logik dahinter. Und vorallem wie du die Grafik in dein Spiel geschickt einbaust. Du wirst ja auch eine GUI brauchen, und da kann man verdammt viel falsch machen.
Ich würde dir aus diesem Grund folgendes empfehlen: Bevor du dich an dein Spiel machst (was durchaus schaffbar ist. Such dir aber lieber noch mind. 1 Mitstreiter. Das ist wirklich wichtig:!:) solltest du kleine Testszenen wie die gerade beschriebene bauen. Das geht schneller, du lernst mehr und wirst nicht von Spiellogik abgelenkt. Dann solltest du eine GUI entwerfen oder mal fragen wer gerade eine zur verfügung hat (Es bauen bereits mehrere an sowas... ).

Wenn dir das jetzt zu sehr nach "ausbremsen" klingt, dann ließ dir mal das Ende vom Quickstart durch...
Ansonsten viel Glück, und viel Lesen!

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Hallo,

ich danke für alle Antworten. Ich hatte folgendes vor: Erstmal grob die Darstellung zusammenzuzimmern und erst dann das Spiel "in dieser Welt hoch zuziehen". Wenn dann im Spiel irgendwas passiert, wird es "nur noch dargestellt". Die 2 genannten Tutorials habe ich mir schonmal angeschaut und bin nun auch schon ein Stück weiter. Weiterhin sind Displaylisten scheinbar dass, was ich ich zu finden erwartet habe. Bei größeren Projekten geht es nich ohne, oder?

:Frase:
Celestia: Hmm, sieht wirklich gut aus. Fehlt halt bloß ne gescheite Handlung, Raketen, Laser usw. weißt schon

:Flash:
Was meinst Du mit "Logik dahinter"? Die Spielelogik? Da habe ich schon stellenweise schon in anderen Spielentwürfen Erfahrung sammeln können. Das heißt wenn Du jetzt Sachen wie:
- Interaktion mit der Spielwelt allgemein
- wirtschaftliche Entwicklung der Planeten
- das Handeln selbst
- Missionen
meinst. (Das soll im übrigen immer ein Server erledigen (achja, das Spiel wird onlinefähig ) Für den Singleplayermodus wird das dann ein lokaler Server im Hintergrund erledigen). Ich habe da gute Erfahrung mit statemachines (Zustandsautomaten) gemacht. Wenn die Stati gut gewählt und sauber definiert sind, die Trigger sauber funktionieren, kann man damit regeln, was der Spieler jederzeit machen können soll.
Ansonsten sehe ich das genau so wie Du. Erst muß die Engine funktionieren, welche das ganze Geschehen korrekt darstellt. Ansonsten sucht man wohlmöglich einen Fehler im Spiel, obwohl es die Engine falsch darstellt (und umgekehrt). In meiner beruflichen Programmiererfahrung habe ich das auch schon mitbekommen und versuche nicht mehr darauf reinzufallen.
Die Sache mit den Mitstreitern habe ich bisher nicht bedacht. Ein "vorteilhafter" Mitstreiter aus der (geographischen) Nähe ist auf den ersten Blick nicht vorhanden. Mal sehen, vielleicht ergibt sich ja was hier im Forum.

Grüße, DNA

_________________
Heute code ich, morgen debug ich, und übermorgen caste ich die Königin auf int.
http://www.2ndmoon.de

Hey Flash, ich seh grade dass Du auch aus Sachsen kommst.
Na ich schicke mal eine PM.

DNA

_________________
Heute code ich, morgen debug ich, und übermorgen caste ich die Königin auf int.
http://www.2ndmoon.de

doch schon, stichwort sind die schon mehrfach erwähnten vertex buffer objects
sind bei einigen sachen deutlich flexibler als displaylisten, da dynamische veränderungen möglich sind (display listen müssten neu compiliert werden => langsam), die gleichen daten in unterschiedlicheren kontexts benutzt werden können (mein jetzt sowas wie verschiedene texturkoordinaten bei gleichen vertexdaten)...
Display Listen sind da vor allem zum zusammenfassen von statechanges sinnvoll, wobei das auch ohne displaylisten nicht übermäßig teuer ist.

Ja genau das meinte ich mit der "Spielelogik".
Da du anscheinend nicht 13 bist, sondern schon ne Ahnung hast, wie du was angehen musst, denke ich, dass es keine unlösbaren Probleme geben wird.

Du solltest aber unbedingt erstmal Erfahrung mit OpenGL Sammeln. Also erstmal paar kleine Testprogramme schreiben...
Beim entwickeln einer eigenen GUI würde ich erstmal warten... Wenn du mit Delphi arbeitest könnte bald das Passende Tool von Lossy erscheinen und dir nen haufen arbeit ersparen...

Stell dich doch mal im Membersforum vor...würde mich mal interessieren, was du bisher so gemacht/geschrieben hast.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Done.

_________________
Heute code ich, morgen debug ich, und übermorgen caste ich die Königin auf int.
http://www.2ndmoon.de

Auch ein Pyromane?

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."

Will ich doch hoffen! So mehr Effekte um so besser!

Bei der Gelegenheit: Wer von euch findet Feuerwerke schön, und würde auch selber gerne rumbasteln? Ich denke das trifft hier auf viele zu!

_________________
Shareholder und Leitender Entwickler bei Pipedream-Games.

Zitat: Siehst du diesen Park da unten? Jeden Tag lernen sich darin Menschen kennen und verlassen einander. Und du hast dein ganzes Leben Zeit darin zu gehen.

Naja, auf biegen und brechen lass ich da nix explodieren, aber folgende Grundsätze soll die Engine einhalten.
- einigermaßen realistisches Flugverhalten. D.h. Im gravitationsarmen Raum (weit weg von Planeten) wirkt nur der Rückstoß als Antrieb, also halt irgendeine Art Triebwerk. Bei einer Kursänderung, kann man nun die "Nase" des Schiffes schon in eine neue Richtung halten, aber der Schub wird erst nach und nach den resultierenden Bewegungsvektor in diese Richtung bringen. (Also mehr eine Art gleiten, aber halt auch nicht zu zäh). Für den gravitationsstärkeren Raum kann man das Schiff um einen Gravitationsantrieb erweitern. Da dieser immer direkt Kraft anwenden kann (bitte keine Details fragen, der Antrieb wird erst 2160 erfunden) kann man nun auch zeimlich enge Kurven fliegen. (Dieser "Modus" kommt dem Flugmodell in Elite am nächsten und ist auch einfacher umzusetzen und einfacher zu fliegen)
- Raumschiffe werden nicht lichterloh zerbröseln (keine Sorge, Explosionen müssen rein). Es werden Schiffswracks übrigbleiben, die im Raum treiben.
- Man wird die Schilde sehen können. Man wird auch sehen können, dass ein Schild grade zusammengebrochen ist, und das der Oppenent ab nun ein ernstzunehmendes Problem hat (Energie weg, Laser weg, Hosen voll, etc.)
- Es wird verschiedene Raketen geben. Kleine sehr schnelle zum einen. Diese können geschwächte Schilde durchschlagen, machen aber nur mäßigen Schaden, es sei denn man trifft die richtige Stelle am Schiff. Diese Raketen können durch Laserbeschuß leicht zerstört werden. Es wird aber auch fette Raketen geben. Mit 'nem richtig prallen Gefechtskopf und eigenen Schilden.


Wie basteln. In echt? Also im Keller und hinterher mit einer Hand an der Wand und die andere in der anderen Ecke? Neee. Aber sonst ist Silvester mit dem handelsüblichen Zeux schon 'ne feine Sache.

DNA

_________________
Heute code ich, morgen debug ich, und übermorgen caste ich die Königin auf int.
http://www.2ndmoon.de

Das ganze Projekt hört sich sehr interessant an, besonderst da ich ein Weltraumfan bin!
Ich erinnere mich an spiele wie:
- Wing Commander Protecy( Oder wie man das schrieb )
- Homeworld
- Homeworld:Cataclysm
- Homeworld 2
- IGE3( Den anderen Namen weiss ich nicht mehr )!


Die Schilde sollten mit Shadern gerendet werden, das gäbe sicher einen Hochinteressanten Verzerrungseffekt!
Oder Subraumbomben wären was tolles!

Zu dem Thema falllen mir so viele Sachen ein, da muss ich doch Glatt ein Sc-Fi buch rausholen und loslesen!

_________________
Shareholder und Leitender Entwickler bei Pipedream-Games.

Zitat: Siehst du diesen Park da unten? Jeden Tag lernen sich darin Menschen kennen und verlassen einander. Und du hast dein ganzes Leben Zeit darin zu gehen.