Live data from Hacker News

Rendering my (billiard) balls in a fragment shader

getlazarus.org

51–60 of 88 posts

Re: Rendering my (billiard) balls in a fragment shader

#52

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'.

Interesting point if it had been apparent it would have been an issue, at what point does a poor Pi become an issue? What would a Pi of 3.0 do?

Here's a presentation show what happens to rendering in the game Doom when π has different values.

https://media.ccc.de/v/mch2022-236-non-euclidean-doom-what-h...

Re: Rendering my (billiard) balls in a fragment shader

#54
post #2

Here is a summary I wrote on my attempt to render balls using only a fragment shader. I am pretty happy with the result, and I've included a breakdown of the creation process.

In the final video, there are still some texture artifacts whenever the number is on the edge (e.g. the ball 4 at 5 seconds). Maybe because of mipmaps? I can't really think of a reason why it happens. It even happens at the bottom of the 4, even though that part is white in the texture.

Re: Rendering my (billiard) balls in a fragment shader

#55

Earlier quoted context omitted.

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...

Thats an interestring post, thank you! Do you think that's why for example JavaScripts Math.PI also comes out to 3.141592653589793?

It must be either a coincidence or backwards. Math.PI is a double precision floating point number that is set to a closest value of pi that could fit in its 64-bit encoding. https://en.m.wikipedia.org/wiki/Double-precision_floating-po...

Re: Rendering my (billiard) balls in a fragment shader

#56

Earlier quoted context omitted.

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...

Thats an interestring post, thank you! Do you think that's why for example JavaScripts Math.PI also comes out to 3.141592653589793?

Not really, that's more related to the fixed precision of IEEE 754 floating-point numbers. In any fixed-precision representation there's always a certain representation which happens to be the best approximation of any constant like pi. That's the one you would pick.

However, you could perhaps infer from the article that IEEE 754 double-precision numbers are sufficient for most physical calculations.

Re: Rendering my (billiard) balls in a fragment shader

#58
post #15

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'.

Lol, wow what a find. You notice the details. I corrected it. Thank you.

At school, I somehow talked myself into a dumb competition with my math geek about memorizing digits of pi.

I won, with 35 digits memorized (he gave up early; that's also around where the first '0' occurs in pi).

I don't miss any opportunities to test that I still remember them correctly, to this day. ;)

Re: Rendering my (billiard) balls in a fragment shader

#59

Earlier quoted context omitted.

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...

Thats an interestring post, thank you! Do you think that's why for example JavaScripts Math.PI also comes out to 3.141592653589793?

Other way around, they use that value because that's the most precision you get with IEEE-754 64-bit floating-point numbers, which is the representation also used by JS for floating-point.
Post reply on HN