Also folgendes.

Ich möchte beginnen ein kleines Testgelände zu bauen. In diesem kleinen Testgelände möchte ich all die Techniken ausprobieren, die man für ein EchtzeitStrat. Spiel benötigt.
Also ich möchte:
eine schicke kleine Karte mit
2-3 verschiedenen Objekten drauf,
ner Figur die ich animiert durch die Gegend hetzen kann,
die u.U. mit Objekten interagieren kann und
das alles in ner schicken Optik.
Ein minimenü mit dem ich das Testgelände Manipulieren kann.

Das übliche also

Ich hab zwar jetzt schon das ein oder anderen Projekt mit OpenGL realisiert. Nur halt nix in diese Richtung. Das Menü zu basteln is die simpelste aller aufgaben. Aber schon bei der Karte gehts los. Ich möchte die Daten von Anfang an optimal verwalten. Deshalb wöllte ich meine Karte aus Dreiecken aufbauen die ich in nem Baum abspeichere. Der Baum wiederum soll zwecks Sichtbarkeitstests mir Vorteile bringen.

Die Theorie dazu is ganz net nur hab ich keine Ahnung, wie ich solche Sichtbarkeitstests durchführe. Auch weis ich nicht wie ich ein Modell animiere. Ich würde wohl auf Noeskas 3DS Loader setzen. Oder kennt einer einen Loader für Lightwave Dateien, der so simple und gut ist wie gl3DS.pas?

Wer kennt Tutorials die mir bei meinem kleinen Testgelände helfen könnten

Ich möchte mit diesem Projekt mal ein richtig gutes Projekt auf die Beine stellen (*g*). Soll heißen auch die Codebasis soll durchdacht und übersichtlich sein und vorallem auch bleiben. Wenn das Testgelände erfolgreich war und so aussieht, wie ich mir das vorgestellt habe (und wenn da Interesse besteht!) würde ich mich auch hinreisen lassen meinem Mitteilungsdrang nachzugeben ein Tutorial daraus zu machen.

Gibts zum Thema Codeaufbau von Eurer Seite Tips und Hinweise wie ich diese Projekt strukturieren sollte, damit das meinen Vorstellungen genügt

Das Testgelände soll später durchaus auch als Basis für echte RTS dienen. Dazu muss die Codebasis wartbar/ordentlich sein und die Optik möglichst nahe komerziellen Produkten kommen. (halt wieder das übliche... )

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

@Animierte Modelle :
Vergiss das 3DS-Format am besten ganz und nutz für die animierten Modelle entweder was eigenes (per Exporter aus deinem 3D-Modeller) oder das Milkshape-Format. Heute braucht man v.a. bei Figuren erst garnicht mehr mit herkömmlichen Keyframeanimationen anzufangen, sondern sollte gleich auf Bones (oft auch Joints genannt) umsteigen, also Vertexskinning. Da ist man nicht nur sehr viel flexibler, spart jede Menge Speicher, sondern kann die Modelle/Figuren dank der bereits vorhanden Knochenstruktur mit Physik versehen, und kann das Vertexskinning noch per Shader beschleunigen (muss man aber nicht).

@Terrain :
Sollte in Sachen Geometrie recht einfach sein, am besten packst du dein Terrain, wenn man es wie gewohnt von Schräg-Oben sieht in einen Quadtree (Octree wäre dann ja überdimensioniert, da man sich ja nicht frei umsehen kann). Dessen Teile prüfst du dann via Frustum-Culling (Occlusion-Queries bringen hier ja auch nix, wegen der Schräg-Oben-Ansicht) auf Sichtbarkeit, und die einzelnen Patches legst du am besten als VBOs im VRAM ab (VBO hat ggü. DL den Vorteil dass du die Patches später noch leicht anpassen kannst, um so z.B. deformierbares Terrain zu implementieren).
Schwerer wirds dann in Sachen Texturierung. Eine einzelne riesige Terraintextur ist im Normalfall nicht flexibel genug und bei großen Karten auch nicht schön. Hier solltest du mal nach "Texture Splatting" suchen, oder das Terrain intern (also nicht zum Rendern, sondern nur für die Texturierung) anders repräsentieren (z.B. als hexagonale Teile), wobei jede Ecke eines solchen Teils dann einen anderen Blendwert und andere Textur-ID beinhalten kann. Was auch beliebt ist (macht AFAIK FarCry so) ist "Texture-Baking". Du machst also im Editor deine Textur so wie ich grade gesagt habe, und wenn die Map "kompiliert" wird, wird deine Textur in großen Blöcken berechnet, so dass man später im Spiel nur noch eine Textur pro Patch/Fläche rendern muss. Aber das Gebiet Terraintexturierung ist fast schon eine Wissenschaft für sich, und im Netz solltest du diverse Techniken zu dem Thema finden.

P.S. : Du hast bei deiner Aufzählung sehr viele Sachen vergessen, die für ein RTS an sich interessanter (Grafik ist da ja eher "Beigabe") sind. Z.B. Wegfindung, AI, Einheitenverwaltung (also von den Datenstrukturen her), etc.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Stimmt die Wegfindung hatte ich noch vergessen.

Ansonsten soll erstmal nur eine Einheit das Testgelände unsicher machen. Die umstellung auf mehr ist dann weniger problematisch. Die Frage der KI ist natürlich eine recht komplexe und eigentlich ein Thema für sich. Die KI kann man allerdings auch getrennt zum Testgelände Entwickeln, da sie ja nur wissen muss wie das Gelände und die Einheiten/Objekte verteilt sind. Es ist also nicht nötig eine KI für das Testgelände zu entwickeln, wo eh keine Gegner unterwegs sind.

(Das Testgelände soll nur die Darstellung und Befehlsvergabe an Einheiten in der Spielewelt darstellen.)

Bei all den Sachen die du genannt hast bleibt mir mal spontan der Mund offen....Wo kann man denn sich in die Sachen einlesen. Zwecks besseren/ schnelleren Verständnis gerne auch auf deutsch.
(Auf der OpenGL Guruskala von 1 bis 100 beweg ich mich ja schließlich noch ca. 50-75 Punkte unter Dir.)
Ich hab zwar von den Sachen schon gehört, und durchs Informatikstudium hab ich in Sachen Datenstrukturen auch keine Angst vor dem Zeugs, aber gemacht hab ich sowas noch net (vorallem net in Verbindung mit OpenGL.).

Wäre es rein Programmiertechnisch ein größerer Aufwand die Kartendaten so zu speichern, dass man die Karte frei drehen kann?
Fändest du es günstig/notwendig, wenn man die Karte frei drehen kann?
Welches Modelformat würdest du favorisieren (Milkshape?) und gibt es dafür bereits Laoder die Animation unterstützen?

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

@Einlesen :
Am besten googeln. Da ich mich persönlich weniger für Terrainrendering interessiere kann ich dir da leider auch keine genaueren Quellen ausser googel nennen. Ich seh mal nach ob ich in meinem PDF-Archiv trotzdem ein paar Dokumente zu dem Thema hab und geb dann bescheid. Anfangs dürfte es aber eigentlich reichen wenn du ne riesen Terraintextur erstellst (z.B. 16k * 16k, was man beim Texturebaking dann evtl. auch machen würde), diese dann aber natürlich vorm Laden in kleinere Chunks unterteilst.

@Strukturen :
Frei drehbar ist kein Muss, aber bei Dawn of War kann man sich auf der Karte quasi komplett frei umsehen, was spielerisch nix bringt, aber in den Replays einiges her macht. Wenn du das willst, dann legst du die Karte halt in nem Octree statt nem Quadtree ab, der Programmieraufwand ist nicht viel größer (hast halt bei nem Octree drei Dimensionen in denen unterteilt wird). Wie gesagt empfehle ich eine von den beiden Strukturen, BSP ist nicht mehr zeitgemäß (zu CPU-lastig), PVS nur für Innenräume (kann man zwar auch auf Octree anwenden, dann aber lieber Occlusion Queries) und Bruteforce kommt natürlich erst recht nicht in Frage.

@Modellformat :
Hier gibts im Downloadarchiv nen Milkshape-Loader (schon sehr lange), wenn der nicht funzt oder nicht mehr da ist : Ich habe für NB3D einen verwendet, denn kann ich dir dann schicken, denn der geht. Alternativen hast du wie gesagt für animierte Figuren (bei nem Panzer oder so ist das was anderes) halt nicht. gl3DS.pas kann Keyframes nicht korrekt einlesen (da hab ich ja dran gewerkelt), weil diese vom 3D Studio MAX schon falsch exportiert werden. Also fällt dieses Format schonmal flach. ASE kann zwar auch Animationen speicher und ist zudem leicht ladbar (da ASCII), hat aber andere Nachteile (u.a. nur eine Texturemap pro Mesh). Also wie gesagt empfehle ich Milkshape. Das Format ist einfach lesbar und v.a. unterstützt es skeletale Animation (und AFAIK auch Keyframes).

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Gut...da wirds dann woll Milkshape werden. Gibts bei Milkshape irgendwelche Lizenzbedingungen die man beachten muss/sollte?

Wäre Cool wenn du in deiner PDF Sammlung was finden würdest. Kann sicherlich net schaden.
Und dank deiner Ausführungen hier hab ich auch gleich paar passende Schlagwörter für Google.

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

Ich finde dieses Thema auch zimlich interessant. Allerdings hatte ich schon ganz schöne Problemme bei der Darstellung eines veränderbaren Bodens.
Vom Gelände war es zimlich primitiv gehalten im dem Höhenpunkte zu einem Gitter aus Qudraten verbunden wurde.

Der erste Textur Versuch bestand darin einfach jedem Qudrat ein Textur-Teil zuzuordnen was aber(aufgrund der abgehackten Textur-Wechsel) nicht seht toll aussah.

Der zweite Versuch bestand darin jeweils 4 Texturen so auf ein Qudrat zu blenden das ein weicher Übergang entsteht.(per Alpha-Anteil von glColor). Da sich aufgrund der Höheninformationen sich Texturen überlappen konnten und das ganze total langsam war wurde auch diese Idee verworfen.

Dann versuchte ich es noch mit Multitexturing was dann aber auch nicht ging da meine Grafikkarte nur 2 Texturen gleichzeitig unterstütze und es soweit ich mich errinnnerte problemme mit der mit glColor gab.

Das nächste mal versuchte ich mit zwei Render-Durchläufen in dem erst der Boden extern geblendet und zusammengefügt wurde um es nacher als Textur zu verwenden. Dort gab es dann(wie sich hier vielleicht einer erinntert) ein Problemm damit das nicht alles zu sehen war und die Bodentextur teilweise schwarz wurde.

Um das Problemm zu lösen renderte ich das nächste mal in einen PBuffer. Wie sich herrausstellte war dieser Vorgang wie schon zuvor aber viel zu aufwendig um ihn bei jeden Renderdurchgang zu wiederhohlen.(Ob ich den PBuffer effinzent genutz habe war die andere Frage)

Darum beschloss ich diesen Rendervorgang nur dann durchzuführen wenn der Boden um ein gewisses Maß verschoben wurde.(Von diesemdurch ein entsprechendes System immer nur das gezeichnet was auch zu sehen war und unterstütze inzwischen das time based movement)
Diese Lösung lief dann auch schon ganz flüssig allerdings ruckte es immer kleinere Rucker wärend man dem Bildschirm verschob.

Wie schon SoS sagte wäre es evt. noch eine Idee eine riesen Textur zu verwenden, ob dies sinnvoll ist und wie man das genau macht weis ich allerdings nicht.

Das ganze Prozess hier war eingentlich Teil eines Teamworks welches nie eines wurde da ich neben dem "Gründer" der einzigste war der aktiv mitwirkte. Da wir uns auf meinen Wunsch hin für OpenGL entschieden lag es also fast nur bei mir da etwas zu programmieren und irgenwie haben wir es dann aufgrund von fehlender Motivation eingestellt.

Wie schon gesagt hätte ich schon Interesse an so einer art 3D Echtzeit Strategie Spiel Testumgebung in der man einfach mal die verschiedensten Techniken schon mal auf einer hörerern Ebene ausprobiern kann.

Ich wäre für Mikeshape auch wenn ich mir dieses Tool erst noch besorgen müsste, wenn es dort einen Loader für animierte Modelle gibt. Vom programmiertechnischen Aufbau würde ich mich gerne an OOP halten und möglichst alles in Klassen abkapseln um so den überblick besser behalten zu können. Auch eine strikte Unit Planung würde ich für gut halten.

MfG
IFlo

_________________
Danke an alle, die mir (und anderen) geholfen haben.
So weit... ...so gut

Ja...also OOP und eine Aufteilung in spezielle Units is bei mir Gang und Gäbe und wird natürlich auch beim Testgelände beibehalten.

Wenn aber jemand noch Ideen hat die darüber hinausgehen (Es gibt ja einige, die schon recht aufwendige Klassenhirarchien gebaut haben. z.B. LooseyXs Bedienelemente) hab ich dafür natürlich ein Ohr offen.

"Texture Baking" ist doch render to Texture oder? Ich hab gegooglt aber keine wirklich dolle Beschreibung gefunden.
Zu LOD, Texture Splatting, VBO und zu Octrees hab ich Material gefunden. Leider ist das Meiste in English und auch kein "ich les' das mir mal schnell durch"-Englisch.

Wenn also jemand von euch auf seiner Platte oder im Netz Einführungen/Tutorials zu nachfolgenden Themen hat, dann immer her damit:

Octree
Frustum-Culling
VBO
LOD
Texture Splatting
Texture Baking

Ach ja:
Erfahrungsberichte sind zu den Obigen Themen auch gern gehört. Man muss ja nicht jeden Fehler nachmachen.

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

hallo flash!!!

also zum thema terrain habsch glaub noch paar pdfs auf der plaate, die kannsch dir bei gelegenheit mal geben. sind aber teilweise wirklich keine schönen alghorithmen, aber was störts dich, musste ja auch so machen in der tu ... achja hier gibts auch ein tutorial @clod!!!!

_________________
Aktuelles Projekt :
www.PicPlace.de