PolyhedronGeometry - level of detail

Hi,

I think there is no information in the documentation about the effect of level of detail on the number of faces created. I guess the answer is number_of_initial_faces * (n**2 + 2*n +1) , where n is the level of detail, and the number of faces is 36 (12 * 3), 20, 8 or 4 (dodecahedron, icosahedron, octahedron, tetrahedron).

Another point is that I would expect that when a texture is applied onto a sphere or onto a subdivision sphere (by refining a polyhedron), the visual result would be the same, but in the case of a subdivision sphere, the texture is rotated by 180°. Therefore, when the texture is a world map, this means that the prime meridian will be the anti-meridian and vice-versa, when using a subdivision sphere.

Thanks for any help.

It is really simple to fix the texture coordinates:

// rotate texture by 180°
const uv = obj.vertexTextureCoords;
for (let i = 0; i < uv.length; i += 2) {
uv[i] += 0.5;
if (uv[i] > 1) uv[i] -= 1;
}

However, this should be the default…

1 Like

Well, I finished my application, and the problems I faced using THREE.js are in the underlined paragraph, “final remarks”, of the documentation:

https://krotalias.github.io/cwdc/13-webgl/extras/doc-light/index.html

To run the application:

https://krotalias.github.io/cwdc/13-webgl/extras/LightingWithTexture.html

or

https://krotalias.github.io/cwdc/13-webgl/extras/LightingWithTexture2.html

any comment/suggestion is welcome. One day I will port everything to using THREE.js only.

1 Like

I will have to study the fix to remove a seam when equirectangular textures try to use mipmapping. Currently, I just remove mipmapping, as the solution that I found works in some case, but does not work in others. And I do not like this.

The fix that you use is not perfectly seamless, just the seam is much less noticeable. This is much better than having no mipmaps at all.

When I looked at the code, a lot of things already exist in Three.js. I did not understand the issue with UVs and the different ways of creating a sphere. Instead of recalculating the UVs, would it work for you if only the texture is shifted horizontally 0.5 (for 180°) or 0.25 (for 90°)?

The fix depends on how the glsl 3.0 function “fwidth” is implemented on the GPU: Distinctive Derivative Differences | by Ben Golus | Medium.

My hardware is kind of old (2014/2017 macOS Catalina/Monterey) and it works perfectly for my environment. However, running on my iPhone with the latest IOS, and using my fingers to rotate the scene, I can see some problems, depending on the position on the screen.

Using plain WebGL is tiresome, because it is necessary to manage all of those buffers on the GPU, but I just wanted to show people that it is possible.

The seam is problematic depending on the triangulation of the sphere and how the UV coordinates are set. It is quite visible when using a subdivision sphere and disabling the Fix uv (seamless) option in the interface (running using the second link):

It is really impressive how it just disappears with a few lines of code on the fragment shader.

When rotating a texture, all UV coordinates have to be rewritten, otherwise the seam may resurface. For instance, instead of translating 0.25 for 90° just use 1.25 (see rotateUTexture code).

1 Like

I have always perceived this seam as the effect of the natural uv edge. To avoid this seam, I used a narrow strip (+/- a few longitudes) as a second texture and blended it with the large texture in that area in the shader.
Admittedly, this is a bit more complex than just using a single texture, but it doesn’t require a lot of effort. In any case, it works completely seamlessly.
To do this you have to e.g. gimp copy a part of the right and left edges from the texture and put them together in a new, narrow image so that the area then fits together cleanly. You have to convert the width of the section into the corresponding longitudes in order to know from where to where you then have to blend in the shader.

Maybe there is a more elegant method. Since this worked well for me, I didn’t give it any further thought

1 Like

That’s the other approach, but you have to generate a second texture by hand. In my case, I just wanted to use any texture available into a pre-defined directory, automatically.

To complicate things, Safari < 16.4 (macOS Catalina) does not support import maps.
Therefore, either I use dynamic module import, and test the version of the browser and selectively import the three.js version appropriately (I have done that in other applications) or I am stuck with three.js@160.

Anyway, the sphere from three.js has the UV coordinates the way I need. If I subdivide a polyhedron, the UV coordinates are rotated by 180° (no problem, I can just rotate the texture back, and use the fix) but cones and cylinders have UV rotated by 90°. That is, the behavior is not consistent, at least, but I doubt this will ever be changed, which led me to using another package for cones and cylinders.

Do I need cones and cylinders for maps? Probably not, because I have no interest in conic projections. However, the AuthaGraph projection (the equations are not public) is very interesting:

Imgur

Well, I feel like dodging the problems, and that’s the price for using third party software. So far, I have managed to get an acceptable solution, and that is what matters in the end.

Yes, you are right about the shift of 0.25, but in fact it should be 1.25 to force all of the UV coordinates to be rewritten. I fixed the rotateUTexture code for doing that.

1 Like