Terrainberechnungen - was braucht es alles?

[starcow]

Tach Zusammen

Der Titel ist vielleicht etwas unpassend, doch mir ist kein besserer dazu eingefallen :-)
Ich habe mich gefragt, was ein Programm haben muss, um ein weitläufiges Terrain darstellen zu können. Meine Frage bezieht sich dabei eher auf das wesentliche Prinzip und weniger auf die technischen Details.
Ich gehe in meiner Überlegung davon aus, dass dieses Terrain als 3D-Modell importiert wird. Keine Simulation und keine Dynamik also. Das Modell darzustellen dürfte ja noch nicht so das Problem sein - einfach alle Polygone zu zeichnen. Was wäre dann der nächste Schritt. Ich nehme an ein Frustum Culling ist zwingen notwendig, dürfte aber auch noch relativ einfach zu realisieren sein.
Ist es damit den schon getan?
Wie sieht es mit LOD aus? Muss man einen Algotrithmus implementieren, der dieses Terrain in der ferne "vereinfacht". Ist sowas überhaupt dynamisch zu realiseren?
Und wäre das eher ein nettes Feature oder absolut essentiel?

Gruss starcow

[Schrompf]

Kommt drauf an, was Du nutzt. Falls Du selbst programmierst: bau Dir Dein Terrain, lies es in Dein Programm ein und rendere es erstmal einfach im Ganzen. Dann siehst Du, wie die Performance ist. Ich behaupte mal: bis einige 10k Dreiecke ist der Ansatz völlig ok. Und Gothic z.B. hat damit eine ganze Spielwelt bestritten :-)

Danach würde ich in grobe Würfel segmentieren und die Segmente einzeln rendern - dann fallen schonmal alle Segmente weg, die hinter dem Spieler oder jenseits der Sichtweite sind. Wenn Du dann bei <200k Dreiecke im Sichtfeld bist, brauchst Du gar nicht weitermachen.

Wenn Du aber wirklich ein Terrain mit Millionen Flächen hast und das auch nach Segmentierung und Culling der unsichtbaren Segmente noch nahezu komplett in Sicht hast, dann musst Du lodden. Und das geht nicht zur Laufzeit, das ist ein ganz eigener Spaß. Davon fange ich nicht an, bevor ich nicht weiß, dass Du das wirklich brauchst.

Falls Du eine fertige Engine benutzt: die meisten Engines bieten irgendein Feature zum segmentierten Rendern großer Meshes. Oder, falls es dumm kommt, nur von Height Maps, aber die zählen da ja auch rein.

[starcow]

Hallo Schrompf
Ich habe schon damit gerechnet, dass du mir da wiedermal gute Inputs geben kannst :-). Dank dir für die schnelle Antwort!
Wenn ich jetzt so drüber nachdenke, dann kann es eigentlich ja nur einen Grund geben, was die Anzahl der sichtbaren Tirs auf dem Terrain in die höhe treiben kann: die "Auflösung" des Gitters des PolyMeshes. Weil die Topologie des Terrains wird die Anzahl der sichtbaren Tris (durchschnittlich) wohl kaum beeinflussen. Vielleicht sind es in spezifischen Siutation mal mehr mal weniger. Aber bei freier Sicht auf das Gelände dürfte die Anzahl von sichtbaren Polygonen immer etwa die selbe sein (oder doch nicht?).
Ich frage mich grad wie man konkret an sowas rangehen könnte... Ich meine man könnte z.b In Mudbox ein Grid erstellen und die Absolute Grösse so definieren, das dieses Grid für ein Areal von 10km x 10km Grösse steht. Nun segmentiere ich dieses Grid, bis ich 1'000'000 Polygone (2'000'000 Triangles) erhalte. Nun kann ich frei modellieren... Allerdings habe ich so Quads von der Grösse von 10m X 10m, was mir jetzt doch als ein bisschen wenig erscheint. Wenn ich jetzt aber pro Meter gerne ein Polygon hätte, käme ich bei einem Areal von 10km x 10km auf ääää 100'000'000 Quads X-D
Also so kanns irgendwie nicht gehen. Aber ist es nicht so, das bei freiem Blick über das Land 10km nicht viel ist? Eine Trübung der Atmosphäre macht sich bei klarer Sicht doch bestimmt erst ab 100km bemerkbar? Und auf einem Planeten wie der Erde wäre der Horizont aufgrund der Krümmung bestimmt 300km weit entfernt (wenn man davon ausgeht, das alles mehr oder weniger Eben ist).
Auf der anderen Seite ist es doch so, das ich schnell mal ein Quad pro Meter brauche, will ich etwas Detail in den Boden reinbringen, wie z.b kleine Unebenheiten etc.

Gruss starcow

[Niki]

Willst du über das Terrain fliegen, latschen, oder beides? Aus der Luft können 10km x 10km sehr wenig sein, wobei da 1m x 1m Quads dann auch extrem klein sind. Vom Boden aus können 10km x 10km extrem viel sein. Hängt alles davon ab, wie hoch die Kamera über dem Terrain ist, und mit welcher Geschwindigkeit sich die Kamera über das Terrain bewegt. Langsame Geschwindigkeit und näher zusammengerückte Terrain-Features könnten vielleicht zur Illusion beitragen.

Nur mal so als Beispiel, auch wenn mittlerweile schon veraltet... Skyrim hat ein Höhenfeld der Größe 3808x3008. Das sind 3807x3007=1.144.7649 Quads. Und nur ein Teil davon ist spielbar. Da kann man recht lange latschen. Ob die Quads 1m x 1m sind, das weiß ich allerdings nicht. Sykrim fügt einige Extra-Details mit Modellen hinzu. In den Schneelandschaften gibt es da beispielsweise Modelle für kleine Schneehügelchen bzw. Schneeverwehungen.

Hast du die Möglichkeit einfach mal zum Testen ein einfaches Höhenfeld darzustellen und darüber zu latschen? Da könntest du dann mit der Laufgeschwindigkeit, Kamerahöhe, und Größe der Textur-Details rumspielen um rauszufinden wie groß es denn nun wirklich sein muss. Mit "Größe der Textur-Details" meine ich nicht die Größe einer Textur in Pixeln, sondern z.B. die Größe eines Grashalms in der Gras-Textur.

Ich mache immer folgende Feststellungen:
(1) Langsame Geschwindigkeit --> dauert länger das Terrain zu passieren
(2) Niedrige Kamerahöhe --> Latschen ist gefühlt schneller.
(3) Kleinere Textur-Details --> Kamerahöhe ist gefühlt höher

Die passenden Einstellungen zu finden und gleichzeitig Probleme mit der Near-Plane weitestgehend zu vermeiden (z.B. Near-Plane schneidet in den Berg direkt vor der Kamera), das kann ein echtes Gefummel sein.

[starcow]

Ok, sehr spannend das ganze! :-)

Als Bezugsgrösse in diesem Beispiel war ich von einem Menschen und dessen Bewegunggeschwindigkeit ausgegangen. Die Kamera wäre dann in der 3D-Person Vogelperspektive gesetzt. Vielleicht in 5 Meter Höhe und ne Brennweite von ungefähr 20mm resp. ~80°.
Bei der Gestaltung von Texturen leite ich die Details und deren Grösse für gewöhlich von einem fixen Masstab ab (Beispielsweise 2048Pixel entspricht 4096mm). Also die Grösse der Grashalme sollte dann so gewählt sein, damit sie "logisch" zur Figurengrösse passen.
Ich versuche mir immerwieder vorzustellen wie gross den 10km X 10km sind. Ist das ne Grösse die die meisten MMO's heute haben - oder ist es vielleicht doch massiv grösser?
Wie steht es den mit der Sichtweite? Bei Dark Age of Camelot (ein älteres MMORPG) hatte ich den Eindruck, das die Sichtweite vielleicht bei 1km liegt, obwohl es sehr weitläufig und offen wirkt.
Ne Frage noch zum Culling und zu LOD:
Hab ich das den falsch verstanden oder greift Frustum Culling immer ausschliesslich auf ganze Objekte und nicht etwa auf einzelne Polygone?
Und wenn LOD nicht dynamisch gemacht werden kann, heisst das in der Konsequenz, dass der Artist das Terrain in verschiedenen "Auflösungen" erstellen muss?

Gruss starcow

[Schrompf]

Ok, Du bist dann doch weit jenseits dessen, was ich für Hobby-Entwicklung für angemessen halte. 100qkm? Wie willst Du die denn mit Inhalt füllen? Ich meine... mach, wie Du denkst, aber ich rate davon ab. Kleinere Brötchen sind empfehlenswerter.



Gestern auf so einer Witzesammel-Seite entdeckt... passt grad schön.

Zum Culling: das funktioniert sogar nur DrawCall-weise. Das umfasst unter Umständen sogar viele Objekte, wenn es Instancing ist. Das klassische Beispiel ist hier Bodenbewuchs: da malt man nicht jedes Grasbüschel oder jeden Farn einzeln, sondern fasst ein paar hundert davon zusammen zu einem DrawCall. Culling ist primitiv ausgedrückt der Code auf der Prozessorseite, der vorab ermittelt, ob es sich lohnt, diesen DrawCall anzustoßen oder nicht. Wie er das macht, dafür gibt es dann viele Möglichkeiten. Die einfachste Version ist es, ein Gesamtvolumen aller Daten im DrawCall zu erstellen - meist eine alles umfassende Kugel (Bounding Sphere) oder einen Würfel (Axis Aligned Bounding Box, kurz AABB). Dieses Volumen testet man dann gegen die Grenzebenen der Kamera (das Frustum).

Mir fehlt übrigens die MMO-Erfahrung, um die genannte Spielweltgröße einordnen zu können. Guild Wars - das einzige MMO, was ich mal gespielt habe - hat Karten bis zu dieser Größe. Aber die haben auch einige Hundert Leute, um diese Karten dann auszugestalten und mit Spielinhalten zu füllen :-) Bei den Splitterwelten dagegen sind die einzelnen Splitter gerade mal 1qkm groß, der größte wird vielleicht 10qkm. Und das bereits auszugestalten wird für Privatentwickler hammerhart. Geschweige denn mit Content zu befüllen. Überlege es Dir nochmal sehr genau, ob Du das wirklich willst.

Wenn Du es wirklich willst, dann kommst Du jedenfalls nicht mit schlichtem Losrendern ans Ziel. Bei 80° Öffnungswinkel und FullHD-Auflösung ist ein 1m-Dreieck bereits in 1000m Entfernung gerade noch einen Pixel groß. Und Du willst ja anscheinend deutlich mehr als 1km Sichtweite, also sind auch substanzielle Teile der 100 Millionen Dreiecke auch gleichzeitig in Sicht. Also: Landschaft bauen, segmentieren, lodden. Von Hand macht das sicher keiner, nicht bei 100 Millionen Dreiecken. Man kann das aber auch automatisieren. Im einfachsten Fall:

- Ermittle die Kante, deren Zusammenfassen am wenigsten Schmerzen bereiten würde.
- Schiebe den einen Punkt der Kante auf den anderen - Du hast 2 Dreiecke gespart.
- Solange, bis Du bei ~einem Viertel der Ursprungs-Polygone angekommen bist.

Nur leider stecken im ersten Schritt genug Intelligenz der Wissenschaftswelt für einige Dutzend Paper in den letzten 30 Jahren. Das machst Du nicht mal eben nebenbei. Plane dafür besser ein paar Wochen Beschäftigung ein. Ganz zu schweigen von der astronomischen Rechenzeit - eine Splitterwelten-Welt loddet nach heftigen Optimierungen eine Viertelstunde lang, Und wir sind wie gesagt bei einem Hundertstel der Datenmenge.

Evtl. solltest Du doch eine der regelmäßigen Mesh-Erzeugungsformen wählen. Eine Voxel-Map mit Marching Cubes oder Dual Contouring spuckt so regelmäßige Meshes aus, dass man die bereits während der Erzeugung halbwegs einfach lodden kann. Dann kannst Du allerdings die Landschaft nicht mehr im 3D-Modeller erzeugen. Das hätte ich aber eh vorher mal im kleinen Maßstab erprobt, da ich nicht weiß, ob die Tools es überhaupt mitmachen, Materialien und sowas auf kleinstem Raum zu verteilen.

[Niki]

10km Sichtweite mit 1m x 1m Quads sind ganz schön heftig. Das ist nicht nur wegen der Anzahl der Polygone so, sondern auch weil der Z-Buffer nicht unendlich genau ist. Unter Voraussetzung eines normalen Fließkomma-Z-Buffers kannst du sagen: je größer die Fließkommazahlen werden, desto ungenauer werden diese. Das bedeutet das zwei große, aber unterschiedliche Distanzen denselben Fließkommawert haben können. Dadurch entstehen dann so nette Effekte, wie ein Berg A der vor Berg B dargestellt wird, obwohl Berg A eigentlich weiter entfernt ist als Berg B. Noch schlimmer, das ganze kann alternieren, so dass die Berge in der Distanz anfangen zu flackern.
Um diesen Effekt zu reduzieren kann man dann die Near-Plane des Frustums verschieben (das Verschieben der Near-Plane hat einen größeren Effekt auf die Genauigkeit des Z-Buffers als das Verschieben der Far-Plane). Zu dem noch ein distanzbasiertes LOD, damit die Vertices in der Distanz weiter auseinander liegen.

Wenn ich mir das dann noch mit einem riesigen 3D-Modell, anstelle eines Höhenfeldes vorstelle, dann fängt mein Hirn langsam an zu käsen. Gehen wir mal banal vor und erzeugen ein LOD-Mesh, wobei die Segmentierung hier mal ignoriert werden soll. Ich benutze dafür jetzt mal einen etwas popligeren Ansatz:

(1) Erzeuge eine Kopie des Original-Meshs
(2a) Wähle einen Vertex der Kopie. Wenn du diesen Vertex nun entfernen würdest dann würde ein Fehler entstehen. Die Größe dieses Fehlers lässt sich mittels des Original-Meshs berechnen. Ist der Fehler kleiner als ein von dir vorgegebener Schwellenwert, dann entfernst du den Vertex.
(2b) Wiederhole 2a bis du dir alle Vertices angesehen hast.

Den ganzen Prozess kann man dann noch X mal mit größer werdenden Schwellenwerten wiederholen um X LOD Meshes zu erzeugen (LOD mit größerem Fehler wird in der Distanz benutzt).

Liest sich gar nicht so schlimm ist aber tatsächlich der Horror. Obiges Verfahren ignoriert nämlich eine ganze Menge Dinge:

(1) Du würdest die LOD Meshes segmentieren um Distanz-LOD zu unterstützen. Die einzelnen Segmente würden dann unterschiedliche LOD-Level benutzen. Du hast dann ein Problem die Cracks zwischen benachbarten LOD-Leveln zu verhindern.

(2) Dein Terrain-Modell ist texturiert. Da kannst du dann nicht einfach Vertices wegschmeißen, die für die Bildung von Materialgrenzen nötig sind. Na, ja, du kannst schon, aber das Ergebnis ist dann auch entsprechend.

(3) Du solltest in der Lage sein die LOD Meshes in möglichst große material-abhängige Triangle-Batches zu unterteilen um die Anzahl der Draw-Calls zu reduzieren.

(4) Wenn du über das Terrain läufst, dann ändern sich wegen des Distanz-LODs die LOD-Level die du in den Segmenten benutzt. Das Ergebnis sind springende Vertices (Geometry Popping).

Bedeutet obiges nun das das ganze nicht ordentlich machbar ist? Nein, keineswegs! Machbar ist das. Aber der Aufwand und das nötige Wissen sind gewaltig.

[Schrompf]

Niki sagt es auch sehr gut, was ich sagen wollte. Ich wollte hier eigentlich noch auf die Präsentation von Just Cause 2 verlinken, weil die auch noch schön auf die Präzisionsprobleme eingegangen ist, die man bei solchen Größendimensionen bekommt. Leider versagt mein Google Fu gerade.

Bei den Splitterwelten haben wir übrigens dagegen "Zonen" eingeführt, die jeweils ein eigenes lokales Koordinatensystem haben und untereinander durch eine 3D-Integer-Position positioniert werden. Ich habe damals gedacht, dass ich für die Physik im Idealfall 4 Nachkommastellen haben will, also ~14 Bits. Bleiben noch 9 Bits Mantisse übrig, was einen Wertebereich von 512 bedeutet. Davon dann die Hälfte, weil ich von Koordinatenrechnungen aus zwei benachbarten Zonen ausgegangen bin. Also 256m Zonengröße. Nette Rechnung, ist aber gescheitert. Zum Einen wünsche ich mir jetzt bereits bisweilen größere Zonen, um in der Entfernung besser große Bereiche auf einmal rendern zu können. Und zum Anderen hat sich die Berechnung als Falsch herausgestellt - ohne VSync bei hohen Frameraten und mit dem PhysX-Character Controller hat die Genauigkeit eben nicht mehr gereicht. Der Spieler konnte sich dann einfach nicht mehr bewegen, bis er wieder irgendwohin geschaut hat, wo die Framerate geringer war. Sehr hässlich.

[Niki]

Bei den Splitterwelten haben wir übrigens dagegen "Zonen" eingeführt, die jeweils ein eigenes lokales Koordinatensystem haben und untereinander durch eine 3D-Integer-Position positioniert werden.

Ja, so was in der Art mache ich hier auch. Ich benutze einen Loose Quadtree um eine räumliche Unterteilung der Gesamtwelt zu erhalten. Knotenpositonen und -radii werden mit double Vektoren bestimmt, und Objekte werden dann relativ zu den Knotenpositionen positioniert. Für diese relative Positionierung benutze ich auch noch double Vektoren, da der Wurzelknoten einen sehr großen Radius hat. Alles was danach kommt ist dann auf floats basiert. Momentan bin ich noch am hoffen, dass mir dieses System die nötige Präzision bietet, aber ich bin zuversichtlich.

[starcow]

Tag Zusammen :-)
Sehr aufschlussreich und interessant was ihr da schreibt!
Vielleicht waren meine Posts teilweise missverständlich...
Es ist definitiv nicht so, dass ich irgendwelche konkreten Pläne oder Ziele für ein MMO habe. Geschweige denn für eins mit 100km2 Grösse. :-D
Einige Leute werfen mir zwar eine gewisse Naivität vor, doch solche Ausmasse hat sie dann doch nicht. Und ich bin im zumindest im glauben das meine Kurve Naivität / Alter eher ne "Sinkkurve" ist. :-D
Verglichen mit euch bin ich auch ein absoluter Programmier-Anfänger. Für weiter als ein OBJ-Parser und ein kleiner Direct3D renderer hat es bei mir nicht gereicht.
Was aber auch daran liegt, das ich mein Fokus in den letzten 4 Jahren gänzlich auf die Gestalterischen Aspekte der 3DGrafik bzw. Grafik allg. gelegt habe. Ich bin also der 3DGrafiker wenn man so will :-D
Die Technik und das Verständnis darüber haben aber für mich nie an Faszination verloren.
Das war jetzt eher ein Gedanken-Experiment wenn man so will.
Ich habe früher sehr gerne DAoC gespielt. In diesem MMORPG (eines der frühen) war es so, das man vom einen Ende der Karte bis zum anderen vielleicht 1Stunde gebraucht hatte. Die Laufgeschwindigkeit dieser äusserst gut trainierten Avataren war vielleicht 10km pro Stunde :-D.
Ich habe halt keine Vorstellung davon mit was für einer Technik die Authoren dieses Spieles das Terrain realisiert haben. Aber ich habe mich gefragt, ob es den _heute_ möglich wäre so ein Terrain einfach 1:1 reinzuladen. Ganz ohne Kompliziertes lodden und mit viel höherem Weitblick. Ich meine das Spiel erschien 2001 und war auch damals keine technische Referenz.
Aber eure Antwort scheint recht klar. Selbst nach 12 Jahren würde man ein Terrain dieser Grösse in diesem Detailgrad nicht ohne weiteres gerendert bekommen.
(Hier noch ein Video zu DAoC http://www.youtube.com/watch?v=_ztQqaFN ... RPUakf8FSM) :-)

Gruss starcow

Btw: Geiles Bild Schrompf :D

[Niki]

Ich wollte hier eigentlich noch auf die Präsentation von Just Cause 2 verlinken...

Meinst du vielleicht das hier? http://www.humus.name/index.php?page=Articles&ID=5

[Niki]

starcow, ich für meinen Teil habe es auch nie so verstanden das du ein riesiges MMO machen willst. Für mich las es sich eher so als wolltest du die Grenzen ausfindig machen.

DAoC mag von 2001 sein, aber das bedeutet nicht das sich jegliche Technik geändert hat. Ein Single-Precision Float hat immer noch 4 Byte, und ein Double-Precision Float hat immer noch 8 Byte. Das war auch früher schon so.

[Schrompf]

Danke für den Video-Link. Ein solches Terrain sollte in der Tat ganz billig zu machen sein. Aus folgenden Gründen:

a) es ist eine HeightMap, also sehr einfache und verlässlich regelmäßige Mesh-Strukturen.
b) Die Vertex-Dichte in dem Video ist vielleicht ~5m oder so.
c) Die Sichtweite ist bestenfalls 500m.

Macht nach Adam Riesling etwa 10k Rechtecke im Bild, also 20k Dreiecke. Das ist trivialer Mist für aktuelle Rechner, da reicht eine schlichte Segmentierung auf ~100m große Patches und Du hast Deinen Terrain-Renderer. Die Material-Zuordnung scheint aus einer AlphaMap zu kommen, die etwas besser aufgelöst ist - vielleicht 1m. Pro 100m-Patch bräuchtest Du also eine 1024er Textur für die Material-Zuordnungen, aber die komprimieren sehr gut und auch eine 1024er bringt heute niemanden mehr aus der Fassung.

Die Präzisionsprobleme bleiben trotzdem bestehen. Bei einem MMO nicht so sehr, weil für die Grobklotz-Bewegungen die Präzisionsanforderungen nicht so groß sind, aber ein Spiel mit Physik müsste sich schon Gedanken über lokale Koordinatensysteme machen.

[starcow]

Ich konnte es einfach nicht lassen und musste das ganze kurz austesten - so konnte ich noch eine Terrain Textur testen, die ich das letzte Jahr mal gemacht hatte. :-)
Ich habe kurz ein paar Hügel in Mudbox gepinselt. Dabei ging ich von einem Grid aus mit folgenden Eigenschaften:
- 1000m X 1000m
- 320 Quads Vertikal / 320 Quads Horizontal (also nach Adam Ries) 102'400 Quads und 204'800 Triangles.
- 3.125m X 3.125m Quadgrösse
Es ist jetzt zwar in Metal Ray gerendert, da ich keine GameEngine zur hand habe, aber die Settings sind so gewählt (Lichtberechnung) das dies auch in Echtzeit möglich wäre (tut ja jetzt sowieso nicht viel zur Sache).

Hier jedenfalls die Bilder, die vielleicht einbisschen Aufschluss über Demensionen und das dabei entstehende Distanz Gefühl geben könnten:

Der helle Punkt rechts unten ist das Licht um die weisse Figur herum (Also die Fackel des Spielers sozusagen :-X)



Die rote Figur (rechte Bildhälfte) ist Luftlinie ~89m entfernt.
Die rote Figur (linke BIldhälfte - wer findet sie :-D) ist ~350m entfernt.
Die Hügel am Horizont sind noch nicht ganz das Ende der Map (wie das Bild von oben vielleicht erahnen lässt).

Mein Eindruck ist nun folgender:
Das ganze wirkt doch ziemlich riesig auf mich. Ich hätte nicht solche Dimensionen erwartet. Player wären bereits schon (auf "natürliche Weise") ab 350 Meter auf einer normalen HD Auflösung kaum noch zu erkennen.
Bäume und andere Hohen Gebäude dürften an der Sichtgrenze von 1km wirklich sehr klein erscheinen. Also kein "Da taucht was fettes aus ner Nebelwand auf" Effekt.
Die Hügel sind mit 3.125m Quads ziemlich smooth. Die Frage ist jetzt was bei starken Steilhängen mit grossem Gefälle passiert. Ob da solche Quads noch reichen, um nicht harte Kanten zu bekommen, weiss ich jetzt auch nicht.

Was denkt ihr darüber. Sind 200k Tris so vertretbar? An einigen Stellen müsste man sicher partiel die Auflösung der Quads erhöhen, um detailierter Sculpten zu können.
Dazu kommen natürlich noch Grass, Bäume Vegetation Häuser etc. Ich könnte mir schon vorstellen, das mann dann annähernd bei 800k Tris landen würde.

Gruss starcow

[Schrompf]

Go for it. 200k Tris sind wurscht. Wir sind bei den Splitterwelten bei 2 bis 4 Millionen Dreiecken pro Frame, und kommen trotzdem noch auf akzeptable Geschwindigkeiten. Da sind die Mini-Frustums für Punktlicht-Schatten viel einschneidender, weil Du immer gleich 6 davon pro Lichtquelle kriegst.

Segmentiere das Terrain aber trotzdem vor dem Rendern. Damit kannst Du zumindest nicht-sichtbare Teile cullen. Und das wird später für Lichtschatten wichtig, da so eine Punktlichtquelle ja auch nur soweit Schatten braucht, wie sie Reichweite hat. Und das sind üblicherweise höchstens ~50m.

[starcow]

Fressen eigentlich so Bäume nicht aunglaublich viel Polys auf? Ich meine so ein kleiner Wald, hat dann schnell mal an die 100 Bäume. Wie hast du dieses Problem in den Griff bekommen? Gab es da nicht so prozedurale Super Bäume die automatischen lodden (Ich glaube das hies Speed-Tree)?

Gruss starcow

[Schrompf]

SpeedTree kannst Du Dir nicht leisten. Das würde aber automatisch lodden, ja. Abgesehen davon gibt es aber nach meinem Wissen keine "fertige" Lösung für Wälder. Der Ausgangspunkt ist in den meisten Fällen ein statisches Modell, evtl. mit separatem Shader für das Blattwerk, weil Du das im Wind schwingen lassen willst oder es schlicht aus Billboards besteht. Damit renderst Du erstmal Deinen Wald und schaust, wie es aussieht. Ab dann wird geloddet - Bäume sind dafür leider kein so dankbares Ziel wie das Terrain, da kann das Einsparen von wenigen Flächen bereits zu groben optischen Fehlern führen.

Bei den Splitterwelten nehmen wir irgendwann anstatt des Baumes nur noch ein Bildboard vom Baum. Die Dinger heißen ursprünglich Imposter, aber wir impostieren nicht wirklich, weil bei uns nur eine Billboard-Grafik aus einer vordefinierten Richtung existiert. Den Wechsel zwischen richtigem Modell und Billboard sieht man bisweilen als heftiges Ploppen, natürlich besonders bei Betrachtung des Baumes aus einer völlig anderen Richtung. Die Billboards werden dann ab einigen Dutzend Metern Entfernung zu großen Segmenten zusammengefasst, die man mit einem DrawCall rendern kann... das ist dann die eigentliche Einsparung.

Wenn ich dann mal an den Splitterwelten weitermache, will ich mal probieren, ob man so einen Baum nicht auch einfach als Sparse Voxel Tree repräsentieren kann. Das wäre die Lösung für alle Richtungsprobleme, sollte rein optisch gar nicht mehr ploppen und der Rechenzeit-Aufwand ist auf heutigen Grafikkarten auch nicht mehr das Problem. Zumal die Bäume dann ja weit genug weg sind und nicht mehr viel Bildschirm einnehmen.

[edit] Nicht zu unterschlagen: es gibt auch kleinere Lösungen zum Erzeugen von Bäumen. Ich habe da aber keinen Überblick. Es gab mal ein OpenSource-Dingens, dessen Modelle aber viele Hunderttausend Polys hatten... nicht echtzeit-tauglich. Dann habe ich auf GameDev.net mal einen Baumgenerator von einem privaten Entwickler gesehen, der hat ganz gute Bäume mit brauchbarem Polycount ausgespuckt. Leider wollte er sich darauf nicht beschränken, sondern wollte unbedingt auch noch selbst rendern, weswegen das Programm für mich auch ausschied. Was es sonst noch gibt, kann ich Dir nicht sagen. Für die Splitterwelten habe ich einige Grafiker an Bäumen verschlissen (es ist anscheinend ein Scheißjob, womit man Freiwillige schnell vergraulen kann) und mir irgendwann von pure3d die Baumsammlungen gekauft. Und die sind echt guter Stoff.

[starcow]

Ok danke Schrompf!

Für die Splitterwelten habe ich einige Grafiker an Bäumen verschlissen

:-D :-D :-D

Jetzt taucht doch noch ne Frage zu deinem vorherigen Post auf Schrompf.
Wieso Punktlicht-Schatten?
In der Natur draussen hat man ja bekanntermassen nur die Sonne / Mond und die werfen aufgrund ihrer Distanz ziemlich scharfe superparalelle Schatten.
In nem Fantasy Spiel wie bei eurem hat man ja keine starken Lichtquellen in der Spielwelt selbst. Vielleicht ein Feuer, Kerze, Fackel, Öllampe etc.
Und bei all diesen Lichtquellen haste aufgrund der Lichtabnahme im Quadrat nach ~8 Meter so gut wie keine Intensität mehr. Selbst wenn man die Wirkung stark übertreibt und die Lichtabnahme linear gestaltet, dürfte doch nach 10Meter Schluss sein. Wie kommst du auf die 50Meter? Ich stelle mir vor, das wenn man eine Lichtqulle hat, die in einem Radius von 50Meter Schatten erzeugen kann, schnell mal die Performance gegen <1fps zusteuert.
Ich merk das immer sehr deutlich mit Mental Ray (In wie weit man das jetzt da vergleichen darf, sei dahin gestellt).
Begrenze ich die Wirkung einer Lichtqulle (also einer InScene Lichtquelle) auf ~10 Meter, sieht man optisch sehr oft keinen Unterschied zur selben Lichtqulle die aber bis 1000Meter wirkt. Das müsste schon ne enorm starke Lichtquelle sein, das man den Cap auf 10Meter sehen kann.
Zudem könnte man doch die Schatten der InSzene-Lichtquellen doch einfach rendern und dann in die Textur backen. Beweglich dürften die Lichtquelle, bis auf die eine, die der Spieler mit sich herumträgt ja sowieso nicht sein. Und Lichtschalter etc. sind ja per se schonmal ausgeschlossen.

Aber vielleicht verstehe ich dich einfach nur falsch - das ist nicht auszuschliessen :-X

In meinem Bild übrigens kommen die Schatten vom Sonnenlicht. Das Figurenlicht erzeugt keine Schatten, hat ne Lineare Abnahme auf 0.0 innerhalb von 8 Meter.

Edit:
Meine Erfahrung ist, das eine dynamische Lichtquelle, die der Spieler herumträgt nicht zwingen Schatten werfen muss. Darauf wollte ich eigentlich hinaus. Wichtig ist natürlich das die Objekte einen Hauptschatten haben. Aber das wäre ja sowieso gewährleistet.

[Schrompf]

Starcow, darf ich vorstellen? HDR-Rendering. HDR-Rendering, das ist Starcow. Ich bin sicher, ihr werden einander zu schätzen lernen.

50m war eine willkürlich gewählte Obergrenze. Bei uns ist das eine Einstellungssache, über welche Strecke die Lichthelligkeit gestreckt wird. Wenn Du tatsächlich rein physikalisch rangehen willst, musst Du bedenken, dass das menschliche Auge einen Dynamikbereich von 10^12 hat. Eine "taghelle" Lichtquelle wie z.B. ein Bauscheinwerfer strahlt Licht ab, das Du im dunklen Wald auch noch in xhundert Metern siehst. Nicht gleichzeitig mit dem Scheinwerfer selbst, das ist klar. Aber mit dem Licht im Rücken kannst Du die Lichtwirkung noch sehen.

Das musst Du nicht mitsimulieren. Es ist meiner Meinung nach eine Abwägungsfrage, welche Lichtquellen man mit Schatten rendert und wie weit man deren Wirkung simuliert. Wenn Du keinen Schatten auf dynamischen Lichtern haben willst, ist das völlig ok. Und wenn bei Dir ewig nur Tag sein soll, kannst Du auch das Sonnenlicht und dessen Schatten einfach in die Terraintextur fest einberechnen. Nichts ist wahr, alles ist erlaubt. Aber nach meiner Erfahrung nutzen die Leute Schatten sehr gern, wenn Du es ihnen anbietest. Wir haben im Rumpf des Händlerschiffs auf ~20m Länge allein 12 Lichtquellen, alle mit voll dynamischem Schatten. Logisch, dass die Framerate dort niedrig ist - selbst mein eigentlich mächtiger Rechner schafft dort nur noch knapp 30 fps. Aber Fakt ist: wenn die Engine es hat, wird es benutzt.

[Niki]

Klasse... diese Pure3D Models sind ja wirklich preiswert ohne Ende. Jetzt muss ich da nur noch schnallen welche 5 Formate denn enthalten sind. Ich hoffe du hast nix dagegen wenn wir dieselben Bäume nutzen? :D :D

[Schrompf]

Mach ruhig. Ich hab schon mehrfach für den Typen Werbung gemacht. Für den Preis kann man echt nicht meckern, und sogar eine kostenlose Sammlung zum Erproben des Workflows ist dabei. Enthalten sind übrigens alle fünf der genannten Formate, also kannst Du Dir stressfrei aussuchen, welches Format Du lesen kannst.

[Niki]

Supi! Und OBJ ist ja nun ober simpel. Das kann man schön leicht umwandeln. Das ganze Vegetations-Paket und die Medieval Modelle werde ich mir wohl leisten.... aber erst mal eins ansehen. Wenn ich damit klarkomme, dann nimmt mir das echt ein paar große Sorgen von der Schulter :)

[starcow]

Das ist echt ziemlich klasse, dass muss man wirklich sagen!
Braucht ihr nicht verschiedene LoD Stufen der Bäume? Die sind ja wohl nicht enthalten, oder irre ich?

Gruss starcow

[Niki]

Braucht ihr nicht verschiedene LoD Stufen der Bäume? Die sind ja wohl nicht enthalten, oder irre ich?

Vielleicht, vielleicht auch nicht :D Die große Schwierigkeit für Leute wie mich ist es überhaupt etwas für den Anfang zu haben. Alles weitere sieht man dann später.

EDIT: Ich will's mal noch anders sagen. Persönlich brauche ich für Motivation auch eine gewisse Optik. Aber ich bin kein Grafiker, und damit ist Optik schwer. Desweiteren braucht man, LOD mal ignoriert, ordentliche Modelle um überhaupt sehen zu können wann etwas gut ist, und wann nicht. Jetzt habe ich mir für den Anfang Bodenpflanzen und Birkenbäume bestellt. Kostet mich €41,65. Klar ist das Geld, aber man muss auch sehen, dass diese Modelle meinen Spaßfaktor für viele Wochen oder Monate nach oben katapultieren können. Vielleicht wird später eine Art LOD gebraucht, vielleicht aber auch nicht. Und auch wenn's erstmal kriechen sollte (was ich nicht glaube), dann ist das immer noch besser als ein Zylindermodell mit Kugeln als Blätter. Wenn's zu extrem ist, dann rendere ich halt Impostors in die Distanz, was so oder so sinnvoll ist.

[Schrompf]

Das sind mehrere detailreduzierte Varianten dabei, glaube ich. Bei den Steinen auf jeden Fall.

[starcow]

Mach dann mal paar Screenshots bitte :-D
Was ist den der Polycount der Bäume? Ist der so genau richtig für euch?

[Niki]

Mach dann mal paar Screenshots bitte :-D
Was ist den der Polycount der Bäume? Ist der so genau richtig für euch?

Screenshots werden noch länger dauern :) Ich bin aufgrund gewisser technischer Änderungen praktisch am Anfang. Ein Hauptgrund warum ich bisher aber noch nicht mal ein Höhenfeld gezeigt habe ist, weil meine Texturen momentan noch geliehen sind. Das muss sich erst ändern (ich kann die in dieser Form nicht selbst erstellen, obwohl's für die meisten Grafiker ein Witz wäre. Ich brauche bestimmte Alphakanäle in meinen Bodentexturen).

Was den Polygon-Count anbelangt, das kann ich nicht beantworten. Ist aber für Games gemacht, also tippe ich so auf 100k-200k. Schrompf kann das vielleicht jetzt schon beantworten. Ich muss warten, weil ich kein PayPal mag und Banküberweisung vorgezogen habe.

[Raphael]

Vor einiger Zeit hatte ich mir mal den hier angesehen:
http://www.gamedev.net/page/community/i ... ditor-r279

Es gab automatische LOD-Generierung und er sah komplex aus. Leider ist die Website down, ich hätte die Beta aber noch auf dem Rechner.
Ansonsten gibt es noch ngplant (http://ngplant.sourceforge.net/), dass hab ich schon ausgiebig genutzt. Nur noch keine Erfahrung mit der LOD-Modell-Bildung. Vielleicht gibt es den kraut-tree editor schon in einer neueren Version, war auf jeden Fall sehr vielversprechend.

Nachtrag: Im Quelltext der Website stehen sogar noch die Lizenzbedinungen: http://www.artifactgames.de/Kraut/

[Niki]

Ja, Raphael, Generatoren gibt's natürlich. Kann man auch selbst machen wenn man denn unbedingt will. Aber die Texturen, wenn sie denn gut sein sollen, müsste man sich als nicht-Grafiker dann doch wieder leihen, oder freie Texturen nehmen bei denen immer irgendwas nicht passt, und wenn's die Grashalmgröße ist. Na, ja, ganz richtig ist das nicht. Ich kann schon Grafik machen, aber ich bin dabei super langsam.

[Schrompf]

Ich hab damals für das interne Forum Bilder davon gemacht. So sehen die aus:

Die Birken sind 500 Tris bid 5000 Tris, die meisten der anderen Bäume sind bei 1k bis 2k.