You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We need a set of methods like the current hyperboloid methods, but for S^3.
My main question: Do we want to try to mash this all into one shader, or do we want a separate shader for the spherical (and maybe euclidean) cases? A separate shader would avoid some branching within the shader execution, but that might be trivial performance-wise. I'm leaning towards two separate shaders, one for spherical+euclidean, and a second for hyperbolic. We could, however, share some of the include shader files between the two.
The text was updated successfully, but these errors were encountered:
I think euclidean would be a good next case - it will make clear how things should be abstracted so as to leave as few possible differences between the geometries as possible.
We need a set of methods like the current hyperboloid methods, but for S^3.
My main question: Do we want to try to mash this all into one shader, or do we want a separate shader for the spherical (and maybe euclidean) cases? A separate shader would avoid some branching within the shader execution, but that might be trivial performance-wise. I'm leaning towards two separate shaders, one for spherical+euclidean, and a second for hyperbolic. We could, however, share some of the include shader files between the two.
The text was updated successfully, but these errors were encountered: