Also besonders beieindruckend fand ich das du es geschaft hast so viele Techniken in einem Projekt zu vereinen.

Gelungen ist dir wie auch schon im Wiki das "Distance based Blending". Was besonders in Kombination mit dem Hintergrund sehr gut aussieht. Diese Technik scheint bei dir auch wunderbar mit der Quadtree Verwaltung zusammen zu arbeiten. Sehr geschickt hast du auch Perlin Noise Effekte für Übergänge eingebaut, wobei ich noch nicht ganz nachvollziehen kann wie du das geschaft hast. (Wann/wie oft wird das zum Beispiel berechnet?)

Das Gras ist zwar eine nette Idee, aber das größte Problem nämlich, dass es verdammt viel Leistung first hast du anscheinden auch noch nicht gelöst. Das einzigste was hierbei interessant ist, wie du das im Untergrund verankert hast?

Hat es einen bestimmten Grund, warum du dir einen eigenen Tree-Editor programmiert, und keinen vorhandenen verwendet hast?(z.b. gibt es für Blender jede Menge Tree-Generations Script Erweiterungen)

So, das war estmal etwas Feedback von mir, schon ein bischen schade das du da nicht mehr weiter machst.

MfG
Flo

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

Ja es sieht ganz nett aus, aber implementiert ist es nicht so wie ichs gern hätte. Derzeit funktioniert das mit einer Alphatextur. Ich habe irgendwo mal gelesen, dass das auch besser (und wie ich annehme schneller) möglich wäre, zumindest wenn OGL 1.3 zur Verfügung steht was ja auch für gscheitest Mulittexturing benötigt wird. Wenn ich mal darüber stolpere wie das "richtig" geht dann werd ich das sicher auch ins Wiki schreiben.


Das bedarf jetzt einer etwas ausführlicheren Erklärung. Prinzipiell ist die Landschaft folgendermaßen aufgebaut:
Es gibt einen Array von Patches (Patch = quadratischer Bereich mit fixer Größe). Jeder Patch besitzt mehrere Layer oder Modifier. Diese Layer kannst du dir vorstellen wie so typische Zeichenprogramm-Funktionen für ein regelmäßiges Gitter, also beispielsweise:
- Verwende grobe Highmap und interpoliere die Höhen mittels Splines
- Modifiziere danach die Höhen noch um einen Wert den du dir mit nem Perlin Noise berechnest
Oder wenn man möchte auch:
- Hier hast du alle Höhen für diesen Patch exakt gegeben (braucht halt umso mehr Speicher)
Da es bei den Höhenpunkten ja Level of Detail gibt, werden diese bei jedem Wechsel der Detailtstufe neu berechnet.

Für die Farbtexturen könnte man wenn man möchte auch unterschiedlichste Algorithmen verwenden, derzeit läuft das jedoch alles über einen Algorithmus ab. Und Farbtexturen werden zur Zeit nur einmal beim Erstellen des Patches berechnet (Erstellen erfolgt jedoch auch während der Laufzeit da die Landschaft ja etwas größer sein kann), LOD gibt es bei der Farbtextur derzeit keinen.
Da ich später noch unterschiedliche Detailtexturen einbauen möchte, habe ich das ganze gleich über Landschaftstypen aufgebaut. Jeder Patch kann nun beliebig viele Landschaftstypen besitzen (0 ist auch möglich wie an einigen Fehlern der Landschaft erkennbar ist :-) ). Für jeden Landschaftstyp steht nun ein Perlin Noise zur Verfügung, welches mit Parametern wie Persitenz und dergleichen gefüttert wird. Zusätzlich besitzt jeder Patch für jeden Landschaftstyp noch Prioritäten an den 4 Ecken, welche linear interpoliert werden. Die tatsächliche Priorität eines Landschaftstyps für ein Texel ergibt sich nun aus Perlin Noise-Wert zwischen 0 und 1 * Interpolierter gegebener Priorität. Wenn nun beispielsweise ein Landschaftstyp für ein Texel Priorität 100 besitzt und ein anderer Priorität 50, so werden diese beiden Landschaftstypen (also derzeit Farbwert und später hoffentlich auch Detailtextur) 2/3 zu 1/3 interpoliert.
Da Perlin Noise ja doch etwas aufwändigere Berechnungen sind verwende ich für die Berechnung des Farbwertes das selbe Perlin Noise. Hier dient der Wert dazu aus einer ziemlich großen 1D-Tabelle einen Farbwert raus zu holen.

Gegeben wird also für einen Textur-Layer:
- Landschaftstyp (Farbtabelle, ...)
- Perlin Noise Parameter
- Die Priorität für jeden Patch (kann auch 0 an allen 4 Ecken sein => wird nicht beachtet)

Das erstellen der Landschaft erfolgt derzeit noch über viele viele Bitmaps, später kommt dann noch ein Landschaftseditor her weil es ansonnsten eine ziemlich blöde Pixelarbeit wird wenn man eine schöne Landschaft haben möchte.


Naja gegen das Füllratenproblem kann man eher wenig machen. Der eine Screenshot mit den 11,irgendwas FPS wurde jedoch auf einer GF2 gemacht, also mittlerweile schon etwas veraltet. Hinzu kommen bei dem Screenshot noch die nicht ganz so tollen Bäume, also die Bäume fressen in dem Screenshot auch mehr Füllrate als sie müssten, weil die Blätterverteilung etwas dumm gemacht ist.
Das Gras ist bei Knirpskrieg jedoch nicht nur wegen der Performance nicht vorhanden, es spielte auch die Zeit eine etwas größere Rolle. Zum einen hatte ich zu dem Zeitpunkt gerade keine allzu guten Grastexturen und zum anderen wäre es ähnlich wie bei der restlichen Landschaft eine ziemliche Pixelarbeit gewesen das Gras richtig zu verteilen. Gras schaut in der Wüste halt nicht allzu toll aus, vor allem wenn man die Grasfarbe noch ein bisschen an die Untergrundfarbe anpasst ...
Stolz bin ich aber darauf, dass mein Gras soweit ich weiß das einzige ist welches sich ohne Vertex Programme im Wind bewegt und dieses noch dazu kaum an der Performance nagt.


Höhe der Landschaft an dem gewählten Punkt und ein zylindrisches Billboard drauf :-). Bei sehr steilen Hängen schaut das etwas blöd aus, aber auf Steilhängen wächst üblicherweise auch ned so viel Gras. Bei flacheren Hängen schaut das Gras entweder weit genug in die Landschaft rein (Z-Buffer übernimmt das verankern) oder es fällt nicht auf weil es vom anderen Gras ziemlich verdeckt wird.


Zum einen weil ich keinen kannte den ich für gut genug erachtete und zum anderen wollte ich die Bäume auch prozedual erstellen. In nem MMORPG gibts ja auf der gesamte Welt doch einige 1000 wenn nicht Mio. Bäume und die sollten nicht alle gleich ausschauen. Wenn man nun ein paar 100 Baumobjekte hat, da kommen schon einige MB nur für Bäume auf. Wenn ich prozeduale Bäume habe, dann brauch ich nicht mal 1/10 des Speichers und habe zudem noch annähernd beliebig viele unterschiedliche Bäume.
Für den prozedualen Algorithmus benötigte ich natürlich auch Daten, welche sich bei anderen Editoren eher schwer erhalten lassen. Und wenn man nun den Algorithmus hat, dann ist das machen eines Editors auch nicht mehr so das Problem.

Hoffe ich konnte deinen Wissensdurst fürs erste stillen :-).

Danke für dein Interesse und natürlich auch für das Lob,
Markus (Lyr)

Wenn ich so überlege wie ich das machen würde fällt mir so spontan glFog ein.


Ich nehme mal an das diese Pachtes aneinader gesetzt werden. Was passiert denn wenn die Höhen nicht zueinander passen? Das kann doch leicht passieren wenn man sie zufällig, und auch noch auf unterschiedliche Art berechnet.


Hier auf DelphiGL.com gibt es auch ein nettes Tutorial zu einer Erstellung bzw. Umgehung einer solcher 1D-Tabelle. Also wenn du das noch nicht gelesen hast. Vielleicht findest du darin noch ein paar Kniffe.

Nach diesen doch recht komplizierten Rechnungen vermute ich mal, dass du die Texturen nur mit der CPU berechnest und sie dann so wie sie sind auch verwendest. Stimmt das so oder läßt du Teile oder alles die Grafikkarte machen?
Ich habe bei der Boden Texturierung immer das Problemm, dass entweder der Boden zu Detail arm, die Boden-Textur zu groß, oder die Berechnungsdauer zu lang ist.


Zum einen weil ich keinen kannte den ich für gut genug erachtete und zum anderen wollte ich die Bäume auch prozedual erstellen. In nem MMORPG gibts ja auf der gesamte Welt doch einige 1000 wenn nicht Mio. Bäume und die sollten nicht alle gleich ausschauen. Wenn man nun ein paar 100 Baumobjekte hat, da kommen schon einige MB nur für Bäume auf. Wenn ich prozeduale Bäume habe, dann brauch ich nicht mal 1/10 des Speichers und habe zudem noch annähernd beliebig viele unterschiedliche Bäume.
Für den prozedualen Algorithmus benötigte ich natürlich auch Daten, welche sich bei anderen Editoren eher schwer erhalten lassen. Und wenn man nun den Algorithmus hat, dann ist das machen eines Editors auch nicht mehr so das Problem.

Das die zu viel Speicher wegnehmen ist ein Argument. Daran hatte ich noch gar nicht gedacht. Und dein Editor unterstützt die? Veröffentlichst du auch deinen Editor?

Also Danke für diese ausführliche Antwort .
MfG
Flo

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

Was da alles für Sachen drinnen stecken....Wow!...wirklich mal etwas anspruchsvoller (Im vergleich zu meinen arbeiten auf jeden fall! )

Ist der Baumalgorithmus deterministisch? Also wenn du denn selben Generierungsseed reinschiebst kommen die selben Bäume raus, oder net?

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

Ja glFog spielt beim Distance based Blending höchstwahrscheinlich eine Rolle. Ich habs bisher nur noch nicht geschafft den Alphawert durch glFog zu beeinflussen, ist allerdings auch schon ziemlich lange aus dass ich das es letzte mal probiert habe. Unter anderem kannte ich mich zu dem Zeitpunkt mit der Texture-Env combine Extension noch kaum aus.


Dies sollte nicht der Fall sein, da aneinander grenzende Ränder gleich berechnet werden, sofern der selbe Layer für beide Patches vorhanden ist. Wenn man die Layer so gestaltet, dass sie nicht abrupt Enden, sondern an den Rändern die Höhe 0 besitzen, dann kommt dies nicht vor. Aber da es ja möglich wäre dass es doch vor kommt, werden Höhenwerte und Normalvektoren der Randwerte von den Nachbarn kopiert, wodurch nur etwas unnatürliche Steilhänge entstehen. Farbtexturen werden nicht kopiert da das wohl etwas zu aufwändig wäre. Aber generell ist für solche Fehler der Grafiker verantwortlich der die Möglichkeiten überreizt, nicht ich :-).


Ich finde irgendwie keines das in diese Richtung geht. Aber ich bin mit der Tabelle ganz zufrieden. Wenn man die Werte interpoliert kommt man mit 256 Einträgen aus, was dann ein ganzes KB je Landschaftstyp belegt, sollte also auch halbwegs Cache-freundlich sein. Und wenn nun einer braune Flecken in seinem Graslandschaftstyp haben will, dann soll er das machen ... also rein prozeduale Ansätze wären denke ich ohnehin nicht allzu gut geeignet dafür. Irgendeine Art von Farbtabelle wird man immer benötigen.


Naja die Farbtextur wird halt bei jedem neuen Patch einmal berechnet und dann der Grafikkarte übergeben. Ich wüsste nicht was ich da großartig der Grafikkarte an Arbeit überlassen sollte.
Aber natürlich ist der gesamte Code dafür (also auch das Perlin Noise) sehr stark optimiert, also halt so Sachen wie mit Integer statt mit Float rechnen, recht viel mit boolschen Operationen, halbwegs Cachefreundlich und dergleichen. Ich verwende derzeit 16x16 Farbtexturen je Patch bei der Landschaft. Mit 32x32 gings aber auch noch ganz flott, selbst auf meiner alten 700erter Klapperkiste.
Im Endeffekt sind das jedoch Sachen die man soweit als möglich den Grafikern überlassen sollte, nur halt ungefähre, obere Schranken festlegen :-).


Was soll er unterstützen? Der Baumeditor ist halt das User Interface um die Parameter für einen zu generierenden Baum fest zu legen. Da es jedoch ziemlich viele Parameter sind, schaut er halt etwas komplexer aus als er eigentlich ist. Da mein Algorithmus jedoch höchstwahrscheinlich ein paar andere Parameter hat als andere, unterstütz er natürlich keine Bäume aus anderen Editoren falls du das meinst.
Zum Downloaden gibts den hier: http://knirpskrieg.sigon.net/Engine.zip, ist halt ein bisschen versteckt zwischen dem Sourcecode, Und die Benutzerfreundlichkeit lässt auch etwas viel zu wünschen übrig :-).


Gern geschehen.


@Flash:
Ja natürlich ist er deterministisch. Einen nicht parallel ablaufenden Algorithmus nicht deterministisch zu machen dürfte sich um einiges schwieriger erweisen :-). Und der Seed wird natürlich auch für jeden Baum gespeichert, nicht nur damit sie immer gleich ausschauen, sondern auch damit keine blöd ausschauenden Bäume auftauchen. Wenn man wenig Dreieckerl haben will und dann 2 oder gar 3 Äste ungefähr in der selben Höhe ungefähr in die selbe Richtung schauen hat man zu viele leere Bereiche. Da sollt ich eh noch ein paar Sachen einbauen das die Verteilung besser wird. Zur Zeit ist nur etwa jeder 5te Baum halbwegs schön, aber da man ja einfach durchklicken kann is das auch ausreichend.


ciao,
Markus (Lyr)