Generierung von Planetentexturen - Texturkoordinaten

Für Fragen zu Grafik APIs wie DirectX und OpenGL sowie Shaderprogrammierung.
Antworten
Despotist
Establishment
Beiträge: 394
Registriert: 19.02.2008, 16:33

Generierung von Planetentexturen - Texturkoordinaten

Beitrag von Despotist »

Ich habe es nun nach längerer Zeit endlich hinbekommen für meinen Planetengenrator 3d Simplex Noise halbwegs adäquat auf eine Kugel zu mappen. Das Bild zeigt Graustufen für 3 Octaven und die Kugeltextur hat eine Auflösung von 512 * 256.
3d noise hat gegenüber 2d noise den Vorteil das keine Kante auf dem Planeten entsteht (tilebar) solange der entnommene Noise auch entlang einer Kugel im Noiseraum entnommen wird. Der Durchmesser der Kugel bestimmt dabei die Frequenz des Noise.
planetheights.png
Als nächstes steht an die Normalmap zu der Heightmap zu berechnen, eine Colormap (damit die Planeten unabhängig von der Höhe Farbe bekommen) zu erstellen und Krater einzubauen. Dann will ich mich noch an animierter Atmosphäre versuchen befürchte aber dass die Performance für Echtzeit zu lahm ist. Ich habe entdeckt dass Mono (was von Unity benutzt wird) auch SIMD unterstützt habe aber noch nicht probiert ob es klappt.

Hier noch ein paar Bilder meiner ersten Gehversuche in Blender. Die Raumschiffe sind bewusst Lowpoly und eckig was zum einen aus Zeiteffizienz geschah, zum zweiten meinen mangelnden künstlerischen Fähigkeiten geschuldet ist, zum dritten realistisch ist (zumnindest in meinen Augen) und zum vierten an Retro-Klassiker wie Elite erinnern soll. Außerdem werden die Schiffe voraussichtlich auch nur von oben mit relativ großem Abstand zu sehen sein. Da wären mehr Details garnicht sichtbar. Allerdings muss die Form daher auch wirklich einmalig sein damit es keine Verwechslung gibt.
spaceship_1.png
spaceship_2.png
spaceship_3.png
Zuletzt geändert von Chromanoid am 31.05.2011, 15:39, insgesamt 1-mal geändert.
joggel

Re: Showroom - Aktuelle Arbeiten und Projekte

Beitrag von joggel »

Und du machst das mit Unity?
Mit was hast du dann die Texturen generiert, also wenns Texturen sind.
Und dann daraus wird die Oberfläche des Planeten generiert?
Alles mit Unity?

Fragen über Fragen... ^^
Despotist
Establishment
Beiträge: 394
Registriert: 19.02.2008, 16:33

Re: Showroom - Aktuelle Arbeiten und Projekte

Beitrag von Despotist »

joggel hat geschrieben: Und du machst das mit Unity?
Die Planeten mit Unity, die Modelle mit Blender. Klingt das so unglaubwürdig? ;)

Falls du die Planeten meinst:
Es wird prozedural ein Kugelmesh erzeugt dessen UV-Koordinaten auf die Textur passen (Lat/Long). Dann wird eine Textur mit mehreren Octaven 3d Simplex Noise gefüllt (hier nur Grauwerte für die Höhen, später auch mal Farben aus einer Colorramp). Die Textur wird dann einfach auf die Kugel gelegt.

Die Textur von der Kugel sieht so aus:
heights.png
Das Ziel ist es, einen prozeduralen Planetengenerator zu bauen der mit verschiedenen Seeds und Parametern quasi unendlich viele Planeten (später auch Asteroiden und Sterne) erzeugen kann. Dabei soll man auch auf die Oberfläche zoomen können (in einer 2d Karte) und auch das Terrain an einem Punkt direkt als Terrain bauen können (was in auszügen auch schon funktioniert siehe ein paar Seiten weiter vorn).
joggel hat geschrieben: Und dann daraus wird die Oberfläche des Planeten generiert?
Ja. Hier ist erstmal nur die erzeugung der Höhe zu sehen (als Graustufenheightmap). Später wie gesagt auch Farben aus einer Colorramp. Dadurch dass es prozedural ist lässt es sich "einfach" für jeden beliebigen Punkt auf dem Planeten berechnen oder eben für alles zusammen.

Das ganze hat zur Zeit die Form eines Tools (Unity-Game) mit dem User rumexperimentieren können und so Einstellungen finden die ihren Geschmack treffen. Mit diesen Einstellungen können dann zufällig variiert viele verschiedene Planeten erzeugt werden. Das ganze wird auch Scriptbar sein so dass die User die Klassen auch direkt in ihren Spielen verwenden können um dieselben Planeten wie in der Anwendung zu erzeugen (wenn sie die Parameter und Seeds speichern). Ist aber noch ne Ecke Arbeit bis dahin und die Todolist wird irgendwie immer länger statt kürzer ;).
Wenn das ganze läuft wirdes auch eine Projektvorstellung mit Demo geben. Die Klassen und die Anwendung sollen über den Unity Asset Store verkauft werden. Ist aber bisher sehr Unityspezifisch so dass es für nicht-Unitynutzer wenig Sinn macht. Aber ein Port von einigen Teilen (Heightmap usw) zu reinem C# sollte machbar sein.
joggel hat geschrieben: Fragen über Fragen... ^^
Wenn du spezifische Fragen hast nur her damit. Aber ich bin ab morgen ein paar Tage weg.

Motivation des ganzen ist meine gute Erinnerung an das Spiel "Starflight" wo man auch hunderte Planeten erkunden kann. Ich will irgendwann mal sowas ähnliches bauen.
joggel

Re: Showroom - Aktuelle Arbeiten und Projekte

Beitrag von joggel »

Despotist hat geschrieben: Die Planeten mit Unity, die Modelle mit Blender. Klingt das so unglaubwürdig? ;)
^^. Naja, "unglaubwürdig" nich!
Hab halt keine Erfahrung mit Unity, und überrascht mich, das man einiges damit machen kann.
Dachte man kann nur Modelle einfügen, mit Texturen versehen, Spiel-Logik-Scipte schreiben und sowas eben.
Das man da auch komplexe Meshs selber "scripten" kann wusste ich nich.

Btw:
SchiffModelle sehen aber garnicht so schlecht aus ^^
Despotist
Establishment
Beiträge: 394
Registriert: 19.02.2008, 16:33

Re: Showroom - Aktuelle Arbeiten und Projekte

Beitrag von Despotist »

joggel hat geschrieben: überrascht mich, das man einiges damit machen kann.
Dachte man kann nur Modelle einfügen, mit Texturen versehen, Spiel-Logik-Scipte schreiben und sowas eben.
Das man da auch komplexe Meshs selber "scripten" kann wusste ich nich.
Es gibt nur ganz wenige Dinge die Editor only sind auf den Rest hast du per API in deinen Scripten vollen Zugriff. Ich staune aber auch immer was die User alles damit anstellen und Unity so quasi durch Packages, Plugins usw erweitern.
Die Meshes selber scripten ist ja Voraussetzung für alle prozeduralen Sachen. So wie ich das in den Foren mitbekomme wird das auch ausgiebig genutzt. Es gibt sehr viele Projekte mit prozeduralem Terrain. Einige machen das Built-in Terrain "unendlich", andere implementieren sogar von Grund auf ihr eigenes Terrain (http://www.youtube.com/watch?v=_xcNYvlw1AY&fmt=18) um mehr Kontrolle zu haben. Es ist also sehr viel möglich.

Das mit dem Modelle reinziehen und platzieren ist halt der Leveleditor-Teil den ich auch selten nutze. Meine Sachen werden halt auch eher komplett aus Scripten gefüllt weil ich keine statischen Levels habe sondern die Szenen eine View auf dynamische Daten sind (Planeten, Sonnensysteme, Raumkämpfe usw).

kleine Info zu Userzahlen von Unity:
http://www.marketwire.com/press-release ... 518423.htm
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Showroom - Aktuelle Arbeiten und Projekte

Beitrag von Krishty »

Interessant, dass du eine Long/Lat-Map für das Rauschen benutzt statt eines Texture Cubes. Ich meine: Irgendwann willst du ja auch mal ein Terrain tesselieren, und wenn du dann ebenfalls Lat/Long als Mesh-Basis wählst, hast du da die üblichen Pol-Anomalien. Ich hatte mir für den Fall, dass ich sowas mal mache, immer vorgenommen, die Texturen als Texture Cubes vorzulegen und auch als Basis-Mesh als tesselierten und normierten Würfel zu nutzen, wo die Texel dann quasi 1:1 auf Vertices gemappt werden.

Aber nichtsdestotrotz: Ich hatte mich auch mal an 3D-Rauschen versucht und es wurdescheiße. Darum meinen Respekt für die Textur :)
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Tiles
Establishment
Beiträge: 1990
Registriert: 11.01.2003, 13:21
Kontaktdaten:

Re: Showroom - Aktuelle Arbeiten und Projekte

Beitrag von Tiles »

Despotist, hast du eigentlich die Pro oder die kostenlose Version? Die kostenlose Unity Version hat halt einige Einschränkungen. Mit der Pro sollte aber alles gehen was mit einer "normalen" Spieleengine auch geht. Und wenn nicht findet sich sicher jemand der ein Plugin oder Script dafür schreibt. Nachteil der Plugins und Scripts ist allerdings, dass inzwischen jeder Hasenfurz mindestens nen Fünfer kostet ...
Free Gamegraphics, Freeware Games https://www.reinerstilesets.de
Die deutsche 3D Community: https://www.3d-ring.de
Despotist
Establishment
Beiträge: 394
Registriert: 19.02.2008, 16:33

Re: Showroom - Aktuelle Arbeiten und Projekte

Beitrag von Despotist »

Krishty hat geschrieben: Interessant, dass du eine Long/Lat-Map für das Rauschen benutzt statt eines Texture Cubes.
Ich weiß leider nicht was ein Texture Cube ist und was er macht. Vielleicht kannst du das Konzept in diesem Zusammenhang mal kurz erläutern. Wenn ich von der Textur das Pixel kenne kann ich dessen Position im Raum (auf die Kugel gemappt) berechnen (Kugelkoordinaten) und habe direkt die Position von der ich den Noisewert abgreifen muss.
Krishty hat geschrieben: Ich meine: Irgendwann willst du ja auch mal ein Terrain tesselieren, und wenn du dann ebenfalls Lat/Long als Mesh-Basis wählst, hast du da die üblichen Pol-Anomalien.
Meine Anforderungen beinhalten aber keinen Echtzeitzoom vom Orbit auf die Oberfläche. Die Orbitview stellt den Planeten in der vom User gewünschten Auflösung dar (einmaliges Berechnen) die Kartenview ebenso nur halt zoom-/scrollbar und für einen Punkt kann man sich das dazugehörige Terrain laden. Dabei will ich mich mit LOD und sowas überhaubt nicht beschäftigen und lasse Unity sich darum kümmern.
Das tesselieren sollte insofern kein Problem sein weil ich den Noise ja für jeden Punkt der Oberfläche berechne. Beim mappen der Textur auf die Kugel wird das für die Position jedes Texels im Raum gemacht und beim berechnen des Terrains für jeden äquidistanten Terrainvertex. Am Pol sollten also mMn keine Probleme auftreten.
Ich würds erstmal gern zum laufen bekommen und falls Probleme auftreten oder die Performance nicht reicht weitersehen. Und wie gesagt würde ich die Engine möglichst viele Dinge übernehmen lassen (dazu ist sie ja da). Da jetzt selber mit
Krishty hat geschrieben: Texturen als Texture Cubes vorzulegen und auch als Basis-Mesh als tesselierten und normierten Würfel
anzufangen übersteigt mein Interesse und mein Zeitkonto bei weitem.
Krishty hat geschrieben: Ich hatte mich auch mal an 3D-Rauschen versucht und es wurdescheiße. Darum meinen Respekt für die Textur
Hat auch alles nicht ganz so geklappt wie initial gedacht. Danke.
Tiles hat geschrieben: hast du eigentlich die Pro oder die kostenlose Version?
Die kostenlose. Für mich ist es bisher nur ein Hobby und ich habe keine Lust da über tausend Euro reinzupulvern (mal davon abgesehen das meine Frau was dagegen hätte ;)). Aber sobald es mal was abwirft geht der erste Gewinn in ordentliche Lizenzen.
Tiles hat geschrieben: Die kostenlose Unity Version hat halt einige Einschränkungen. Mit der Pro sollte aber alles gehen was mit einer "normalen" Spieleengine auch geht.
Ich weiß, aber bisher habe ich noch nichts vermisst. Ich bin nicht so der Grafik- und Effektfetischist. Es muss erstmal nur laufen.
Tiles hat geschrieben: Nachteil der Plugins und Scripts ist allerdings, dass inzwischen jeder Hasenfurz mindestens nen Fünfer kostet .
Du kannst ja wählen was du brauchst. Und ein fünfer zu zahlen ist mir meist lieber als da selber Stunden oder Tage dran zu sitzen. Das sehe ich als großen Vorteil von Unity und dem Asset Store.
Grimasso hat geschrieben: Ist doch ne gute Basis mit den Raumschiffmodellen! Erinnern mich ein wenig an die Bots aus Descent
Danke. Bei Descent erinner ich mich nur noch an bunte Pixel und das mir meist schlecht wurde in den Tunneln.
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Showroom - Aktuelle Arbeiten und Projekte

Beitrag von Krishty »

Beispiel eines Texture Cubes (in diesem Fall die Heightmap des Mondes) ist angehängt (darf ich nicht anzeigen; soll ja nicht in den Showroom :) ). Hat halt keine Anomalien und deutlich weniger Verzerrung. Dementsprechend wäre auch der Planet so tesseliert, dass Flächen auf Pixel fallen – wie eine Geodätische Kuppel, nur mit Vier- statt Dreiecken (und einem Bisschen mehr Verzerrung):

Bild

Aber ja, mach erstmal weiter :)
Dateianhänge
Moon height map (cubic, small).png
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Despotist
Establishment
Beiträge: 394
Registriert: 19.02.2008, 16:33

Re: Showroom - Aktuelle Arbeiten und Projekte

Beitrag von Despotist »

Krishty hat geschrieben: Beispiel eines Texture Cubes (in diesem Fall die Heightmap des Mondes)
Als ich das Bild gesehen hatte hab ich erstmal gedacht: "Verdammt, wie hat der die Krater so schön hinbekommen?" ;).
Krishty hat geschrieben: Hat halt keine Anomalien und deutlich weniger Verzerrung.
1. weniger Verzerrung, nicht "keine".
2. geht es hier um die Repräsentation echter Daten, bei mir um die Erzeugung künstlicher Daten.
3. das Problem mit dem Aufbringen der Textur auf eine Lat/Long Kugel bleibt bestehen.
4. Du sprichst (wenn ich dich richtig verstehe) davon die Werte der Textur auf ein Mesh (Kugel) zu bringen. Bei mir gehts ja andersrum und ich berechne die Noisewerte an der Position der Pixel der Textur und mappe diese dann auf die Kugel. Dass das zu Artefakten und Anomalien an den Polen führt ist klar liegt aber mehr an dem generellen Problem 2d Flächen auf 3d Körper zu bringen und umgekehrt.
5. das "Framework" ist so gestaltet dass sich der Nutzer die Daten für einen beliebigen rechteckigen Ausschnitt holen kann und was er dann damit anstellt bleibt ihm überlassen. Das mappen auf eine Lat/Long Kugel ist also nur mein stümperhafter Versuch einer Visualisierung. Genausogut kann man es auf alles andere mappen.

Hier mal ein Bild eines Pols.
pole.png
Krishty hat geschrieben: Aber ja, mach erstmal weiter
Ich bin ja für Hinweise offen um spätere Probleme zu vermeiden. Aber was du da vorschlägst hört sich erstmal zu gruselig für mich an ;). Aber das mit der geodötischen Kuppel hört sich interessant an. Werd das mal überdenken.

@mods: wenn euch die Diskussion zu weit geht für den Thread bitte sagen und wir können es ausgliedern.
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Showroom - Aktuelle Arbeiten und Projekte

Beitrag von Krishty »

Despotist hat geschrieben:Als ich das Bild gesehen hatte hab ich erstmal gedacht: "Verdammt, wie hat der die Krater so schön hinbekommen?" ;).
Stundenlang Kartenmaterial aus den verschiedensten Quellen per Hand zusammengeflickt, weil ich nirgends eine zufriedenstellende Höhenkarte des Mondes gefunden habe ;)

Es stimmt schon – ich spreche davon, 2D-Daten in 3D zu kriegen und du davon, 3D-Daten auf 2D abzubilden. Wenn es nur eine schnelle Visualisierung ist, ist es ja auch tatsächlich wumpe.

Aber eins kann ich nicht stehen lassen:
Despotist hat geschrieben:3. das Problem mit dem Aufbringen der Textur auf eine Lat/Long Kugel bleibt bestehen.
Nö. Da ein Texel in einem Texture Cube durch einen 3D-Vektor adressiert wird, ist seine Position in der Textur ganz einfach identisch mit der Position des Vertex’. Auch, wenn du eine geografische Kugel statt einem Geodom nimmst. Und auch die Umwandlung einer 3D-Koordinate in eine Speicheradresse ist flotter, weil sie im Gegensatz zu der geographischer Koordinaten ohne Trigonometrie auskommt.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Despotist
Establishment
Beiträge: 394
Registriert: 19.02.2008, 16:33

Re: Showroom - Aktuelle Arbeiten und Projekte

Beitrag von Despotist »

Krishty hat geschrieben: Stundenlang Kartenmaterial aus den verschiedensten Quellen per Hand zusammengeflickt, weil ich nirgends eine zufriedenstellende Höhenkarte des Mondes gefunden habe
Ich dachte ja erst es handelt sich um einen der von dir genannten Versuche mit Noise.
Krishty hat geschrieben: Da ein Texel in einem Texture Cube durch einen 3D-Vektor adressiert wird
Ist dieses Verfahren was du beschreibst das Cubemapping oder was eigenes? Gibts da eine Dokumentation der Technik oder ein Tutorial? Da das nicht direkt in Unity drin ist heißt es ja das ganze von Hand zu machen wenn ich mich nicht täusche, wobei Shader für mich eher ein rotes Tuch sind.

So wie ich das sehe schließen sich diese Verfahren und Adressierungsmöglichkeiten nicht aus. Falls es nötig oder erwünscht sein sollte könnte ich das später also noch hinzufügen. Dein Vorschlag ist also keine Grundsatzentscheidung sondern ein zusätzliches Feature.

Danke für den Hinweis mit der geodätischen Kuppel. Das mit der Kugel hat mir ganz schön Kopfzerbrechen bereitet. Die Lat/Long sphäre habe ich letztendlich genommen weil ich ja auch eine 2d Kartenansicht (Rechteck) brauche und dafür dieselbe Textur verwenden kann.
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Showroom - Aktuelle Arbeiten und Projekte

Beitrag von Krishty »

Despotist hat geschrieben:Ist dieses Verfahren was du beschreibst das Cubemapping oder was eigenes?
Ja, das ist simples Cubemapping.
Despotist hat geschrieben:Gibts da eine Dokumentation der Technik oder ein Tutorial?
Hmm, habe auf die Schnelle das hier gefunden. Die Umwandlung der Richtung in X, Y und Seite geschieht im Grunde durch Suchen der Koordinatenkomponente, die am weitesten von 0 weg ist (bei -1; 0,5; -0,25 wäre es also die Seite in negativer X-Richtung) und X/Y sind dann schlicht die anderen beiden Koordinatenkomponenten durch die Hauptkomponente dividiert.
Despotist hat geschrieben:Da das nicht direkt in Unity drin ist heißt es ja das ganze von Hand zu machen wenn ich mich nicht täusche, wobei Shader für mich eher ein rotes Tuch sind.

So wie ich das sehe schließen sich diese Verfahren und Adressierungsmöglichkeiten nicht aus. Falls es nötig oder erwünscht sein sollte könnte ich das später also noch hinzufügen. Dein Vorschlag ist also keine Grundsatzentscheidung sondern ein zusätzliches Feature.

Danke für den Hinweis mit der geodätischen Kuppel. Das mit der Kugel hat mir ganz schön Kopfzerbrechen bereitet. Die Lat/Long sphäre habe ich letztendlich genommen weil ich ja auch eine 2d Kartenansicht (Rechteck) brauche und dafür dieselbe Textur verwenden kann.
Jaa, mach erstmal weiter. Ich weiß z.B. nicht, wie der Texture Cube mit der Äquidistanz funktionieren würde. (Vielleicht was Skalarproduktmäßiges oder so.) Falls du irgendwann aus irgendeinem Grund feststellen solltest, dass die die geografischen Koordinaten doch noch Probleme machen sollten, wüsstest du schonmal, wie eine Alternative aussehen könnte.

Soll ja nicht wieder heißen: „Es ging sooo schnell voran, bis Krishty mir Flausen in den Kopf gesetzt hat.“ ;)
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Despotist
Establishment
Beiträge: 394
Registriert: 19.02.2008, 16:33

Re: Showroom - Aktuelle Arbeiten und Projekte

Beitrag von Despotist »

Krishty hat geschrieben: Soll ja nicht wieder heißen: „Es ging sooo schnell voran, bis mir Krishty Flausen in den Kopf gesetzt hat.“ ;)
"Wieder"???? ;)

Naja solche "Abschweifungen" sind ja auch mal interessant und ich lerne was dazu. Und falls ich es noch benötige weiß ich ja von wem ich eine saubere, schnelle und super integrierbare Implementierung bekomme ;). Spaß beiseite. Es war auf jeden Fall eine Bereicherung für mich. Auch wenn erst mal sehr weit hinten auf der TODO-Liste steht.

Danke Krishty.
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Showroom - Aktuelle Arbeiten und Projekte

Beitrag von Krishty »

Despotist hat geschrieben:
Krishty hat geschrieben: Soll ja nicht wieder heißen: „Es ging sooo schnell voran, bis mir Krishty Flausen in den Kopf gesetzt hat.“ ;)
"Wieder"???? ;)
Nicht von dir, aber aus meinem sozialen Einzugsgebiet kriege ich das fast täglich zu hören ;)
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
joeydee
Establishment
Beiträge: 1039
Registriert: 23.04.2003, 15:29
Kontaktdaten:

Re: Showroom - Aktuelle Arbeiten und Projekte

Beitrag von joeydee »

Despotist hat geschrieben: 1. weniger Verzerrung, nicht "keine".
2. geht es hier um die Repräsentation echter Daten, bei mir um die Erzeugung künstlicher Daten.
3. das Problem mit dem Aufbringen der Textur auf eine Lat/Long Kugel bleibt bestehen.
4. Du sprichst (wenn ich dich richtig verstehe) davon die Werte der Textur auf ein Mesh (Kugel) zu bringen. Bei mir gehts ja andersrum und ich berechne die Noisewerte an der Position der Pixel der Textur und mappe diese dann auf die Kugel. Dass das zu Artefakten und Anomalien an den Polen führt ist klar liegt aber mehr an dem generellen Problem 2d Flächen auf 3d Körper zu bringen und umgekehrt.
5. das "Framework" ist so gestaltet dass sich der Nutzer die Daten für einen beliebigen rechteckigen Ausschnitt holen kann und was er dann damit anstellt bleibt ihm überlassen. Das mappen auf eine Lat/Long Kugel ist also nur mein stümperhafter Versuch einer Visualisierung. Genausogut kann man es auf alles andere mappen.
1. Keine ist auch unmöglich, aber Krishty hat schon recht: mit einem Cubemesh als Basis ist es viel weniger Verzerrung, da sie sich auf 8 statt nur 2 Pole verteilt. D.h. lange dünne Dreiecke entstehen erst gar nicht.
2. Tut nichts zur Sache woher die Daten kommen. Im Gegenteil: reale Texturen für Kugeln (Planeten) findet man sogar eher als lat/long statt als Cubemap.
3. Nein, das Problem ist damit (deutlich besser) gelöst. Du musst natürlich auch das Mesh austauschen (welches Krishty oben gepostet hat), nicht nur das Mapping.
4. Das geht genauso: man berechnet den Wert an einer Texelposition. Um die 3D-Position eines Cubemaptexels zu rekonstruieren ist nichtmal Trigonometrie erforderlich. 3D-Noise auf die Position anwenden und Texelfarbe setzen ist dasselbe. Das Berechnen eines Noisewertes im Raum sollte jedenfalls unabhängig vom Mappingverfahren sein, falls nicht, rate ich dir dringend, auch das zu ändern.
4b. siehe 1.
5. Wenn es dir zur Visualisierung reicht, ist das doch ok. Wenn du später aber eine höhere, evtl. dynamische Tesselierung (LOD) anstrebst, wirds mit einer Cubemap und dem passenden Mesh aber deutlich einfacher und besser.
Despotist
Establishment
Beiträge: 394
Registriert: 19.02.2008, 16:33

Re: Showroom - Aktuelle Arbeiten und Projekte

Beitrag von Despotist »

Wie gesagt habe ich Lat/Long gewählt da ich die so erstellte Textur gleich als 2d Karte verwenden kann wo der User auch Punkte auswählen soll so dass ich deren Position (Lat/Long, 3d Raum) auch direkt kenne. Die Kartendarstellung fällt ja für Cubemaps flach da sie keine gewohnte Orientierung ermöglichen (siehe KrishtyÄs Mondbeispiel). Es wird also wahrscheinlich eh auf eine Mischung der Verfahren hinauslaufen eben für die verschiedenen Zwecke/Darstellungsformen.
joeydee hat geschrieben: Das Berechnen eines Noisewertes im Raum sollte jedenfalls unabhängig vom Mappingverfahren sein, falls nicht, rate ich dir dringend, auch das zu ändern.
Der Simplexnoise wird mit 3d Koordinaten aufgerufen ist also entsprechend flexibel. Für die LatLongtextur werden die Positionen der Pixel über eine Umrechung in sphärische Koordinaten ermittelt welche dann in 3d Koordinaten transformiert werden.
joeydee hat geschrieben: Wenn es dir zur Visualisierung reicht, ist das doch ok. Wenn du später aber eine höhere, evtl. dynamische Tesselierung (LOD) anstrebst, wirds mit einer Cubemap und dem passenden Mesh aber deutlich einfacher und besser.
Da gleich noch eine Frage dazu: Wenn ich die Cubetextur verwende lohnt sich das doch nur wenn ich wirklich die gesamte Kugel abdecke. Wenn ich zb reinzoomen will auf immer kleinere Ausschnitte brauch ich ja den ganzen Rest nicht mehr. Die räumliche Auflösung muss sich aber erhöhen um mehr Detail abzubilden. Wie muss ich mir das in der Technik die von euch vorgeschlagen wird vorstellen? Ich kann ja die Auflösung der Textur nicht beliebig vergrößern (Hardware).
Bei der LatLongtextur sage ich einfach nimm statt den gesamten Planeten nur noch einen Teil von x1,y, bis x2,y2 und berechne die Zwischenpunkte in derselben Auflösung wie vorher (die reale Auflösung bleibt gleich aber die räumliche Auflösung erhöht sich beim reinzoomen).
Was mich auch ein bisschen wurmt ist die "Platzverschwendung" in der Cubemaptextur da ja die Hälfte der Fläche nicht genutzt wird. Oder könnte man das auch vermeiden indem man die Flächen unzusammenhängend speichert und mit den Seiten des Würfels auf den jeweiligen Bereich in der Textur verweist? Das sollte ja relativ einfach gehen wenn die Koordinaten mitgespeichert werden. Oder werden die nur berechnet?
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Showroom - Aktuelle Arbeiten und Projekte

Beitrag von Krishty »

Despotist hat geschrieben:Was mich auch ein bisschen wurmt ist die "Platzverschwendung" in der Cubemaptextur da ja die Hälfte der Fläche nicht genutzt wird. Oder könnte man das auch vermeiden indem man die Flächen unzusammenhängend speichert und mit den Seiten des Würfels auf den jeweiligen Bereich in der Textur verweist?
Cubemaps werden üblicherweise nur zu Darstellungszwecken zu der Form abgerollt, die ich gepostet habe. Intern speichert man sie als ein Array von sechs quadratischen Texturen bzw. einen vertikalen Stapel in 1×6-Seitenverhältnis, siehe wieder Anhang für das Mondbeispiel.

Ich habe gerade nachgerechnet, und die minimale räumliche Auflösung von Texture Cubes ist bei selber Pixelzahl tatsächlich 10 % geringer (also die Distanz, die Texel maximal weit im 3D-Raum auseinanderliegen, 10 % größer):

Gehen wir davon aus, dass du die Erde mit ihren idealisierten 40.000 km Umfang auf 100 km genau darstellen willst, Texel also nicht größer als 100×100 km sein dürfen. Eine geographische Textur wäre dann (40.000 km ÷ 100 km) × (20.000 km ÷ 100 km) = 400×200 = 80.000 Pixel groß.

Von diesen 80.000 Pixeln kannst du theoretisch sechs Seiten eines Texture Cubes mit je 115,47 Pixeln Seitenlänge erzeugen. Du hast dann einen Würfel, der auf jeder Seitenlänge 115 Mal unterteilt ist. Dabei haben die vier Texel um die je sechs Würfelflächenmittelpunkte minimale Winkelauflösung, d.h. maximale räumliche Entfernung auf der Kugel. Und die überspannt einen Winkel von atan(1 ÷ (115,47 ÷ 2)) auf der Kugel, also 0,99635° von 360°, was 110,7 von 40.000 km entspricht.

Natürlich gesetzt dem Fall, dass ich da jetzt keinen Denkfehler drin habe (wenn der liebe Gott gewollt hätte, dass ich Mathe kann, hätte er mir Solarzellen auf die Stirn gepappt).

Das entsetzt mich nun selber ein bisschen, weil ich eher 10 % höhere Auflösung erwartet hätte, da nicht so viele Texel in die Pole abfließen. Die Masse von acht Polen gegenüber zwei bei geographischen Koordinaten macht’s aber.

Man kann Cubemaps tunen, damit sie überall nahezu gleichmäßige räumliche Auflösung haben. Theoretisch lassen sich dann 87 km Auflösung erreichen, aber dann muss man bei jeder Koordinatenumrechnung den Tangens ausrechnen, und das geht massiv auf die Leistung.
Dateianhänge
Moon albedo (stacked).png
Zuletzt geändert von Krishty am 31.05.2011, 12:20, insgesamt 1-mal geändert.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Despotist
Establishment
Beiträge: 394
Registriert: 19.02.2008, 16:33

Re: Showroom - Aktuelle Arbeiten und Projekte

Beitrag von Despotist »

Krishty hat geschrieben: Cubemaps werden üblicherweise nur zu Darstellungszwecken zu der Form abgerollt, die ich gepostet habe. Intern speichert man sie als ein Array von sechs quadratischen Texturen bzw. einen vertikalen Stapel in 1×6-Seitenverhältnis, siehe wieder Anhang für das Mondbeispiel.
Ja so hatte ich mir das vorgestellt. Dann ist ja alles ok.
joeydee
Establishment
Beiträge: 1039
Registriert: 23.04.2003, 15:29
Kontaktdaten:

Re: Showroom - Aktuelle Arbeiten und Projekte

Beitrag von joeydee »

Ja, man verwaltet intern 6 einzelne Texturen. Je eine für ein gewölbtes Quad, welche zusammen eine Kugel ergeben. Die Quads kannst du dann leichter und sinnvoller unterteilen (Quadtree z.B.) als eine lat/long-Map. Und natürlich ebenso Ausschnitte in höherer Auflösung berechnen etc.
Das einfachste Rendern per Shader geschieht dann so: du lädst die Texturen als eine Cubemap hoch und renderst dein Mesh per Cubemap-Lookup. Dazu brauchst du nichtmal Texturkoordinaten im Stream.

Noch ein wenig Mathe from Scratch hierzu, ich hoffe es sind keine groben Fehler drin, aber das Prinzip sollte klar werden:
Das Vorzeichen und der maximale absolute Wert der Koordinatenkomponenten x,y,z eines Vektors verraten, welche Textur zu diesem Punkt gehört. Ist z.B. abs(x) der größte Wert gegenüber abs(y) und abs(z), und ist x<0, liegt dieser Punkt auf der linken Fläche.
alle Werte durch abs(x) teilen, und du hast mit y und z die normalisierte Texturkoordinate des Punktes, gesehen aus der Mitte der Textur mit einer Kantenlänge von 2, das musst du noch auf übliche Texturkoordinaten kompensieren.
Also z.B. (-5,3,1) heißt linke Fläche, (3/5*0.5+0.5, 1/5*0.5+0.5) sind die Texturkoordinaten auf die dieser Vektor auf die linke Fläche zeigt.
Umgekehrt gehts natürlich auch, also Texel (0.4/0.7) der linken Textur in einen Vektor umrechnen: x=-1, y=(0.4-0.5)*2=0.2, z=(0.7-0.5)*2. Den Vektor dann noch normalisieren und mit dem Radius multiplizieren, damit er auf der Kugel liegt.

@Mods: ich denke auch, diese Diskussion sollte evtl. in einen eigenen Thread getrennt werden.
Benutzeravatar
Chromanoid
Moderator
Beiträge: 4254
Registriert: 16.10.2002, 19:39
Echter Name: Christian Kulenkampff
Wohnort: Lüneburg

Re: Generierung von Planetentexturen - Texturkoordinaten

Beitrag von Chromanoid »

Antworten