Seamless sphere texture mapping

[stiff mason]

When mapping a texture to a sphere, a seam is generated as longitude wraps from 360 deg to 0 deg, thus as uv wraps from 0.0 to 1. 0. This is a result of a primitive's vertices lying on different sides of this wrapping. That is, one or more vertices' uv values lie close to 0.0, and the other's close to 1.0. Therefore, the color of the primitive is decided by interpolating across almost the entire texture (0.0 - 1.0).

Padding, ignoring or clamping do not fix the issue as this only moves the artefact. For example, if we decide to set values >0.1 or <0.9 to 0.0, primitives that contain any one vertex in these ranges will give a seam.

I've attached three images: one displays the seam, one displays the uv values and the third displays latitude and longitude lines.

Does anyone know how to prevent this seam? This is in Unity, but I assume both the issue and it's solution apply to basically all environments.

[stiff mason]

<@&823670431239634975>

[dim sigil]

You need to fix the uv mapping, idk how you do this in unitys editor though, but in blender iirc you select the edge and mark it as a seam

[unreal pumice]

Therefore, the color of the primitive is decided by interpolating across almost the entire texture
If you uv unwrap the model properly, wouldn't the uv value switch from 360 to 0 in instant on the same point in space so there would be no space or gap in between the vertices and therefore no seam either? I don't quite understand how you managed to get that seam so wide, usually at most one pixel wide error regions appear at the wrapping point due to the way mipmap selection relies on partial derivatives of the uvs which dicontinuous uvs break but this here seems to be something not quite the same

Is the first image literally what you got by slapping the texture on the sphere or is it an attempt to visualize a problem you think you are facing?

[stiff mason]

Yes it is the actual issue, not a visualization. When zooming or changing perspective, the line gets distorted and changes.

This is my interpretation of the seam.

[unreal pumice]

But I still don’t get it, why do you have a seam and not an instant switch on uvs?

[stiff mason]

One or more vertices lie very close to 1.0 and the other vertices lie very close to 0.0 in terms of uv.x. Thus, there is an interpolation across these uv’s to determine the color of the primitive. For these uv values, that is basically an interpolation across the entire texture that is displayed (the seam).

This would also explain the inconsistencies of the color of the seam. Notice how in some areas, the seam is basically only blue, or really thin. These are the areas where there is almost only water going across the texture.

[unreal pumice]

I figured so but usually there is no seam area. The vertices at 1 and 0 are on same point (on top of each other). Why isn't that the case for you?

[stiff mason]

Is this not more about vertices lying ever so slightly past 0, and ever so slightly before 1? I've tried setting uv 1.0 to 0.0, however this didn't achieve a noticeable difference.

[unreal pumice]

Take the default Blender UV Sphere as example, there's no seam area. It looks like uv.x values of 0 and 1 are on exactly same vertex. In reality, the UV seam will be split so that the UV values of 0 and 1 are on two different vertices which just lie on top of each other

[stiff mason]

Mine is like this.

uv 0.0 would be in the middle of the blurry triangles I suppose.

[unreal pumice]

You have done something wrong then

[stiff mason]

I see.

[unreal pumice]

Even the unity default sphere is unwrapped this way

[unreal pumice]

seems like in your case 1 would be on the vertex right of the blurry triangle and 0 would be on the left, values 0 to 1 are in between

[stiff mason]

But I have the same problem for the default Unity sphere.

Is the error in the uv mapping?

[unreal pumice]

What does your shader do?

[stiff mason]

https://paste.myst.rs/zxzikvhp

It maps position to longitude and latitude to uv.

It's a bit longer than it has to be because I have some blending (not included in this visualisation), and the texture is split into four.

[unreal pumice]

But this line is just wrong OUT.uv = sphereProjection(v.vertex.xyz);. As I said, vertices with uv.x = 0 and 1 are on exact same place in space so your code would give them the same coordinate although the other should be 0 and the other 1

[stiff mason]

Alright, so what should I do?

[unreal pumice]

One solution would be to give sphereProjection uv.x as a parameter and do something like x = uv.x > 0.5? x : 1.0 - x (or <, not sure which way atan2 works). This could work but I would be terrified to rely on this because I'm not 100% confident atan2 used like that would give consistent results on all platforms

[stiff mason]

Why should we flip u if uv.x > 0.5?

[unreal pumice]

So on one side the vertex would get value of 0 and 1 on the other

[stiff mason]

But now, 0.6 becomes 0.4 which isn't correct? No?

[unreal pumice]

oh right

you should do it only for values very close to 1 or 0

but still this seems very unreliably as I said

I would much rather UV map the model so that it has the sphereProjected coordinates as UVs to begin with so there's no need to rely on shader to do that

@stiff mason wait wait wait... Why do we actually calculate the longitude from the positions in sphereProjection to begin with? Isn't uv.x exactly that already? uv.y might or might not be the correct lattitude depending on the projection but I don't see a reason why uv.x wouldn't be the longitude...

[stiff mason]

That works for the default sphere, but not for my generated sphere. Nonetheless the seam persists when using v.uv for the default sphere.

I've now done the uv calculations for the mesh, but it's only really moved the issue to another place (and the seam is still there of course).

[unreal pumice]

What you mean by "generated sphere"? The Blender default UV Sphere works too

[stiff mason]

I'm generating a custom one in Unity, such that I can control the amount of vertices and the specific vertices.

[unreal pumice]

That's exactly what I meant by UV mapping the model to reflect the sphereProjected coordinates. That's where you should do the coordinates and only read uv.x and uv.y as lattitude and longitude in the shader code

[stiff mason]

Yes, I have done that now.

And removed those calculations from the shader.

[unreal pumice]

good, if it doesn't work, you have done it wrong. impossible to help you further without seeing that code but it should be really straight forward in the mesh generation code to calculate the proper UVs

[stiff mason]

But I mean they are the same calculations, only in a different place. I am still doing world to lat and long to uv.

How would I do it otherwise?

[unreal pumice]

Is it UV sphere, icosphere, rounded cube or something else?

[stiff mason]

It's a rounded cube.

[unreal pumice]

wouldn't UV sphere be much easier?

[stiff mason]

Like a cube with normalized vertices.

I don't really know what a UV sphere is.

I did see one approach where one defines latitude and longitude lines and places vertices at the intersections. Maybe this would be easier?

[unreal pumice]

It's (UV sphere) the default sphere blender uses, it's literally points placed on lattitude and longitude lines

[stiff mason]

I'll give it a go.

[unreal pumice]

That way when you construct the mesh in a loop that iterates through the points to be placed, you can use the loop index to calculate the right uv coordinates (something like i / longitudeLines )

@stiff mason The most important thing to note though, whatever method you choose to construct the sphere, which you likely have missed earlier, is that you need UV seam on that longitude line where the UV coordinates 0 and 1 meet. In practise that requires splitting the edge into two sets of vertices of which both have different UVs. It's similar to how if you want flat shading on a model, you need extra vertices to store the different normals, in this case you need extra vertices to store the two different UV coordinates on the same position

[unreal pumice]

The main reason I suggest using UV sphere instead of rounded cube is that with rounded cube you will have these horrible artefacts near the poles with rounded cube (image below is the default unity sphere) which you would not get with UV sphere because you have more vertices near the poles to do the interpolation with. Even with UV sphere you will get small artefacts similar to this which as far as I know are unavoidable, but adding more longitude lines will make them less and less noticeable

@stiff mason What I mean by split edges would be that for example these two triangles can't share same vertex because one of them needs to have uv.x of 0 and the other 1. For that reason all the vertices on that longitude line must be actually two sets of vertices where the one connects to the triangles on the left side and the other connects to the right side (different UVs). This is what Blender does for all the edges that have UV seams on them (on export, when you edit the vertices the two are logically the same). The default unity sphere must do this edge splitting too to make the UVs work as they do.

[stiff mason]

Yeah

[stiff mason]

This is already the case for my rounded cube, as two faces meet there, but I'll make sure to implement that for the uv sphere.

Just came back from a quick walk, so I'll get on it now.

[unreal pumice]

Btw this is what I mean. With UV sphere with only 8 longitude lines and 3 lattitude lines (usually longitudeLines / 2 - 1 is good amount of lattittude lines) you can see that the UVs are not fully continuous and have these small bands (I'm not sure how visible they will be on your screen) in them similar to the rounded cube one. As pointed out earlier, these are not avoidable due to the way interpolation works but with reasonable amount of longitude and lattitude lines, you won't see these cause any issues. On rounded cube or icosphere, these may cause visible artefacts though. You could get these perfect by not relying on UVs at all and always calculating the fragments longitude and lattitude coordinates from the fragments position. Doing two atan2s on a fragment shader is bit wasteful though when you can easily prebake the lattitude and longitude values to the UVs to cut some work and again, these interpolation issues will not be a problem on higher line counts

[unreal pumice]

Similar issue occurs when one wants to make perfectly smooth cone shape which is impossible due to interpolation ruining the normals. This is the same issue because what you have on the poles is indeed a cone. To fix that I have seen people add more geometry towards the tip of the cone. Adding more geometry to the poles could also work for this UV issue but I doubt you need to worry about it at all

[stiff mason]

The sphere is completed, but the uv calculation doesn't seem to work:

private Vector3[] GenerateVertices(out Vector2[] uvs)
{
    Vector3[] vertices = new Vector3[latitudeLines * longitudeLines];
    Vector2[] nUVs = new Vector2[latitudeLines * longitudeLines];

    int vertexIndex = 0;
    for (int y = 0; y < latitudeLines; y++)
    {
        float latitude = Mathf.Lerp(-PI, PI, (float)y / (latitudeLines - 1));
        for (int x = 0; x < longitudeLines; x++)
        {
            float longitude = Mathf.Lerp(-PI, PI, (float)x / (longitudeLines - 1));

            Vector3 vertex = new()
            {
                x = Mathf.Cos(latitude) * Mathf.Cos(longitude),
                y = Mathf.Cos(latitude) * Mathf.Sin(longitude),
                z = Mathf.Sin(latitude),
            };

            Vector2 uv = new()
            {
                x = (float)x / (longitudeLines - 1),
                y = (float)y / (latitudeLines - 1),
            };

            vertices[vertexIndex] = vertex;
            nUVs[vertexIndex] = uv;

            vertexIndex += 1;
        }
    }

    uvs = nUVs;

    return vertices;
}

[steady frigate]

@stiff mason, your codeblock was automatically pasted to https://paste.myst.rs/gnggjezo

[stiff mason]

@unreal pumice

[unreal pumice]

make the shader to only display the UV colors at first to debug the matter

isn't the mesh also sideways? is it just rotated or is it actually generated that way?

[stiff mason]

The upper part look as what we want, but the bottom part is like flipped.

[stiff mason]

Generated that way. I was thinking to tackle it later, but maybe it's apart of the issue.

[unreal pumice]

could be. Not that it matters a ton but usually it is generated rightside up which also makes sense since you want this to be our planet earth so the poles would be on top and bottom presumably

[stiff mason]

Yeah

@unreal pumice Now it's properly rotated, but it's awfully distorted

Yet the uv map looks okay.

[unreal pumice]

can you share the newest code including the triangle triangle index generation so I could experiment with it?

[stiff mason]

https://paste.myst.rs/1ctyqpgh

@unreal pumice Code above ^

I'd think it would be triangle definition because everything is like stretched, but at the same time the mesh looks liek it should, and the wireframe looks correct too.

[unreal pumice]

I would be quite confident it's something to do with the uvs

[stiff mason]

Yeah you're probably right

Ah

There are more vertices at the pole but the uv doesn't account for this

The algorithm assumes lines are spaced evenly

[hoary wraith]

what is the shader

[stiff mason]

It works now. No seams either

[stiff mason]

Shader is just sampling from a split texture and blending values. I moved the uv calculations to the mesh and generated a uv sphere instead

[hoary wraith]

oh okay

[stiff mason]

@unreal pumice Thank you so much for the help. I got it working by changing the latitude range to -PI/2 -> +PI/2, and determining uv.y by (latitude + PI / 2) / PI.

[unreal pumice]

This is what I get with your code when longitudeLines is 16 and latitudeLines is 8. Looks like there's something seriously wrong. For larger counts it seems to work except for the poles and likely it stilll does something weird which doesn't just show up. Did I mess something up or does this happen for you too?

For me at least there seems to be an inner and outer mesh of which the inner seems to be messed up when it comes to the UVs. This could be some triangle indices thing

[stiff mason]

mines like this

[unreal pumice]

For large line counts I need to go inside the mesh to see anything going on but that's definitely not right

I might have messed up mine then

[stiff mason]

No, I think it was because I had to change the latitude range

Try -PI/2 to PI/2

[unreal pumice]

Oh yeah it does work now. I think the sphere wrapped once around itself earlier

[stiff mason]

Yeah

Well thanks for the help!

[unreal pumice]

Animation of what happened earlier 😁. Glad you got it working, you are welcome

[unreal pumice]

@stiff mason Last thing (I hope), when I draw a little sphere on middle point of each triangle, I get a ring of triangles at the very top where there shouldn't be any triangles. That is because you are generating extra vertices on top and triangles that connect to those extra vertices which will get squeezed to nothing (the middle points of those triangles is there because they have 2 vertices at the pole and the third on the first latitude line). Mesh.Optimize doesn't seem to fix this either so you would have to modify your code to take is into account if you want to remove those. Not a big deal anyways but just wanted to let you know

[stiff mason]

Thanks, I’ll look into it

[hoary wraith]

should use another method of generating verts

[stiff mason]

What method?

[hoary wraith]

Fibonacci sphere algorithm

[stiff mason]

interesting

[stiff mason]

How would I generate uv values for this algorithm?

Going through latitude/longitude conversions isn't really an option.

[unreal pumice]

Other than more even spacing, is there something else that would be beneficial here? I think getting the uvs correct would be really hard to get working properly and I think it could also suffer from similar interpolation issues at the poles as normalized square method does

[hoary wraith]

why hard

you can still use polar coordinates to sample the texture

spherical

[unreal pumice]

Hard because at some point you would have to revert the longitude coordinate (uv.x) from 1 to 0 and that would get us back to the original seam issue (#1325907859975704716 message). To fix that, the edge where the UV discontinuity happens should be split into two vertices but with Fibonacci sphere that line is much more unpredictable, with UV sphere it's just one of the lines of longitude. Again, it's possible to reconstruct the latitude-longitude coordinates in fragment shader but storing them as UVs sounds more performant (and they are generating the sphere by code anyways so might as well prebake the coords there)

@hoary wraith and this (#1325907859975704716 message) is the other issue discussed earlier where the linear interpolation does very poor job at representing the polar-ish coordinates near the poles. The UV sphere does not really fix this issue (which afaik is unavoidable) but makes it far less pronounced due to more geometry at the poles

[unreal pumice]

The Fibonacci lattice is a good way to distribute points (somewhat) evenly on a sphere but I don't think the triangulated meshes themselves look too appealing. There seems to be a way with the Fibonacci sphere to get the poles more dense (which is the biggest weakness of UV spheres) which would help the pole issue but the seam issue still exists. I think I should be able to find some way to to deal with the seam issue but I don't have time to give it a try right now and I think UV sphere should be good enough middle ground between many solutions, easy to implement and produces pretty clean geometry

[hoary wraith]

why do you need more dense poles

I would expect the poles to be more precise since more of the texture would map there

[unreal pumice]

I'm talking about the area very next to the pole. Here is for comparison UV spheres with 32, 16, 8 and 4 lines of longitude (rendered by just outputting the UVs). You can see how with smaller amount of edges towards the pole, there's these clear discontinuities in the UV coordinates that appear at the edges leading to the pole (some of which are highlighted). On the 32 resolution sphere those lines are not very noticeable and with even higher resolution spheres, those lines are hard to notice even when zoomed very close

Maybe this would be more fair comparison. Here the amount of lines of latitude remains the same yet the ones with less resolution will have more pronounced discontinuity lines towards the pole. Technically this happens all around the model and not just the poles but it is most noticeable near the poles

[unreal pumice]

@hoary wraith For UV sphere the discontinuity issue comes from these empty areas missing from the UV map. I believe this will happen no matter which way of modeling a sphere you choose but I'm happy to be proven wrong. With the default sphere in unity (which is a normalized cube) this problem is much worse. The more there is edges pointing towards the pole, the smaller the gaps will be between. I am quite confident that no matter how you construct your sphere, you can never fully cover the whole UV range from (0, 0) to (1, 1) (when the UVs represent the longitude and latitude coordinates (is that called spherical coordinates?))

[hoary wraith]

Oh. I think there's a way to map a rectangle onto a sphere (with distortion)

[unreal pumice]

How would that work?

[hoary wraith]

You know spherical coordinates?

[unreal pumice]

I assume I do

[hoary wraith]

You have a 2pi by pi rectangle. X coordinate corresponds to theta (longitude) and y is phi (latitude)

Makes sense or explain more

[unreal pumice]

go on

I can already guess where this is going

[hoary wraith]

no that's the whole thing

given a point on the sphere, you obtain those two angles, then perform a lookup on the rectangle texture

color that point accordingly

[unreal pumice]

I guessed wrong... Where would you do that though? Vertex and fragment shader both have their problems (in fragment shader it's just bit wasteful but will obviously give perfect results). Are we talking about something else than a shader?

[hoary wraith]

Just the math

There would be optimizations to apply for rendering

[unreal pumice]

But where you apply the math

[hoary wraith]

It's proof that you can texture a sphere without those cutouts

[hoary wraith]

You can precompute uvs

so in the vertex shader the UV is passed to fragments

more verts is better to approximate

idk what is used in practice but this is essentially what I would do

[unreal pumice]

But that was the whole point about the UV discontinuities around the poles. The more vertices there are connected to the pole, the more precise the UVs will be. That may be self-evident but that's what I meant

And isn't this exactly what we/they did?

The spherical coordinates were earlier calculated in the vertex shader and were moved to the mesh generation (stored in UVs)

[hoary wraith]

I still don't understand how the discontinuities arise

if anything, the poles are most precise because they map to a proportionally larger area on the texture

or is it actually imprecise for that reason

because a small movement on the sphere near poles corresponds to a large movement in the rectangle, meaning error will be amplified

easy mathematical fix tho

[unreal pumice]

That is true, but elsewhere the distortions only distort the texture, at the poles pieces of the texture will be missing. I think this is the exact same issue why you cannot create nicely smooth shaded cone that doesn't have these ugly strips no matter how hard you try. You can easily add more geometry to make the strips thinner and therefore less visible like you can in this case

The cone issue is about normals and ours is about UVs but I think the principle is exactly the same

[hoary wraith]

The cone issue is an issue that applies to all geometry

If you want more precision you add more vertices

I don't understand why the poles won't be textured at all

Maybe I just need to play around with an example

[unreal pumice]

That is true but that's where it's particularly visible (like in our UV case, the pole is a cone where the missing UVs show up, for the normal case the missing normals show up harsh lines)

[unreal pumice]

They will be textured but not continuously

[hoary wraith]

Why not continuously?

If you move in a continuous way on the sphere, it always corresponds to a continuous movement on the texture, except across poles. But if you've done your texture right (colors matching) it will be color continuous

[unreal pumice]

Because if you look at this line for example, you can see how most of it is missing. The texture could take this into account for this particular mesh but if you yoink any texture of earth from internet for example, it will be textured from bottom to top

[hoary wraith]

This is not how I've set up my texture

It really is just a rectangle

None of those cutouts

[unreal pumice]

Do you mean a subdivided rectangle mapped into a 3D sphere?

[hoary wraith]

no like my texture is a rectangle

Every point on the sphere maps to a point on the rectangle, and every point on the rectangle maps to a point on the sphere

There's no point on either form that doesn't have a corresponding point

The underlying sphere mesh doesn't matter because you can always decompose to spherical angles to derive the uv

[unreal pumice]

@hoary wraith I get what you are saying but I don't think it would work in practise (I think it would always leave gaps if you just save the spherical coordinates in the UVs and use the UVs to place the texture). if you have a mesh unwrapped like this for example, these two fragments would have different longitude coordinate although they both lie on the same longitude line (the right UV.x coordinate in this case is the middle point of these two). You can obviously correct for this in the shader code if you know the amount of longitude and latitude lines on the mesh but I don't think you can ever precalculate the longitude and lattitude coordinates to UVs and have no discontinuities in the UVs

[hoary wraith]

The solution is not to use this UV map

[unreal pumice]

Like this one?

[hoary wraith]

If you use a map with discontinuities it will have discontinuities

[hoary wraith]

Yes?

It's a terrible mesh

A better mesh would be all triangles formed from that algorithm I posted above

But it's UV map would not contain straight lines mostly

I think

[unreal pumice]

@hoary wraith The problem with this one is that at the north pole for example, all those vertices that are on the top row gets placed at one single point (at the pole obviously). This squeezes all the highlighted triangles to nothing (two edges basically) and we are left with only the lower triangles, essentially the same issue as here #1325907859975704716 message

[hoary wraith]

The rectangle is squeezed more at the top and less at the bottom

It still remains continuous

And they're not rectangles how I do the mesh

They would be triangles

[unreal pumice]

I disagree. There's no rectangles, only triangles. Any triangle that is placed so that one of it's edges is at the top edge of the UV map (as opposed to only one vertex) will not exists in reality (because it will have two vertices on same position, the north pole)

And even if unity used rectangles instead of triangles, rectangle with two of it's points on same position becomes a triangle

[hoary wraith]

The triangles aren't triangular in the UV map

triangles sharing a vertex with a pole become a rectangle in my mapping

[unreal pumice]

I know, but when you move that into unity, it becomes two triangles

[hoary wraith]

no the mesh is a triangle, the UV is a rectangle

it's two different things

the triangle warps to a rectangle under the map

[unreal pumice]

The UV sure is a rectangle but it doesn't matter what the UV looks like if in reality we can only see half of it (the other triangle). The other triangle of the rectangle is squeezed out of existence and therefore we cannot observe it

[hoary wraith]

no the triangle at the pole becomes a small rectangle

[unreal pumice]

It becomes triangle that has 2 vertices at the exact pole, which makes it no triangle. It doesn't matter if triangle of area 0 theoretically exist if we cannot see it

[hoary wraith]

no no you misunderstand

[unreal pumice]

I don't think I do

[hoary wraith]

there's never a rectangle in the mesh

only triangles

And not even a rectangle made of two triangles

I get what you are saying

[unreal pumice]

That is true, but all of these blue triangles here #1325907859975704716 message have two vertices with the latitude of 90 degrees which means that in the actual mesh they are located at the pole

The UV map is supposed to be an accurate representation of the lattitudes and longitudes of the vertices, therefore those triangles must have 2 points on the pole and that is not possible for a triangle

[hoary wraith]

I can't explain it now, but a triangle on the pole of a sphere really does become a rectangle in the uv

I'll draw a pic when I get home

[unreal pumice]

ping me when you do

[hoary wraith]

@unreal pumice

[unreal pumice]

I'll try something out... might take a while depending

[hoary wraith]

is there anything unclear? i tried to give a nice proof

[unreal pumice]

I see what you mean (awesome sketches btw). I do understand that this happens in theory but I don't think this happens in practise (in blender or unity or any other triangle based software). I actually take back what I said about quads. If unity used quads instead of triangles, I believe this could indeed work. Let me show what I mean. Let's start by a very simple question, if we create a quad (made of two triangles) and give it a checkerboard texture like in this picture. What would happen if we take the top edge of the quad and scale it down to nothing? Would the vertical lines starting from the bottom converge towards the top most point (where the two vertices are on top of each other) or something else entirely?

[hoary wraith]

in this case, it would be like what you talked about from above. the two top verts would overlap and one tri would degenerate

but i think the software is limiting the kind of uv mapping you can do

you can try writing a custom shader (do it in frag for simplicity) to sample the above texture

[unreal pumice]

Yes, this is what happens and it's where the problem lies. I don't think it is so much limitation on the UV mapping but rather the fact that each vertex must have single UV coordinate which does not change. In order for the lines to converge, the UVs of the top most vertex would have to change

[hoary wraith]

if you're doing my triangle example above, the lines will converge. don't think about the pole itself, but rather right before it. you'll see that the lines do converge

[unreal pumice]

The lines do but even if you unwrap the model to look like a square on the UV map, in practise you will end up only seeing one of the two triangles making the "quad" and half of the texture would not be visible

[hoary wraith]

no no there's no triangles in the uv

its a rectangle in the uv and triangle in the mesh

[unreal pumice]

So it is in this example. The UV map does look like a square and the mesh looks like a triangle yet half of the texture is missing

[hoary wraith]

why is half the texture missing?

every single point in the rect corresponds to the triangle, and vise versa

there's no degeneration/overlap like you talked about above because there's only one tri

[unreal pumice]

I see where you come from. Let me put it this way. How do we ever form this triangle in Blender, in Unity (procedural generation) or in vertex shader of any sort? It clearly has 4 distinct data points worth of information for the UV data that needs to be rendered on the triangle mesh yet triangles by definition can have only 3 vertices and therefore 3 UV values that the engine will interpolate between when the triangle is rendered.

As much as it would make sense mathematically, no engine lets you make a triangle with 4 different UV coordinates

[hoary wraith]

no no the triangle is in the mesh only. in the uv its a rectangle. the triangle's uv coordinates in the mesh are (as i wrote before): (0, 0), (0, b), (a, b). this is all that's necessary

wait

[unreal pumice]

I get it, but how do you create such triangle in the mesh data

[hoary wraith]

oh i do see your point that interpolation here fails. so not at the vert shader level. a naive frag shader would be able to implement this

two draw calls. one for the poles and one for the rest of the tris. how i might do it

OR two triangles

no

im like 30% about to write a render to see how i can do this

[unreal pumice]

This is what I meant all along. I don't think there is any way to construct the mesh or the UVs so that by just sampling the texture (texture on spherical coordinates from somehwere on the internet) based on the UVs so that all of the texture would be visible even if zoomed very closed in, in other words the apparent texture on the mesh would be discontinuous and so would the UVs. One solution suggested waaay before on the thread was to do the spherical coordinate reconstruction in the fragment shader but that might be bit much especially on some low end devices. This way of using two draw calls I didn't even consider, that is really cool idea. The main mesh could be rendered using the UVs only and the poles could be done using separate shader that calculates the coordinates in a fragment shader to make it cheaper (by not doing it for the whole mesh). I see a new discontinuity issue arising from this approach too but it would likely be less noticeable. Likely just rendering using the UVs is good enough too regardless of the discontinuity issues assuming they don't need some very closeup shots of the planet and if the mesh resolution is high enough, the issues region and effect will be small enough to not be noticeable. The poles are also just mostly white ice (on earth) so couple issues there might not be that big of a deal

[hoary wraith]

also also there's a way to map the interpolated wrong coordinates to the correct ones

[unreal pumice]

That might be what I referred to in the last sentence here #1325907859975704716 message

If the longitude and latitude line counts are known, I assume only some very basic arithmetics (+-*/) would be required to correct the wrongly interpolated UVs in the fragment shader

[hoary wraith]

for the poles, if the initial coordinate is (x, y), the corrected coordinate is (x*b/y, y)

wait let me draw a pic

[unreal pumice]

This is for the one triangle case only where the triangle is supposed to take the space of the whole UV map right (from 0 to 1 on both axes)?

[hoary wraith]

well from 0 to a and 0 to b. yes one triangle (so poles). all other triangles map to some kind of three curvy sided shape in the uv

WAIT

don't put a vertex on a pole??

nah that wouldn't work the interpolation would totally goof

[unreal pumice]

you mean in the middle instead of corner?

Are we doing something like this now? (looks like could simplify the calculation of the corrected UVs). By brains not braining anymore

[hoary wraith]

no

okay i feel compelled to render this now UGH

fire up the opengl and c

[unreal pumice]

good for you, I ain't touching that stuff never again . Once tried to render some text with opengl and it was all wasted time in the end. Maybe I should try again some time

[unreal pumice]

If I got everything correct, from this UV arrangement, correcting the UVs should be as easy as this:

float a = 1.0 / ((AmountOfLatitudeLines + 1) * (0.5 - abs(uv.y - 0.5)));
if (a > 1.0) //this fragment is on the pole triangles and should be corrected
{
  uv.x *= a; 
}

I have to go get some sleep now. I will try tomorrow whether this actually works but it just might.

[unreal pumice]

@hoary wraith This does indeed seem to work (shader recreated in Blender). All of these spheres are UV mapped like in the image above so that the uv.x is 0 for all the vertices at the poles. Every sphere just has different AmountOfLatitudeLines value according to their resolution so the correction can be done correctly. There might be an easier way but I think you need AmountOfLatitudeLines regardless in the shader code to do the correction

The texture is just a simple checkerboard texture slapped on top of the corrected UVs

[unreal pumice]

It is actually surprising how badly distorted/jagged these textures are for the low resolution spheres. Geometrically it makes a ton of sense when we look at the triangles that are generated but somehow I have always thought it's no big deal because the interpolation takes care of everything

[hoary wraith]

what's the underlying mesh?

maybe the Fibonacci would work better

[unreal pumice]

You can see the black outline of the edges, it's just a simple blender UV sphere

[hoary wraith]

forgot what we even set out to do with this lol

[unreal pumice]

This #1325907859975704716 message is just about receiving these #1325907859975704716 message wrong UVs in a fragment shader and performing some arithmetics to get the correct UVs on the poles as if the triangles mapped to a quad on the UV map

[hoary wraith]

oh yes

so tada it's a continuous texturing

[unreal pumice]

It indeed is. Just requires knowing the latitude line count in the shader but that shouldn't be a big issue

[hoary wraith]

Even just hardcode it for extra savings

Although I don't think this works for other meshes?

[unreal pumice]

Might as well assuming it is constant (I don't know if they have planned to have multiple spheres with different resolutions for example, could even use shader variants for those potentially)

[unreal pumice]

Only for UV spheres UV mapped like shown

[hoary wraith]

Mhm

I'm not a fan of all those wasted tris at the poles and would much prefer the equidistant layout

I think it probably would still work though. You just need to calculate how many tris are placed around the poles

[unreal pumice]

From what I have seen, the Fibonacci sphere type vertices look nicely distributed along the spherical surface but the triangulated mesh doesn't look clean at all (most of the quads are very thin likely causing similar texture distortions as the UV sphere does). There might be some clever way to triangulate those meshes but I have yet seen one. I think icosphere could be a better option than Fibonacci in that it would produce very self similar and non distorted triangles with very even spacing between the vertices. Then we might run into UV seam issues and honestly at that point I would rather just reconstruct the spherical coordinates from the positions in fragment shader and not rely on UV data at all

[hoary wraith]

Inverse trig on a frag shader oof

[hoary wraith]

Not sure where you looked, but this seems to be very nice https://stackoverflow.com/questions/76593284/delaunay-triangulation-of-a-fibonacci-sphere?noredirect=1&lq=1

[unreal pumice]

That looks better than what I remember seen but there's now no predictable pattern at the poles which would likely cause much harder issue to prevent there

[hoary wraith]

Assume a point at the poles?

[unreal pumice]

I think without we would run into problems again

Basically no matter how the mesh is constructed, we would run into discontinuity issues at the poles if I'm not mistaken and fixing those in a fragment shader for this particular mesh seems out of my expertise. For a UV sphere that was easy enough for me

One solution not discussed yet would be to construct a lookup texture that maps the UVs into spherical coordinates from whatever UV mapping is used. This way only one extra texture sample would be required although this has it own obvious downfalls too (extra memory, one texture per planet resoultion required (relevant if there's multiple), maybe not the easiest to implement, the resolution is a limiting factor (although bilinear filtering could help a lot) etc.)

Now that I think about it, it shouldn't be particularly difficult to just render the whole mesh into a render texture using a custom shader that uses inverse trig to fill in the spherical coordinates

[hoary wraith]

By uv sphere you mean your triangle rectangle mesh?

[unreal pumice]

yes

blender calls it a UV sphere, there might be a better more universal name for that

[hoary wraith]

The generalized pole correction is just a mapping from a triangle with one vert at the pole, to a trapezoid with parallel edges vertical

I think it can be done

[unreal pumice]

I think the problem arises when we actually try to implement this in a shader code. As far as I know, most shader system would only provide you the interpolated data so you wouldn't know to which triangle (what are it's 3 vertices) this fragment belongs to and therefore knowing how to correct the UVs of this specific fragment would be really hard if the triangles are not arranged in some mathematically predictable way in the UV map (so the interpolated UV coordinate alone would be enough to calculate where this fragment belongs to. In theory it is always the case but not always is it practical to calculate)

[hoary wraith]

not practical vs mathematically impossible

[unreal pumice]

what do you refer to by "mathematically impossible"?

[hoary wraith]

as in there's no way to uniquely transform the pole triangle to a corrected uv map

so, given interpolated uv coordinate, it is impossible to derive the original intended/corrected uv coordiante

[unreal pumice]

I mean it is certainly possible in theory but for most meshes/uv mappings, it would be practically impossible

[hoary wraith]

why do you say practically impossible

[unreal pumice]

For example given some interpolated UV coordinate in the arbitrarily triangulated Fibonacci sphere you linked earlier, I cannot think of any way to gain any information of the triangle itself that this UV coordinate belongs to without using a lookup texture (or potentially with some extra per vertex data?)

[hoary wraith]

oh no i mean specifically just poles

[unreal pumice]

How do you even know that this given UV is part of the pole in the Fibonacci sphere?

[hoary wraith]

two draw calls? or maybe some branch if the uv is high or low enough

no i think it needs two draw calls or extra data

[unreal pumice]

But even if you used two draw calls, wouldn't you have to fall back to doing inverse trig for the poles? Even if you know that one of the triangle's vertices lie on the pole, you wouldn't know much about the other 2 and therefore I don't quite know how you would be able to figure out the corrected UVs

[hoary wraith]

well my hope is that you are able to derive the angles from the interpolated uv

i am not sure if it is possible

[unreal pumice]

I'm very surprised if it is possible

[hoary wraith]

if you allow for passing that additional longitudinal count maybe??

[unreal pumice]

for the uv sphere that is demonstrably possible, but I don't think the Fibonacci sphere even has any longitude line count

[hoary wraith]

i'm using the longitudinal line count as equal to the number of triangles around the pole

and i believe the Fibonacci sphere exhibits radial symmetry about the polar axis so this can be also used

so the triangles around the poles are regular?

[unreal pumice]

Not in the example you showed, I don't think so. As I suspected, they use stripy.sTriangulation that uses Delaunay triangulation which afaik doesn't guarantee in any way regular triangulation (even if the points might be symmetrical). The more pleasing looking triangulations that I have seen looks like these one which likely doesn't fix many of the issues we had with the UV sphere (dense poles, stretched triangles/thin quads)

[hoary wraith]

This is not fib?

[unreal pumice]

I'm not sure but if I understand it correctly, it is except for the poles which they had to do this type of trickery to avoid severe rendering issues (the quads would get super thin at the poles) https://blender.stackexchange.com/questions/60898/closing-fibonaccis-hole

[hoary wraith]

It seems like this user achieved something

https://stackoverflow.com/questions/76593284/delaunay-triangulation-of-a-fibonacci-sphere?rq=1