41–50 of 88 posts
I happened to notice that PI is #define'd to 3.1415926538, which isn't the correctly rounded off value of 3.14159265358... Seems like they missed a '5'.
What would a Pi of 3.0 do?
Good timing - I was procrastinating on HN instead of trying to fix my phucked-up phong; you've helped me do both.
I happened to notice that PI is #define'd to 3.1415926538, which isn't the correctly rounded off value of 3.14159265358... Seems like they missed a '5'.
I'm surprised you'd have to define pi in a fragment shader at all. Surely such a commonly used constant would be defined in the language/headers already?
What's the benefit of rendering using this technique over a regular sphere rendered with the usual pipeline?
Well first of you get infinite smoothness and better lighting (and reflections if you add them) because there is no underlying geometry. It's just math. It's also much faster, as you're only giving the GPU four vertices defining the square. This can even be sped up further by using point sprites which consume only one vertex.
Furthermore, depending on the GPU and the exact workload, it can be that vertex and fragment shading can run in parallel. In that case, it is better to spread the load over both, instead of letting the fragment shaders do everything.
The same goes for texturing. Instead of calculating most of the ball's color pattern in the fragment shader, and only using texture lookups for the number itself, if you just have a texture covering the whole ball, you basically offload a lot of computation to the texture units.
That said, for a pool game where the balls are one of the most important items on the screen, it's probably worth it to get the perfect smoothness and lighting, as you mentioned.
I'm just getting my feet wet with shaders myself. Could this fragment shader be used in a "real" 3D game? At the moment, the sphere is orthographicly projected onto the screen so the sphere will always appear as a circle rather than an ellipse. How easy would it be to use this shader in place of a spherical mesh as you might find in a typical geometry based 3D render? I.e. could you use the same technique and render…
As far as I know there shouldn't be any distortion issues. A sphere will always look like a circle from any perspective. Well that is unless it's really really big or your are really really tiny and you give the size difference you are relatively close to its surface. At that perspective it just look like a flat plane.
I happened to notice that PI is #define'd to 3.1415926538, which isn't the correctly rounded off value of 3.14159265358... Seems like they missed a '5'.
I'm surprised you'd have to define pi in a fragment shader at all. Surely such a commonly used constant would be defined in the language/headers already?
I happened to notice that PI is #define'd to 3.1415926538, which isn't the correctly rounded off value of 3.14159265358... Seems like they missed a '5'.
That’s a little bit more accuracy than what is needed for this post, but good catch :-) https://www.jpl.nasa.gov/edu/news/2016/3/16/how-many-decimal...
I'm just getting my feet wet with shaders myself. Could this fragment shader be used in a "real" 3D game? At the moment, the sphere is orthographicly projected onto the screen so the sphere will always appear as a circle rather than an ellipse. How easy would it be to use this shader in place of a spherical mesh as you might find in a typical geometry based 3D render? I.e. could you use the same technique and render…
You have to rotate the quad to face the camera, since it has to cover the area where the ball may render (imagine the extreme case: if the quad is perpendicular to the camera, it looks like a line to the camera, you could only render the ball within that line, it wouldn't protrude to the left or right).