I am kinda looking for some ways out of this little rabbit hole.
I wanted to experiment with high fidelity per pixel cone drawing and shading. I have an application (radar) that really only needs cone 3D geometry and I figured it would be cool if I could render them implicitly and get sharp pixel perfect geometry by deriving the geometry in addition to the shading within the fragment shader.
This all works and I got quite far embedding the z-picking and occlusion logic such that now I finally am able to ignore parts of the cone that intersect my pixel rays behind the camera and to always show the nearest intersection in front of the camera (easier said than done!). Even computing the normal direction was a piece of cake and the lighting looks great.
Now I grapple with computing the texture coordinates, and I'm realizing I might be a bit screwed and forced to use atan2 for the radial angle coordinate on the cone.
Typically whenever we want to reach for atan2 in hot code or shader code, we're trying to do something further with the angle derived and can eliminate it by being clever with various vectors available to us from which various trig values can be derived efficiently. But here I need to directly use an angle for a texture lookup and it seems like I'm SOL and really actually need to use an atan function now in the shader due to the approach I took with this. So far this seems like a dealbreaker and I may actually need to go back to using a traditional cone made out of vertices and interpolated uv coordinates.
For background info, the way the shader is constructed is by substituting the implicit ray equation into an implicit cone equation; as this yields a quadratic equation in the ray's parameter variable, the coefficients of the quadratic equation are computed and substituted in and zero, one or two t-values (distance along ray) pop out.
