Terrainberechnungen - was braucht es alles?

Für Fragen zu Grafik APIs wie DirectX und OpenGL sowie Shaderprogrammierung.
Benutzeravatar
starcow
Establishment
Beiträge: 592
Registriert: 23.04.2003, 17:42
Echter Name: Mischa Schaub
Wohnort: Zürich
Kontaktdaten:

Re: Terrainberechnungen - was braucht es alles?

Beitrag von 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
Zuletzt geändert von starcow am 08.04.2013, 17:21, insgesamt 2-mal geändert.
Freelancer 3D- und 2D-Grafik
mischaschaub.com
Benutzeravatar
Schrompf
Moderator
Beiträge: 5401
Registriert: 25.02.2009, 23:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas
Wohnort: Dresden
Kontaktdaten:

Re: Terrainberechnungen - was braucht es alles?

Beitrag von 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.
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
Benutzeravatar
starcow
Establishment
Beiträge: 592
Registriert: 23.04.2003, 17:42
Echter Name: Mischa Schaub
Wohnort: Zürich
Kontaktdaten:

Re: Terrainberechnungen - was braucht es alles?

Beitrag von starcow »

Ok danke Schrompf!
Schrompf hat geschrieben: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.
Freelancer 3D- und 2D-Grafik
mischaschaub.com
Benutzeravatar
Schrompf
Moderator
Beiträge: 5401
Registriert: 25.02.2009, 23:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas
Wohnort: Dresden
Kontaktdaten:

Re: Terrainberechnungen - was braucht es alles?

Beitrag von 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.
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
Niki
Establishment
Beiträge: 309
Registriert: 01.01.2013, 21:52

Re: Terrainberechnungen - was braucht es alles?

Beitrag von 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
Benutzeravatar
Schrompf
Moderator
Beiträge: 5401
Registriert: 25.02.2009, 23:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas
Wohnort: Dresden
Kontaktdaten:

Re: Terrainberechnungen - was braucht es alles?

Beitrag von 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.
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
Niki
Establishment
Beiträge: 309
Registriert: 01.01.2013, 21:52

Re: Terrainberechnungen - was braucht es alles?

Beitrag von 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 :)
Benutzeravatar
starcow
Establishment
Beiträge: 592
Registriert: 23.04.2003, 17:42
Echter Name: Mischa Schaub
Wohnort: Zürich
Kontaktdaten:

Re: Terrainberechnungen - was braucht es alles?

Beitrag von 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
Freelancer 3D- und 2D-Grafik
mischaschaub.com
Niki
Establishment
Beiträge: 309
Registriert: 01.01.2013, 21:52

Re: Terrainberechnungen - was braucht es alles?

Beitrag von Niki »

starcow hat geschrieben: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.
Benutzeravatar
Schrompf
Moderator
Beiträge: 5401
Registriert: 25.02.2009, 23:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas
Wohnort: Dresden
Kontaktdaten:

Re: Terrainberechnungen - was braucht es alles?

Beitrag von Schrompf »

Das sind mehrere detailreduzierte Varianten dabei, glaube ich. Bei den Steinen auf jeden Fall.
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
Benutzeravatar
starcow
Establishment
Beiträge: 592
Registriert: 23.04.2003, 17:42
Echter Name: Mischa Schaub
Wohnort: Zürich
Kontaktdaten:

Re: Terrainberechnungen - was braucht es alles?

Beitrag von starcow »

Mach dann mal paar Screenshots bitte :-D
Was ist den der Polycount der Bäume? Ist der so genau richtig für euch?
Freelancer 3D- und 2D-Grafik
mischaschaub.com
Niki
Establishment
Beiträge: 309
Registriert: 01.01.2013, 21:52

Re: Terrainberechnungen - was braucht es alles?

Beitrag von Niki »

starcow hat geschrieben: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.
Benutzeravatar
Raphael
Beiträge: 65
Registriert: 22.12.2011, 13:39
Echter Name: Raphael Menges

Re: Terrainberechnungen - was braucht es alles?

Beitrag von 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
Establishment
Beiträge: 309
Registriert: 01.01.2013, 21:52

Re: Terrainberechnungen - was braucht es alles?

Beitrag von 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.
Benutzeravatar
Schrompf
Moderator
Beiträge: 5401
Registriert: 25.02.2009, 23:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas
Wohnort: Dresden
Kontaktdaten:

Re: Terrainberechnungen - was braucht es alles?

Beitrag von Schrompf »

Ich hab damals für das interne Forum Bilder davon gemacht. So sehen die aus:
screenshot_baeume.jpg
Die Birken sind 500 Tris bid 5000 Tris, die meisten der anderen Bäume sind bei 1k bis 2k.
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
Niki
Establishment
Beiträge: 309
Registriert: 01.01.2013, 21:52

Re: Terrainberechnungen - was braucht es alles?

Beitrag von Niki »

Nett! Ich bin erstaunt das es nur so wenig Polygone sind. Also ist bei dichtem Bewuchs die Füllrate wohl problematischer als die paar Polygone.
Benutzeravatar
Schrompf
Moderator
Beiträge: 5401
Registriert: 25.02.2009, 23:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas
Wohnort: Dresden
Kontaktdaten:

Re: Terrainberechnungen - was braucht es alles?

Beitrag von Schrompf »

Exakt. Aber wir sind inzwischen ganz schön vom Ursprungsthema abgekommen. Nagut... Starcow ist auch selbst Schuld, er hat mit den Bäumen angefangen :-)
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
Niki
Establishment
Beiträge: 309
Registriert: 01.01.2013, 21:52

Re: Terrainberechnungen - was braucht es alles?

Beitrag von Niki »

Och nöö, das würde ich jetzt so nicht sehen :) Zu Terrain gehört ja mehr als ein Höhenfeld. Bäume, Steine, etc, sind ja durchaus ein Teil davon.
Benutzeravatar
starcow
Establishment
Beiträge: 592
Registriert: 23.04.2003, 17:42
Echter Name: Mischa Schaub
Wohnort: Zürich
Kontaktdaten:

Re: Terrainberechnungen - was braucht es alles?

Beitrag von starcow »

Richtig! :mrgreen:
Nein, ich finds voll spannend! :-)
Schrompf, der Screenshot sieht klasse aus!

Niki
Was hast du den für Vorstellungen bezüglich deinen Texturen? Und was für ne Menge benötigst du?
Ich arbeite ja an meinem Abschlussfilm und dürfte nichtmal in dem Ausmass hier posten, geschweige den an was rumbasteln :-X - aber man braucht ja mal ne Abwechslung. Und vielleicht hab ich noch was in meiner Sammlung drin... hab ne zeitlang Terrain Texturen gemacht...

Gruss starcow
Freelancer 3D- und 2D-Grafik
mischaschaub.com
Benutzeravatar
Schrompf
Moderator
Beiträge: 5401
Registriert: 25.02.2009, 23:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas
Wohnort: Dresden
Kontaktdaten:

Re: Terrainberechnungen - was braucht es alles?

Beitrag von Schrompf »

Niki hat geschrieben:Zu Terrain gehört ja mehr als ein Höhenfeld. Bäume, Steine, etc, sind ja durchaus ein Teil davon.
Nö :-) Bei uns war das Terrain immer nur der große Mesh unter den Spielerfüßen. Alles andere lief bei uns unter dem Begriff "Landschaftsmöbel"
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
Niki
Establishment
Beiträge: 309
Registriert: 01.01.2013, 21:52

Re: Terrainberechnungen - was braucht es alles?

Beitrag von Niki »

starcow hat geschrieben:Was hast du den für Vorstellungen bezüglich deinen Texturen? Und was für ne Menge benötigst du?
Beantworte ich morgen Abend, weil's etwas Zeit kostet, ok? :) Ist schon etwas spät für heute.
Niki
Establishment
Beiträge: 309
Registriert: 01.01.2013, 21:52

Re: Terrainberechnungen - was braucht es alles?

Beitrag von Niki »

So, dann wollen wir mal...

Erstmal Höhenfelder zum einfacheren Verständnis. Du hast eine Graustufentextur, wobei jedes Pixel in dieser Textur eine Höhe darstellt. Weiß ist ganz weit oben, und schwarz ist ganz weit unten. Solche Texturen hast du sicherlich schon zig mal gesehen, und wahrscheinlich auch benutzt. Nun rendert man ein Raster aus Quads, wobei die Rasterpunkte (Eckpunkte der Quads) auf zugehörige Höhen in der Graustufentextur fallen. Die Rasterpunkte werden anhand dieser Höhen vertikal verschoben. Die Graustufentextur hat also genau so viele Pixel (Höhen) wie das Raster Rasterpunkte hat. Diese Graustufentextur nennen wir nun eine Heightmap. Auch diese Technik hast du wahrscheinlich schon mal in einem 3D Programm benutzt, aber wenigstens haben wir jetzt einen einheitlichen Wortschatz für die folgenden Erklärungen.

Jetzt stell dir eine leere Leinwand vor. Diese Leinwand hat ein Grundmaterial, nämlich das aus dem die Leinwand selbst besteht. Jetzt nimmst du einen großen Pinsel, tränkst ihn in Farbe, und schleuderst diese Farbe auf die Leinwand. Diesen Vorgang wiederholst du mit z.B. 8 verschiedenen Farben. Das Ergebnis ist ein modernes Chaos-Kunstwerk das aus mehreren Ebenen (Layern) verschiedener Farben besteht. Dieses "Dranschleudern" von verschiedenen Layern aus Farben nennen wir nun Texture-Splatting.

Das Grundmaterial des Terrains, z.B. Erde, nennen wir Basistextur, und die wird erstmal über das gesamte Terrain gezogen. Generell werden alle Texturen gekachelt, und müssen damit in alle Richtungen nahtlos teilbar sein (seamlessly tilable textures). Die anderen 8 Farben entsprechen anderen Texturen (Gras, Sand, Stein, Schnee, Straße) und werden an entsprechenden Stellen layerweise über die Basistextur gelegt. Also zum Beispiel, Layer 0 = Basistextur, Layer 1 = Steintextur, Layer 2 = Grastextur, Layer 3 = Sandtextur, und Layer 4 = Straßentextur. Nun existiert pro Layer eine Alphamap. Diese Alphamaps haben, der Einfachheit halber, dieselbe Größe wie die Heightmap. Das heißt, pro Höhe, existiert pro Layer ein Alphawert, und dieser Alphawert gibt die Deckkraft für die entsprechenden Layertexturen an. Du hast also zum Beispiel eine Alphamap für den Sandlayer, und kannst nun darin rummalen. Weiß bedeutet "hier ist Sand", Schwarz bedeutet "hier ist der Layer unter dem Sand sichtbar", und Graustufen vermischen die Farben. So kannst du nun also, durch schlichtes Malen, über diese Alphamaps definieren wo Sand ist, wo Straße ist, wo Gras ist, usw. Lediglich der Basislayer 0 hat keine solche Alphamap, denn dieser Layer wird immer einmal erst mit voller Deckkraft gezeichnet. Auch diese Technik hast du möglicherweise schon indirekt benutzt, aber ohne vielleicht zu wissen, dass das ganze Texture-Splatting heißt oder die technischen Details zu kennen.

So... nun habe ich die Grundlage um das Hauptproblem zu erklären. Wenn du nun einen Übergang von Gras nach Sand haben willst, dann benutzt du in der Alphamap Graustufen. Dadurch das Graustufen die Texturen von übereinanderliegenden Layern vermischen, entstehen verwaschene Materialübergänge. Anstelle von Gras mit Sand dazwischen hast du dann plötzlichen grünen Sand. Das kann, je nach gewolltem Grafikstil, sehr hässlich sein (besonders wenn man bedenkt, dass eine Alphamap im Vergleich zur 3D Größe des Terrains sehr klein ist... Ein Quad ist ja größer als ein Pixel)

Das Ziel ist es nun diesen verwaschenen Look zu reduzieren und ganz nebenbei mehr Vielfalt zu erhalten.

Nehmen wir mal an, dass alle Materialtexturen die Größe 1024x1024 haben. Da machst du in Photoshop ein neues Bild der Größe 1024x1024 auf. In die Hintergrundebene von Photoshop packst du die Grastextur. In eine darüber liegende Ebene packst du die Straßentextur, und spendierst dieser einen Alphakanal. Da mein Projekt mittelalterliches Fanatsy ist, sehen die Straßen natürlich nicht aus wie auf der Autobahn. Aneinandergelegte Steinplatten passen da schon eher. Diese Steinplatten formen eine Struktur mit Rillen zwischen den einzelnen Platten. Du kannst nun den Alphakanal der Straßeneben so beeinflussen, dass stellenweise die Grastextur der Hintergrundebene sichtbar wird, und zwar in erster Linie in den Rillen der Straßentextur.
Wenn du dir nun vorstellst, dass alle Materialtexturen im 3D Terrain einen solchen Alphakanal haben, dann kannst du dir vorstellen wie das aussieht. Du erzeugt somit eine viel größere Vielfalt, da das Sichtbare in den Straßenrillen vom Untergrund abhängt. Wenn du nun auch noch daher gehst und sagst, dass das Vermischen der Farben der Materialtexturen nun nicht mehr von den großen Layer-Alphamaps abhängt, sondern von den Alphakanälen der Materialtexturen, dann entfernst du damit das Verwaschene vollständig. Die Layer-Alphamaps sagen dann nur noch "hier ist Sand" (weiß) oder "hier ist kein Sand" (schwarz). Graustufen sind da keine. Auf grund mathematische Formalen entstehen nun trotzdem Übergänge, die sehen dann wie Gras mit Sand dazwischen aus, und nicht wie grüner Sand. Das ganze kann nun aber an Materialübergängen etwas hart aussehen. Das behebt man dann dadurch das doch wieder ein paar Graustufen in die Layer-Alphamap eingeführt werden.

Um das ganze nochmal zusammenzufassen, schaue dir mal folgenden Blogeintrag an: http://www.m4x0r.com/blog/2010/05/blend ... -textures/

Du siehst hier wie Gras und Sand vermischt werden. Im oberen Bild entsteht aus Gras und Sand ein grüner Sand. In dem Bild darunter werden die Alphakanäle der Materialtexturen benutzt, wobei die Layer-Alphamaps nur sagen "hier ist Sand" oder "hier ist kein Sand". Schon viel besser, aber an den Rändern hart. Das letzte Bild zeigt die Wiedereinführung von Graustufen in die Layer-Alphamap. Perfekt!

Für die Programmierer unter uns: ich habe die Layer-Alphamaps nicht 100%-ig korrekt beschrieben. Im wesentlichen wird die Deckkraft der Alphamaps etwas anders benutzt, aber ich wollte hier nicht mit Formeln und Shadercode anfangen. Der oben genannte Blog verrät diese Details.

So starcow, mein Problem ist es nun die Materialtexturen mit den Alphakanälen zu erzeugen :) Bei Gras, Sand, Stein, Schnee, und Erde geht das noch halbwegs, da der Alphakanal quasi nur ein weiches Rauschen enthält. Bei den Steinplatten ist das schon aufwendiger. Das sind übrigens auch genau die Texturen, die ich für den Anfang brauche: Erde, Sand, Gras, Stein, Schnee, Plattenstraße. Falls du da was machen möchtest, dann würde ich mich sehr freuen, aber ich muss mich darauf verlassen können, dass die Texturen dann auch wirklich nicht das Copyright von jemand anders verletzen. Die Größe der Textur-Details ist momentan schwierig abzuschätzen, aber was du in obigem Blog siehst scheint mir einen gute Referenz zu sein (meine momentanen Testtexturen sind da ähnlich). Super wären 1024x1024 Texturen, denn runterskalieren kann man notfalls immer. Falls das zu hoch ist gehen aber auch 512x512 Texturen :) Und noch etwas... ich möchte ungern daran Schuld sein wenn du deinen Abschlussfilm verpatzt. Ich kann warten! :)
Benutzeravatar
starcow
Establishment
Beiträge: 592
Registriert: 23.04.2003, 17:42
Echter Name: Mischa Schaub
Wohnort: Zürich
Kontaktdaten:

Re: Terrainberechnungen - was braucht es alles?

Beitrag von starcow »

Hi Niki
Ich danke dir für diesen sehr umfangreichen Beitrag! :mrgreen:

Ich habe da ein paar Gedanken und Bemerkungen dazu :-)
Das Thema interessiert und fasziniert mich auch schon länger, und ich habe auch immer wieder nach verschiedenen Lösungs-Ansätzen "geforscht".

Ich bin mit den Blending-Methoden über verschieden gross skalierten Masken recht gut vertraut, da ich sie immerwieder selbst einsetze. Aber totzdem Danke für diese gute und ausführliche Zusammenfassung :-)
Ich kann dir mal schildern wie ich in etwa vorgehe bei einem Shading-Network für Szenen mit Terrain. Wobei man hier wieder Anmerken muss, das das auf Echtzeitgrafik vielleicht nur bedingt übertragbar ist - aus gründen der Performance.

Grundsätzlich entwerfe ich Texturen immer in 4k also 4096 X 4096 / gelegentlich auch 8k oder 2k. 16k und und <2k in Ausnahmefällen. 16k ist dann aus Performance Gründen eher nicht mehr so lustig zu gestalten - und hier braucht man auch merklich mehr Ausdauer. Der Unterschied zwischen 2k und 4k ist für mich als Grafiker aber nicht so dramatisch. Wenn ich 10 Stunden an ner 2k Textur sitze und für 12 Studen arbeit das ganze in 4k bekommen kann, ist der Fall für mich klar: 4k.
Weniger als 2k ist für mich wenig sinnvoll. Der Arbeitsaufwand von 1k gegenüber 2k liegt etwa bei 90% - ich bin dann aber mit 1k im rendring doch drastisch eingeschränkt. Und gerade bei sehr gelungenen Arbeiten kann das dann ganz schön ärgern :-)

Bei Texturen für weitläufige Areale setze ich auf eine 4 Paltte vom selben Motiv. Z.b Wiese satt, grün. Davon gibt es 3 Variationen. Alle diese lassen sich aber aneinander ankacheln. Egal von welcher Seite, und welche Textur. Sie sind beliebig nahtlos aneinander kachelbar. Per Zufall wird jetzt die Fläche mit diesen Stücken durchsetzt.
So sieht man selbst aus sehr grosser Höhe keine Wiederholungsmuster.
Fürs Blending setze ich meist auf Fraktale und Prozedurale Texturen (ausser es muss custom sein), die sozusagen "Auflösungsfrei" sind. Meistens ist das bei mir im Shading-Network ein ganzer Tree von geblendeten Fraktalen und Clouds (in verschiedener skalierungen) die dann als Alpha-Make fungieren.
Was mich jetzt aber doch erstaunt, ist die grösse deiner Alpha-Layermap. 1Pixel per Vertex? Das wäre bei meinem Beispiel-Terrain nur ne 320x320 Pixel Map! Da hätte ich jetzt keine Hemmung ne 2048 Map einzusetzen.

Deine Beobachtung vom 50% Blending über grosse Fächen hinweg kann ich nur teilen. Das funktioniert nicht, weils halt nach genau nach blending ausschaut :->
Oftmal bringt aber alleine schon die änderung der Blending-Methode die gewünschte Wirkung. Multiply / Negativ Multiply / Lighten etc. - was dein Programm so hergibt mal testen. ein Mutiply Blending sollte eigentlich auch in RealTime absolut kein Problem sein. Ich glaube all diese Blending Modi sind mathematisch nicht wirklich komplex. Und gerade Modi die so eine art Cap haben, geben oftmals deutlich realistischere Ergebnisse als reine 50% Mix-Blendings.
In der Art meine ich das

Code: Alles auswählen

if (LayerA.Pixel.Helligkeit >= (50+LayerB.Pixel.Helligkeit))
{ LayerA.Pixel.Helligkeit + LayerB.Pixel.Helligkeit}
Was ich jetzt bei deinem Post nicht 100% verstehe...
Du hast also für jede Textur eine kleine Alpha-Masken Map (also nicht die globale Layer-Blend Map). Bei deinen schönen Medieval Steinplatten wären dann die Rillen in dieser Map weiss.
Nun kommt die globale Layer-Blend Map und besagt: Die Steinplatten müssen hier zu 50% mit dem Grass darunter geblendet werden.
Was nun transparent wird, ist lediglich die Rillen der Steinplatten-Map und nicht die ganze Map selbst? richtig?
Was passiert nun aber, wenn die globale Layer-Blend Map besagt, das zu 25% geblendet werden soll? oder zu 75%?
Was man bräuchte wäre eine solche Alpha Map mit weichen Graustufen-Verläufen.
Nun wird aber vor dem rendern aus dieser graustufen Map eine harte s/w gemacht. Mit genau dem Threshould aus der globalen Alpha-Map.

Ich sehe du bist da ja ziemlich tief drin und hast natürlich entsprechende Ansprüche an die Qualität. Zur Zeit drück mein Zeitplan wieder. Ich muss bis morgen Abend eine ganze Tempel Architektur UV-Layouten :-X Ich mach das ja eigentlich sehr gerne (was meine Grafiker-Kollegen immerwieder erstaunt :-D). Nur der Zeitdruck müsste so nicht sein :-X
Deshalb wird es wohl darauf hinauslaufen, das wir die Sache nach meinem Abschlussfilm neu beurteilen müssen (Mitte / Ende Juni). Aber Grundsätzlich fänd ich das schon enorm spannend. Und paar Hires Terrain Texturen zu gestalten ist ja auch nicht sooo das riesen Ding.

Gruss starcow

Edit:
Hier noch ein Beispiel von einer Terrain-Textur von mir.
Bild

Wie in diesem beispiel erstelle ich mir oftmals Templates, womit ich dann per Fraktale verschiedene Textur-Typen blenden kann. Das könnten z.b Blüten in einer Wieso sein. Oder so wie hier, ein etwas weniger bewachsener Untergrund.
Der Vorteil an so einem Template ist dann, das ich die Fraktale schnell ändern kann und so eine Textur erhalte, die zwar ähnlich aber nicht gleich ist. So krieg ich dann auch relativ schnell ne Palette von mehrer Themen hin.
Übrigens war hier auch die grosse Herausforderung den Übergang von "Bewachsen" zu "Unbewachsen" realistisch hinzubekommen. Weil dieser musste ja Prozedural bleiben (austauschbar).
Darum hab ich auch auf eine nachjustierung per Hand komplett verzichtet, um zu sehen wie weit man automatisiert kommt.
Die Hauptthemen (Wiesengrün, Erde) sind eine Mischung aus Fotographie, Pinselarbeit und Fraktalen.
(ist übrigens die Textur, die ich auf dem Terrain eben getestet habe...)

Und hier noch ein Auszug aus einer 16k Arbeit...
Das 16k Quadrat links oben, zeigt genau 1/4 der gesammten Textur...
Bei so grossen Texturen ist es immer wieder interessant zu sehen, wie stark sich der optische Eindruck, in der skalierung ändern kann.
Bild
Freelancer 3D- und 2D-Grafik
mischaschaub.com
Niki
Establishment
Beiträge: 309
Registriert: 01.01.2013, 21:52

Re: Terrainberechnungen - was braucht es alles?

Beitrag von Niki »

Ich melde mich später nochmal, denn grad im Moment ist's schlecht. Habe auch noch nicht alles gelesen. Wollte aber schon mal vorweg sagen... je größer die Originalbilder, desto besser. 1024 oder 512 hatte ich nur deshalb gesagt weil ich dachte das wäre einfacher für dich. Irgendwo muss man ja auch die Bildinformationen für sehr große Texturen hernehmen können :)
Niki
Establishment
Beiträge: 309
Registriert: 01.01.2013, 21:52

Re: Terrainberechnungen - was braucht es alles?

Beitrag von Niki »

So, bin jetzt wieder da.

(1) Mein umfangreicher Beitrag
Mein Beitrag war deshalb so umfangreich, weil ich aus diesem Thread nicht ersehen kann ob du reiner Grafiker oder Grafiker+Programmierer bist. Deswegen wollte ich eine einheitliche Sprache vorgeben :)

(2) Texturgröße
Wie schon zuvor beantwortet. Je größer desto besser.

(3) Paletten von selben Motiv
Ja, daran habe ich natürlich auch sofort gedacht. Ist aber auch mehr Arbeit für dich, und ich kann nicht garantieren, dass ich später auch alle Variationen benutzen kann (performance-technisch). Außerdem bin ich niemand der gleich die ganze Hand nimmt wenn man ihm mal einen kleinen Finger anbietet. Ich habe mich also zurückgehalten.

(4) Größe der Alpha-Layermap
Momentan benutze ich 1024x1024 Heightmaps, und auch 1024x1024 Alpha-Layermaps. Das heißt aber nicht, dass man keine größeren Layermaps nutzen kann. Aber man muss es ja auch mal so sehen... nur weil du pro Vertex einen Alphawert angibst heißt das ja nicht, dass deshalb nur ein einziges Pixel aus der Materialtextur genommen wird und somit ein einfarbiges Quad entsteht. Der Alphawert gibt ja lediglich an ob ein Material benutzt wird, und Materialtexturen sind ja größer als 1x1 Pixel. Und wenn dann die Quads nicht zu groß sind, dann gibt das schon sehr viel Spielraum.

(5) Blendmodi
Du hast schon recht das die meisten Blendmodi mathematisch eher einfach sind. Allerdings ist es nicht so einfach die Blendmodi zum Beispiel pro Layer konfigurierbar zu machen, aus Performance-Gründen. Dazu musst du vielleicht wissen das ich die Layer nicht separate nacheinander zeichne. Es wird einmal gezeichnet, und der Pixelshader berechnet Pixelfarben unter Berücksichtigung sämtlicher Layer in einem einzelnen Schritt. Blendmodus ändern hieße für mich also eine Änderung des Blendmodus für das gesamt Terrain. Auch damit kann man natürlich rumspielen, aber ich bin momentan mit dem normalen Blending recht zufrieden. Also später mal, zumindest um Mal die Unterschiede zu sehen.

(6) Die Rillen in den Platten
Ich habe ja schon erwähnt, dass ich die Beschreibung mit dem Blenden teilweise übersprungen habe. Im folgenden wird angenommen, das 0=0=0% (schwarz) und 1=255=100% (weiß). Ein Wert von 0.5 wäre also ein mittleres Grau.
Du hast einmal den Wert aus der globalen Layermap. Nehmen wir da mal L=0.5 als Beispiel. Dann hast du einen Wert T aus der Maske der Materialtextur. Wenn nun T < L - X, dann wird der Pixel aus der Materialtextur überhaupt nicht gezeichnet (der Layer ist an dem Pixel volltransparent). Wenn T > L + X, dann wird der Pixel aus der Materialtextur genommen (ohne jegliche Transparenz). Wenn L+X >= T >= L-X, dann wird geblendet. Der Blendfaktor B ist dann B = (T - L + X) / (2 * X). Ich hoffe ich habe mich da jetzt nicht vertan :D Die Konstante X gibt hierbei lediglich die halbe Größe des Bereiches an, in dem überhaupt geblendet werden soll. Bei mir ist X=0.1. Versuch am besten die Formeln nachzuvollziehen, denn erst dann verstehst du so richtig was abgeht :)

(7) Dein Zeitplan
Wie ich schon sagte, ich kann warten :) Dein Abschlussfilm muss natürlich Vorrang haben. Ich hab ja für den Moment noch die geliehenen Texturen.

(8) Deine Beispieltexturen
*Neid* Das ist schon mächtig gut. Ich würde da wahrscheinlich eine ganze Woche aus so einem Ding rumpinseln und fotoretuschieren. Und selbst dann würde es nicht so aussehen wie deine Arbeit. Und die Teilbarkeit wäre wahrscheinlich auch schlecht :D
Antworten