Question about the bounds of sphericalCoordsToTextureCoords and vice-versa

[mijofr]

Hullo!

I'm building a CylindricalAdapter for use in my own projects right now, to display older cylindrical panoramas pulled from QTVR. When implementing this I've been poking around inside the equirectangular adapter to reverse engineer what the bounds are meant to be for the figures coming out of textureCoordsToSphericalCoords and sphericalCoordsToTextureCoords

For my testing I've been using a nicely low-res 20x6 mesh texture to test with, and turned off texture filtering:

Anyway, when in an Equirectangular Adapter (with cropped-texture panodata) what I'm seeing is that when running sphericalCoordsToTextureCoords, for the X coordinates I actually get values 0-20 inclusive, so 21 possible values, and within the bounds of the vertical range of the panorama I get 0-6 inclusive for textureY. It seems like the transition from one value to another is in the middle of the pixels, so when I aim at points I get these values for the texture coords:

Is this intended? My initial guess was that when within the bounds of the panorama I should be returning 0-19 inclusive as X coords and 0-5 inclusive for Y coords. Is that incorrect?

For the return trip, when transforming texture coords to spherical coords, that seems to return the pitch and yaw of the top-left coordinate of the pixel. Is that what I want, or should it be the average pitch/yaw of the pixel, so the middle?

I know this is a bit nitpickey but I'd just like to make sure I'm right on it. Since cylinders are easy geometry, instead of raycasting I'm just doing a bit of manual trig maths for these functions.

(I was initially doing this to see if there was something special I should be doing with edge cases when rolling off the top and bottom of the texture, if both edges should return texture coords within the size of the texture)

As a side question - since cylindricals don't go all the way to the poles, will there be issues if I return NaN values for when you point up beyond the texture? In equirectangular when it's cropped it returns negatives that would correlate to what it would be if the texture wasn't cropped, but in a cylindrical mapping that would go to infinity.

[mistic100]

Aren't you hitting an edge case/math precision issue because your texture is so small ?

You could debug the function and check if any of the math is wrong, I never had such report on standard panoramas.
https://github.com/mistic100/Photo-Sphere-Viewer/blob/main/packages/core/src/adapters/EquirectangularAdapter.ts#L123-L134

You can also to choose do not implement these functions at all, it will only prevent using textureX/textureY parameters on the rest of the API https://github.com/mistic100/Photo-Sphere-Viewer/blob/main/packages/core/src/adapters/AbstractAdapter.ts#L67-L79

The result of sphericalCoordsToTextureCoords is not used by the viewer itself, it is only exposed on "click" event and such, so I guess you can safely return NaN.