Texturemapping Fehler Sphere

[cbadboy]

Aktuell implementiere ich eine primitive Sphere, orientiiert an diesem Tutorial http://local.wasp.uwa.edu.au/~pbourke/t ... exturemap/.
Klappt soweit auch ganz gut, nur habe ich an den Polen Texturmapping Probleme: http://www.image-share.com/ipng-200-251.html

Hier mal mein Code für die Sphere Berchnung, wobei nRings und nSlices, so wie der Radius frei definiert werden können:

Code: Alles auswählen

   int i;
    for (i = 0; i < nRings; i++)
    {
        float phi = ((float) i / (float) (nRings - 1) - 0.5f) * (float) PI;
        for (int j = 0; j <= nSlices; j++)
        {
            float theta = (float) j / (float) nSlices * (float) PI * 2;
            int n = i * (nSlices + 1) + j;
            float x = (float) (cos(phi) * cos(theta));
            float y = (float) sin(phi);
            float z = (float) (cos(phi) * sin(theta));
            vertices[n * 3]      = x * radius;
            vertices[n * 3 + 1]  = y * radius;
            vertices[n * 3 + 2]  = z * radius;
            normals[n * 3]       = x;
            normals[n * 3 + 1]   = y;
            normals[n * 3 + 2]   = z;
            texCoords[n * 2]     = 1.0f - (float) j / (float) nSlices;
            texCoords[n * 2 + 1] = 1.0f - (float) i / (float) (nRings - 1);
}

 for (i = 0; i < nRings - 1; i++)
    {
        for (int j = 0; j <= nSlices; j++)
        {
            int n = i * (nSlices + 1) + j;
            indices[n * 2 + 0] = i * (nSlices + 1) + j;
            indices[n * 2 + 1] = (i + 1) * (nSlices + 1) + j;
        }
    }

Ich kann keinen Fehler feststellen. mache ich etwas falsch an der Texturkoordinaten Berechnung?
Die Textur funktioniert übrigens mit gluSphere Objekten ohne die Fragmente an den Polen ...

[Fred Feuerstein]

Hio.
Nur mal ne Idee ...
Schon mal mit dem Sampler respektive den Sampler-Parametern rumgespielt ? (Mip/Min/Mag)

MfG Fred

[Aramis]

Deine Mappingprobleme sind ein völlig normales Artefakt des verwendeten Projektion der Textur auf die Kugeloberfläche (vergleichbar mit einer flachen Weltkarte und einem Globus), du wirst sie nicht vermeiden können. Texturfilter können die Stellen allenfalls im Blur verschwinden lassen oder sie extra pixelig erscheinen lassen. Alternativ die Texturen „vorverzerren“, wie in dem von dir verlinkten Artikel aufgezeigt - oder machst du das bereits?

Ich hab ihn nur überflogen, aber dein Code sieht i.O. aus.

[eXile]

Vielleicht kann man mit einer "cubed sphere" ein besseres Texture-Mapping finden. Im Allgemeinen ist aber klar: Ohne Singularitäten kann man eine solche Abbildung nicht gestalten ("Satz vom gekämmten Igel"), aber man kann versuchen, durch eine höhere Anzahl an Singularitäten den optischen Eindruck zu verbessern, derart, dass davon jede einzelne weniger ins Gewicht fällt. Dies ist bei einer "cubed sphere" der Fall, dort hat man eigentlich an allen ehemaligen Kanten der Würfelflächen Singularitäten.

[Krishty]

Dann gebe ich auch mal meinen Senf dazu:

Ich wollte zuerst schreiben, was Fred Feuerstein geschrieben hat – sieht so aus, als ob der Mip-Filter nicht linear eingestellt sei. Dann habe ich mir die Texturfilterung aber mal genauer betrachtet … die scheint ja insgesamt nicht zu stimmen (rechte obere Bildhälfte ist total verschwommen?)

Dann habe ich das Z-Fighting auf den Polen gesehen. Ist das dein Problem? Falls ja, fällt mir nichts dazu ein.

Deine Mappingprobleme sind ein völlig normales Artefakt […], du wirst sie nicht vermeiden können.

Das hatte mich dabei stutzen lassen:

Die Textur funktioniert übrigens mit gluSphere Objekten ohne die Fragmente an den Polen ...

eXile hat auch vollkommen recht … ich z.B. benutze für Planetentexturen ausschließlich Texture-Cubes (Cubemaps), die Texelausbeute ist einfach besser und man braucht noch nicht einmal Texturkoordinaten sondern kann die Vertexpositionen recyclen. Was für ein Mapping man wählt hängt aber vom Einsatzzweck ab – will man z.B. später die Oberfläche entsprechend der Map tesselieren, sind Polarkoordinaten die einfachere Wahl. Für pures Rendering sage ich aber hunderprozentig: Nimm Texture-Cubes.

… was dir aber ganz streng genommen alles nicht bei deiner konkreten Frage weiterhilft.

Gruß, Ky

[kimmi]

Wenn das Ergebnis bei einer gluSphere ok auszusehen scheint: Hast du schon mal die generierten Koordinaten aus deinem Algorithmus denen von gluSphere gegenübergestellt? Vielleicht findest du da einen Hinweis, wo dein Fehler liegt. Auf den ersten Blick sieht dein Code ok aus, allerdings liegt hier der Teufel ja bekanntermaßen im Detail.

Gruß Kimmi

[cbadboy]

Danke ersteinmal für die vielen Antworten. Der Fehler lag tatsächlich im Texturemapping filter, hatte hier noch NEAREST MIPMAP
aktiv, mit LINEAR läuft es nun bestens :D

Das mit der Planetentextur war eigentlich rein zufällig, hatte einfach nach einer Textur gesucht, die ganz gut nachvollziehbar ist um
gleich auch noch mal zu schauen, wie sich das ganze als Skysphere verhält. Und da sind Artifakte an den Polen ja sehr unschön,
da sie dem Betrachter ja ständig ins Auge fallen würden.

Skybox läuft auch mit Cubemap, allerdings trotz hochauflösender Texturen werden meine Texturen meist gezerrt und optisch nicht so
schön, zudem sollte man ja mit ner Skysphere besser Zufallsverteilungen, wie z.B. Sterne als Sprites realisieren können ...

Aber Ihr habt mich neugierig gemacht, was dass Sphere mapping mit einer CubeMap betrifft. Habt Ihr dafür vielleicht ein Link der mir
etwas mehr Input bietet oder nen Schlagwort wo ich google mit quälen kann?

[Krishty]

Skybox läuft auch mit Cubemap, allerdings trotz hochauflösender Texturen werden meine Texturen meist gezerrt und optisch nicht so
schön, […]

Gezerrt wird immer, allerdings sollte das bei Texture-Cubes seichter ausfallen als bei Spherical-Mapping … wie hast du denn deine Texture-Cubes erstellt? HDRShop (1) hat eine Funktion, um Spherical-Maps zu Cubemaps zu transformieren (Image -> Panorama -> Panoramic Transformations... > Source Image: Latitude/Longitude - Destination Image: Cubic Environment), die bei Bedarf bilineare Filterung und Supersampling einsetzt – der Qualitätsverlust sollte also kaum nachweisbar sein und durch die automatisch gleichmäßigere Pixelverteilung aufgehoben werden … aber kommt natürlich immer auf den Content an (Abtasttheorem).

[…] zudem sollte man ja mit ner Skysphere besser Zufallsverteilungen, wie z.B. Sterne als Sprites realisieren können ...

Inwiefern? Wannimmer sowas gleichverteilt sein soll, musst du die Anomalien ausgleichen … imo ist das bei Cubic-Mapping sogar weniger komplex, weil man einen zufälligen 3D-Vektor generiert und mit dem Tangens die Ecken ausdünnt. Eine Transformation in ein anderes Koordinatensystem (Polar zu euklidisch), wie sie bei Spherical-Mapping geschehen muss, entfällt dabei.

[eXile]

Vielleicht eine dumme Frage, aber: Warum eigentlich eine Skysphere und keinen Skydome? Dieser ist ohne Singularitäten texturierbar und müsste doch eigentlich dasselbe wie ein Skysphere bieten? (Natürlich bei erhöhtem Aufwand für die Berechnung der Texturkoordinaten und geeigneter Texturaufteilung.)

[Krishty]

Ich beantworte die Frage mit gleicher Unsicherheit: Ist ein Sky-Dome nicht bloß eine halbierte Sky-Sphere? Die Artefakte bleiben in diesem Fall gleich.

[eXile]

Nein. Selbst eine Sphäre mit einem noch so kleinen Loch kann glatt gekämmt werden. Beispiel für eine Halbkugel:



Die Pfeile geben eine Richtung der Texturkoordinaten an, die andere Richtung steht orthogonal zu dieser. Der "Trick" liegt also darin, die Texturkoordinaten genau an der Grenze, an der man die Halbkugel von der anderen Halbkugel aus eine Kugel gelöst hat, parallel bzw. orthogonal entlanglaufen zu lassen.

[Krishty]

Verstehe, die vier Kanten der Textur werden also zu der einzigen Kante, die man als „Horizont“ kennt …

Wie nennt man dieses Mapping-Schema?

[cbadboy]

Skydome soll später einmal kommen, aktuell gehe ich ersteinmal davon aus, das es kein Terrain geben
soll und da eignen sich ja CubeMap und Sphere besser soweit ich weiß ...

Gezerrt wird immer, allerdings sollte das bei Texture-Cubes seichter ausfallen als bei Spherical-Mapping … wie hast du denn deine Texture-Cubes erstellt? HDRShop (1) hat eine Funktion, um Spherical-Maps zu Cubemaps zu transformieren (Image -> Panorama -> Panoramic Transformations... > Source Image: Latitude/Longitude - Destination Image: Cubic Environment), die bei Bedarf bilineare Filterung und Supersampling einsetzt – der Qualitätsverlust sollte also kaum nachweisbar sein und durch die automatisch gleichmäßigere Pixelverteilung aufgehoben werden … aber kommt natürlich immer auf den Content an (Abtasttheorem).

Die Texturen habe ich "geborgt" von Hegemonia bzw. mir welche von einem Freund erstellen lassen. Sphere war mir als Objekt eher in den Sinn gekommen, da ich gelesen habe, dass man weniger Probleme mit Kanten hat und es auch so leichter für die Grafikfraigles ist Grafiken zu entwerfen. Aber nach Deinem Artikel bin ich neugierig geworden ... Dafür werde ich aber noch einiges an Wissen aufarbeiten müssen ;)

[Krishty]

Sphere war mir als Objekt eher in den Sinn gekommen, da ich gelesen habe, dass man weniger Probleme mit Kanten hat und es auch so leichter für die Grafikfraigles ist Grafiken zu entwerfen.

Ja, in der direkten Bearbeitung sind Texture-Cubes (sofern an den Polen keine Details vorliegen) tatsächlich ein bisschen schwieriger zu handhaben – bspw. erwarten die meisten APIs keine Cube-Kreuze, sondern man muss die Seiten erst in sechs einzelne Texturen aufbrechen und übergeben.

Das lässt sich aber alles automatisieren, genau wie die Konvertierung Spherical -> Cubic. Wenn man also nach fünf Minuten Arbeit an der Textur ein paar Sekunden lang ein Skript laufen lässt statt sofort zu testen, sollte das akzeptabel sein, zumal sich die Qualität des endgültigen Produkts ja verbessert.

Aber nach Deinem Artikel bin ich neugierig geworden ...

:)

[eXile]

Keine Ahnung wie man so ein Texture-Mapping nennt, weil ich mir das selber aus den Fingern gesaugt habe. Kann aber sein, dass das wirklich noch einen "bekannten" Namen hat ...

[cbadboy]

Öhm, hättet Ihr evtl. ein oder zwei Links bzgl. des Cubemappings i.V.m. Sphere Objekten? Hab bisher nur eins aus dem MSDN gefunden,
aber das sieht noch nicht so vielversrpechend aus ... OpenGL i.V.m. GLSL wär wesentlich einfacher in den Schädel zu bekommen :D