Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support equirectangular cubemap projections #814

Open
wasimabbas-arm opened this issue Dec 4, 2023 · 2 comments
Open

Support equirectangular cubemap projections #814

wasimabbas-arm opened this issue Dec 4, 2023 · 2 comments

Comments

@wasimabbas-arm
Copy link
Contributor

Most of the environemnt cubemaps one can find online are in equirectangular format. Its impractical to expect people to convert those to 6-cubemap images before they can be turned into a ktx file.

IIRC there is a way to extract data for each side from the equirectangular projection onto each cubemap face without having to render it like a 3D engine would do. It will be nice if this is supported.

@MarkCallow
Copy link
Collaborator

Its impractical to expect people to convert those to 6-cubemap images before they can be turned into a ktx file

Is it? How do people use these images on GPUs? Do they not make cubemaps?

@wasimabbas-arm
Copy link
Contributor Author

wasimabbas-arm commented Dec 4, 2023

AFAIK there are a few ways how people would use it.

First options is to create a cube map offline using tools like https://github.com/dariomanesku/cmftStudio. That can read
Input and output formats: *.dds, *.ktx, *.hdr, *.tga. and write out Input and output types: cubemap, cube cross, latlong, face list, horizontal and vertical strip.
You can then load those as normal. In Vulkan you should have to load each face, each mip-map etc into the GPU.

The other options is that you load the source file in latlong and do a render to all 6 faces of a cube using the texture and generate the cubemap that way. Provides more control and easy to change cubemaps but requires more runtime processing time.

The other options is to just use the latlong texture as it is and instead of doing cubemap filtering do 2D filtering using the formula that, I can't remember and mentioned above. This option gives you even more control but doesn't use the hardware capabilities available.

Pros and Cons:
Option 1:
Pros:
Not ktx-software problem.
Compressions is easy, each side is compressed separately. No code required to extract faces.
Cons:
Pre-procssing required. Multiple tools required to end up with a ktx cubemap. Will be harder in automated workflows.

Option 2:
Pros:
Can support any projection of cubemap.
Cons:
More engine work required. Requires runtime cost atleast once.
If the latlong image was compressed, your cube map will endup with some uncompressed format or if framebuffer compression available it might be possible to use that.

Option3:
Pros:
No offline or runtime tools required to do anything.
Compression just works.
Cons:
Not using the hardware capabilities available. (Can't say if it will be faster or slower)

I would really like the first option but without having to use another tool to create those 6 faces first.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants