spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Ich würd so ein Modul auch brauchen!

denke mal nicht dass es sowas schon gibt.. hat sich wohl noch keiner die arbeit gemacht schaut euch einfach ma das beispiel - spiel vom dx9sdk an, da ist ne "terrainengine" mit heightmaps dabei...

Engine würd ich das nicht nennen, eher Terrain Brute Pipeline oder so. Und ich denke keiner wird hier sein hart erarbeitete Terrain Klasse mit Quadtree, Culling, Effekten etc posten. Da sollt ihr mal selber arbeiten...

Ich hab das Buch Jetzt lerne ich Spielepreogrammierung mit DirectX und VC++, da ist ne Klassse drin, die aus ner Heighmap die Vertex und Indexdaten erstellt und anzeigt. Allerdings pohne Extras und nicht gerade Performance optimiert. Aber als Grundlage ganz net.

Zitat

Und ich denke keiner wird hier sein hart erarbeitete Terrain Klasse mit Quadtree, Culling, Effekten etc posten.

Witzig, bei mir ist es genau umgekehrt. Wenn ich nicht den Code posten kann, werde ich auch keine Terrain Engine schreiben (es sei denn für wirklich viel Geld).

Einer der grossen Vorteile von nicht bezahlter Entwicklung ist doch dass man mit anderen Leuten zusammenarbeiten kann statt dass jeder wieder jede Sache (3D Editor, 3D Engine, Sound Engine, Kollisions Code etc etc etc) wieder von Grund auf neu machen muss.

Zitat

Da sollt ihr mal selber arbeiten...

Ich weiss das hier viele denken, man sollte mal alles in einem Spiel selber gemacht haben um den Überblick zu haben. Das ist zwar sicher ganz lehrreich (wenn man es tatsächlich durchhält), aber man kann halt nie state-of-the-art sein, denn in kommerziellen Spielen stecken viele zig Mannjahre. Leutz, heutzutage gibt es das Internet. Da findet man hunderte oder tausende gleichgesinnter und hunderte von "work in progress" Projekten an denen man sich beteiligen kann. Mir ist es lieber, ich habe einen Teil von etwas gemacht, was die Leute länger als ne Stunde spielen als dass ich sagen kann "alles von mir", aber es sieht eben auch danach aus dass nur ein paar Jahre von mir drin sind. Denkt mal drüber nach.

Ich will keinem auf den Fuss treten, will aber zeigen dass es auch ganz andere Meinungen gibt als was manche scheinbar für selbstverständlich halten. Tatsächlich gibt es sogar eine grosse Open Source Gemeinde, die von Zusammenarbeit lebt, eine eigene "Philosophie" hat, etliche Bücher und Zeitungsartikel, die inzwischen von wahrscheinlich allen grossen SW Firmen ernst genommen wird, bis hin zu Unterstützung im Milliarden (!) Bereich, eigene Lizenzen hat, Ihren Anthropologen , eigene Anwälte, etc.

Alos ich mach es so, dass ich mein "spiel" und mein editor parallel weiterentwickle und die Sachen, die beide brauchen, in eine Globale Klasse(engine) einarbeite.

@Deckhead:

Dann nutzt Irrlicht oder OGRE, ich glaub bei OGRE is Terrain dabei und bei Irrlicht kommts noch.

Hi,

naja bevor man so ein Modul baut sollte man sich erstmal fragen: "Was soll es können und wozu brauch ich es?"

Die 1. Frage klingt kniffling, ist sie auch, denn bei LOD wie z.B. ROAM oder dem Crystal-Algo fällt jegliche Dynamik des Terrains flach (wie z.B. Krater durch Granatexplosionen). Also die Breite dieser Palette von Fragen zu diesem Punkt ist relativ groß.

Die 2. Frage ist eigentlich offensichtlich, jedoch sollte man doch mal drüber nachdenken. z.B. bei ROAM ist es sogut wie unmöglich auch ein Indoorrendering zu veranstalten inc. großem Terrain (z.B. wenn man von einer riesigen Wüste in ein Haus geht bzw. tiefen unterirdischen Bunker). Dazu sollte man sich fragen bei Indoorgames: Lohnt es sich überhaupt? Falls das Game zu 90% im Indoorbereich abspielt wäre es intellegenter auf so ein Modul zu verzichten und es auch per Indoortechnik zu rendern (auch wenn die Performance nicht so besonders sein würde).

Soviel dazu.

Bei meiner Engine (zu der demnächst wieder Screens erscheinen werden) wird es so gemacht:
Das Terrain genau wie Indoordaten werden in einem eigenen 3D Editor erstellt. In der Engine selber wird ein Octree aufgebaut (je nach leistung der CPU/GPU unterteilt). Die Boxen des Octrees die sichtbar sind werden mit der OpenGL Extension HP_Occlusion_Test (bzw. auf NVidia karten mit NV_Occlusion_query) auf ihre Überdeckung getestet (also z.B. eine Box bedenkt die hintere, also muss die hintere nicht gerendert werden).

Das Funktioniert ganz gut und alles bleibt Dynamisch Bei einem Octree ist sogar noch der vorteil wenn man vor einem berg steht das evtl. die Hochdetailierte Spitze nicht gerendert werden muss

Diese Methode ermöglicht es IHMO einen fast Perfekten Übergang von Indoor zu Outdoor

- Patrick