This method is not time sensitive. Because of conservation of momentum and energy, Euler integration is not an issue. The problem is that when a collision happens, you let the 2 objects intersect with themselves and the wall. This leads to the small cube slowly drifting through the wall. If you just snap back the cubes positions after a collision, you should be fine. Technically the pieces don't even need to move, you just have to count the collisions respecting the alternating order of wall and cube collisions.
The problem here is that we don't know if the blocks collided until it's too late and they're already overlapping. So we must reduce the time step to be notified earlier of a collision occurring. You're suggestion of overwriting the position of the blocks breaks a few laws of physics and will introduce an additional source of error without actually fixing the original issue. There are two solutions: 1. Upon detecting overlap, compute how far back to reverse the simulation until the blocks are just touching. Do so, and then compute the collision and continue. 2. Before moving the blocks, measure the distance to the next collision. If this is less than the sum of the velocities then advance the simulation by a fractional time step such that they just meet. Then compute the collision and continue. In physics engines, method 1 is called a discrete simulation, advancing by a fixed time step and solving intersections retro-actively, very common in video games as it's relatively cheap to compute. Method 2 is called continuous collision resolution and is more computationally expensive and so sees less use in video games (Fun fact: this method was used in Diablo 3's bespoke physics engine to give us that sweet ragdoll physics)
@@thetastefultoastie6077 The only thing that matters to get an accurate result is the order of wall and cube collision. And it's only decided by the sign of the relative speed of the small cube. As long as you maintain that order, anything goes. Position doesn't matter much as long as you ensure the correct order.
Ah, thank you for this discussion. Indeed I did not explain this properly, oy! @Tasteful, if you would like to write a new comment (essentially what you wrote above) that is stand-alone I can pin it. I will address this during my live stream and maybe try to make a new version?
@@thetastefultoastie6077 I understand what you're saying, but this isn't a time dependant problem, and can be solved analytically. Therefore the only reason for the time stepping should be visualisation, not too get the answer. The visualisation could be solved simply with the fix above but it means it'd run faster without grinding to a halt.
@@Brahvim I’ve never looked at a comment and wanted to make a comment about how awful it was until now. I don’t care that it was over a year ago, that was one of the worst things that I have read in my entire life. Please, never let any words escape from your head again, whether verbal, digital, or pen and paper. Your thoughts do not deserve to be heard.
@@brando3465 _Thanks._ I've always talked to people about my UA-cam comments sounding cringe anyway. _Well this one was just stupid,_ and I'll have to make sure I make less of these. UA-cam is _just not_ the place for me to do these things, maybe. ...Thanks.
It's amazing how accurate you got it! Even having seen the 3blue1brown video, I was blown away by how the digits of Pi appeared, and the correct ones to boot! And all with so little code.
Agree !!! Pi is such a magical number , so mind bending where and how people come up with different ways to find it ! It's everywhere too !! Happy Pi day ! :D
Knowing the velocity of both blocks, you could calculate the point in space and time where they collide. So you don't need time steps at all! (Except for animation purposes). If the time until collision is above say 1/60th of a second you could use a time step for animating. In fact that would give you a nice iterative formula for pi. (That would converge quite slowly!)
Yeah I didn't use time or distance at all in my program to count collisions. It might seem like the small block could get crushed between the wall and big block if the big block is really big but I think what happens is there is trillions of small collisions that occur slowing the big block down enough so the crushing can't happen. At least in a mathematical model.
Man For this you deserve 3,141,592,653,589,793,238,462,643,383,279,502,884,197,169,399,375,105,820,974,944,592,307,816,406,286,208,998,628,034,825,342,117,067 subscribers. And No I didn't copy-paste or see and type it. I remember 100 digits of PI using ASAP Science's song '100 digits of PI '!!
I did this in processing myself and after 7 digits it was just too slow.. I can't believe it went till 9 digits at such a good speed. But it's super impressive. I love how we all enjoy coding mathematical ideas that just make programming fun😂❤️
A Good way would be to calculate the "exact" collision point. Then you could calculate the amount of time that the small block needs to hit the wall, add v*time to both, calc exact collision point, repeat.
29:47 The difference between float/double and BigDecimal, as well as the difference between int/long and BigInteger, is that using primitive types, the JVM is allocating a chunk of memory just for that primitive type's previously-set boundary, while as a for BigInteger/BigDecimal, the JVM is directly using the memory to store the bytes, which naturally results in a bigger usage of memory for the application. If you have a lot of RAM and you need high-precision for numbers, you can safely use BigInteger/BigDecimal. Just be careful not running into Infinite loops!
That clack sound is the same as the clack that Clackers made, a toy from the late 60's that used to break kids wrists :) Good article on Wikipedia about them. Super video!
You can also simulate/calculate pi in different bases by adjusting the mass ratio between the blocks! You get pi in base ten if the ratio is 10^2^n, you can do binary with 2^2^n, hex with 16^2^n, etc. You have to convert from base 10 to the target base, of course.
The reason why Euler integration is normally approximate is because it assumes v to be constant throughout a time step, resulting in setting x += v, where in theory it should be x+= integral of v dt. In this case the objects are moving conserving momentum, so v is a piecewise constant function and, as long as the time step is smaller than the smallest distance between two consecutive collisions, the algorithm will give exact results.
@@philippg6023 Yes, he does prerender everything. It's a python library he wrote himself. I mean, why should he play it live? It's a video, after all, playing it live and recording it would be a waste of precision and smoothness.
I think that using the speed of both blocks after the last collision can bring more digits to pi ; possibly up to 8 digits for 64 bit double floating point. The slope of that line represent the best rational approximation to get a few more digits of pi. The current code compute 10 digits of pi and double are 18 digits total. One extra twist of optimization could be to avoid redrawing the cubes if they didn't move by a whole integer, which is one pixel. We expect no more than 1 order of magnitude improvement here. This code reminds me the bresingham algorithm to draw circles using integers only.
30:10 For the optics method, the trick is to use complex numbers to represent the angles, rather than explicitly dealing with angles or relying on any kind of trig function. Using the small angle approximation you can construct a complex number for a particular angle 𝜃 as just 1+𝜃i, and then n*𝜃 is (1+𝜃i)^n. Here's a quick python implementation: ideone.com/T4UCnV For the kinematics method, instead of a fixed timestep you can directly compute the time until the next collision as dt = (x1+w1-x2)/(v2-v1) and make that as one single step; then to animate it you can either interpolate between timesteps or you can have a separate fixed-timestep integration that you re-seed from the main integration at each collision. This also lets you play the clack sounds at a more granular time resolution rather than forcing it to be quantized to the animation framerate. If you're interested I have a python implementation of this that works for an arbitrary number of blocks in an arbitrary number of dimensions, including an interpolation mechanism. At this point I don't have anything for generating the actual animation, but I can at least plot graphs: gist.github.com/AJMansfield/00d69e1488c2b1eb56b8c4da2ca739dc Alternately, you can even forego tracking the block positions altogether, since we already know what order the collisions happen in and the position doesn't figure into the momentum transfer equation. If you take this route you can also simplify things even further and perform the momentum transfer as a single matrix multiply rather than as a number of separate steps. Here's another quick python implementation of this method: ideone.com/jPBh8C
Nice hint with the video length (31:41) And offcours awesome video as always I find it cool how you are so motivated and you actually made me want to learn a few digits of PI myself so I made an app that lets you train PI like a vocabulary trainer. I think you would like it
I watched the videos from 3blue1brown when they were released and I also absolutely fell in love with the clacking, hahaha! I like seeing I'm not the only weirdo in this world :3
I just programmed it on my phone up to d=9, was a bit tricky to get right but not that bad... Essentially the main part of code is: public boolean iterate() { if(v1>0) { cols+=2; double tempV1 = getNewV1(); double tempV2 = getNewV2(); v1 = tempV1; v2 = -tempV2; return true; } if(Math.abs(v2)>Math.abs(v1)) { cols++; double tempV1 = getNewV1(); double tempV2 = getNewV2(); v1 = tempV1; v2 = -tempV2; if(v2
Dan, just precalculate the collision without simulating velocity in steps. All you really need to do is calculate the moment of the collisions, not what's in between
What I thought about doing is: instead of doing a simulation that checks collision through coordinates, you could just evaluate whether the blocks will collide or not or if the smaller block will hit the wall, like so (block 1 is the smaller one, with speed v1 and block 2 is the bigger one, with speed v2): if v1 > 0 and v1 < v2, the blocks will never collide again; if v1 < v2, block 1 will hit the wall; if neither is true, blocks 1 and 2 will collide with each other and change speeds based on the formula. Based on this idea, I created a program in C++ that does exactly that, but by 11 digits the imprecision got too big and the results stopped matching :\
you could make the time steps increase proportionally to velocity and inversely to distance close distance + high velocity = lots of tiny steps large distance + low velocity = few large steps
You can speed up the calculations by a lot if you just set timeSteps to 6 ** (digits - 1), instead of 10 ** (digits - 1). You won't miss any counts, I've tested it with 11, and it didn't miss a single number.
amazing Π fun. I'd like ou to show basic workings for how physics formulas are derived. it's not that hard to run through conservation of momentum and energy quickly. years since I did it but we only had calculators and spreadsheets to do such models in those days!
I think a better way to fix the precision issues would be to use a variable timestep. You can predict exactly when the next collision will be so you can be sure you get it right.
This idea have been discussed in more detail in another comment trail. The two choices are skipping until close to collision then allow the current code to resume looping from 0 to 9 times to detect the collision and find the pi digit or go past collision and back track with a loop similar to the present code.
:D I tried to make this simulation when it came out and it it worked but was rly buggy because there box went on the the other side of the "wall" thing Thank you so much :D
it would be cool if you would do the squares size to depend on its mass, so it would look realistic (it would look awful and probably crash the browser after 3 digits, but it would be entertaining anywyas)
This method is not time sensitive. Because of conservation of momentum and energy, Euler integration is not an issue.
The problem is that when a collision happens, you let the 2 objects intersect with themselves and the wall. This leads to the small cube slowly drifting through the wall.
If you just snap back the cubes positions after a collision, you should be fine.
Technically the pieces don't even need to move, you just have to count the collisions respecting the alternating order of wall and cube collisions.
I came to see if this comment was here, not too write it myself, but because I didn't think it was a problem but wanted to get confirmation :-)
The problem here is that we don't know if the blocks collided until it's too late and they're already overlapping.
So we must reduce the time step to be notified earlier of a collision occurring.
You're suggestion of overwriting the position of the blocks breaks a few laws of physics and will introduce an additional source of error without actually fixing the original issue.
There are two solutions:
1. Upon detecting overlap, compute how far back to reverse the simulation until the blocks are just touching. Do so, and then compute the collision and continue.
2. Before moving the blocks, measure the distance to the next collision. If this is less than the sum of the velocities then advance the simulation by a fractional time step such that they just meet. Then compute the collision and continue.
In physics engines, method 1 is called a discrete simulation, advancing by a fixed time step and solving intersections retro-actively, very common in video games as it's relatively cheap to compute. Method 2 is called continuous collision resolution and is more computationally expensive and so sees less use in video games (Fun fact: this method was used in Diablo 3's bespoke physics engine to give us that sweet ragdoll physics)
@@thetastefultoastie6077 The only thing that matters to get an accurate result is the order of wall and cube collision. And it's only decided by the sign of the relative speed of the small cube. As long as you maintain that order, anything goes. Position doesn't matter much as long as you ensure the correct order.
Ah, thank you for this discussion. Indeed I did not explain this properly, oy! @Tasteful, if you would like to write a new comment (essentially what you wrote above) that is stand-alone I can pin it. I will address this during my live stream and maybe try to make a new version?
@@thetastefultoastie6077 I understand what you're saying, but this isn't a time dependant problem, and can be solved analytically. Therefore the only reason for the time stepping should be visualisation, not too get the answer.
The visualisation could be solved simply with the fix above but it means it'd run faster without grinding to a halt.
I love that the video length is Pi (31:41)! Happy #PiDay!
Was this intended?
@@MaxPicAxe yes
Holy crap I didn't notice this, I love when youtubers take the time to add little easter eggs xD
We have a mission - lets make the likes 3 141
@Shreerang Vaidya let the sharing begin #Piday #Collisions #JavaScriptbenchmark
15:30 FUNDAMENTAL THEOREM OF ENGINEERING
Gordon Chan You had 3.14 likes but now you have 3.15
e=pi=3
and sin x = x ofc
g/3 = pi = e = 3
Jose Gonzalez ah yes, g/3
Calculates Pi On Pi day ... with a Pi long video ...
how committed someone can be?
dont forget eating pie and singing the pi song
Lol
@@tregi yup
Pi commited
approximately pi long
the video length is 31:41 this is just excessive
And also: Unexpected and a Coincidence (maybe)
27:14
It goes like this, the wall, the block,
the drawing loop, the ticking clock,
the baffled Dan programming Pi collisions 🎶
You should be proud of yourself
That's amazing
p5 js
p5 js
The baffled Dan composing Pillelujah!
Pillelujah, Pillelujah, Pillelujah, Pillelujah.
What is that to the tune of?
engineers: "that's kinda like pi, 3!"
A few feet is no issue!
`3!`
Hmm, "Three factorial"?
(That's `27`!)
r/unexpectedfactorial? :wheeze:
timestamp: 15:30
@@Brahvim I’ve never looked at a comment and wanted to make a comment about how awful it was until now. I don’t care that it was over a year ago, that was one of the worst things that I have read in my entire life. Please, never let any words escape from your head again, whether verbal, digital, or pen and paper. Your thoughts do not deserve to be heard.
@@brando3465 _Thanks._ I've always talked to people about my UA-cam comments sounding cringe anyway. _Well this one was just stupid,_ and I'll have to make sure I make less of these.
UA-cam is _just not_ the place for me to do these things, maybe.
...Thanks.
It's amazing how accurate you got it!
Even having seen the 3blue1brown video, I was blown away by how the digits of Pi appeared, and the correct ones to boot! And all with so little code.
You could also use this way:
console. log(Math.PI);
Mahdi Nicoo that wouldnt be fun
@@andrewzhang8512 r/wozzles
@@andrewzhang8512 r/woooosh
This is frickin amazing :D Math and Computer Science are just so amazing! Happy Pi Day everyone
Agree !!! Pi is such a magical number , so mind bending where and how people come up with different ways to find it ! It's everywhere too !!
Happy Pi day ! :D
Knowing the velocity of both blocks, you could calculate the point in space and time where they collide. So you don't need time steps at all! (Except for animation purposes). If the time until collision is above say 1/60th of a second you could use a time step for animating. In fact that would give you a nice iterative formula for pi. (That would converge quite slowly!)
Yeah I didn't use time or distance at all in my program to count collisions.
It might seem like the small block could get crushed between the wall and big block if the big block is really big but I think what happens is there is trillions of small collisions that occur slowing the big block down enough so the crushing can't happen. At least in a mathematical model.
Man For this you deserve 3,141,592,653,589,793,238,462,643,383,279,502,884,197,169,399,375,105,820,974,944,592,307,816,406,286,208,998,628,034,825,342,117,067 subscribers.
And No I didn't copy-paste or see and type it. I remember 100 digits of PI using ASAP Science's song '100 digits of PI '!!
Oh god.
man i was feeling depression because i field to learn advanced javascript and u made me more interested in it u made me change my mind
26:52 I love the song, you should upload a video just with the song
I did this in processing myself and after 7 digits it was just too slow.. I can't believe it went till 9 digits at such a good speed. But it's super impressive. I love how we all enjoy coding mathematical ideas that just make programming fun😂❤️
Man, it's really cool you just see the physics through the math, like with hypothesising what the m=1 scenerio is. You're quite the polymath!
A Good way would be to calculate the "exact" collision point. Then you could calculate the amount of time that the small block needs to hit the wall, add v*time to both, calc exact collision point, repeat.
29:47 The difference between float/double and BigDecimal, as well as the difference between int/long and BigInteger, is that using primitive types, the JVM is allocating a chunk of memory just for that primitive type's previously-set boundary, while as a for BigInteger/BigDecimal, the JVM is directly using the memory to store the bytes, which naturally results in a bigger usage of memory for the application.
If you have a lot of RAM and you need high-precision for numbers, you can safely use BigInteger/BigDecimal. Just be careful not running into Infinite loops!
12:27
We can think of the wall as 256 high bedrock
That clack sound is the same as the clack that Clackers made, a toy from the late 60's that used to break kids wrists :) Good article on Wikipedia about them.
Super video!
Oh the concept is from 60s, I used to have one of those like almost 10 years ago
That want dark, very quickly.
What an amazing video as always! The video edition is every time getting better too. Great work!!! Thanks!!!
A podcast with Grant and Dan in it has the potential to break the Internet.
I loved that getting pi , and pi song and eating pi , thank you so much ❤❤❤
You can also simulate/calculate pi in different bases by adjusting the mass ratio between the blocks! You get pi in base ten if the ratio is 10^2^n, you can do binary with 2^2^n, hex with 16^2^n, etc. You have to convert from base 10 to the target base, of course.
Oddly enough, I actually did this a couple months ago! I coded the collision thingy! Neat
This is one of the best channel on UA-cam!
One of the most respected youtube channels.
You are amazing.
That rendition of Hallelujah was beautiful.
+3Blue1Brown needs to see this. Extremely laggy and inefficient, but extremely elegant.
Props to the editor on this one. This is my favorite episode!
Best PI day ever. Thank you so much dan!!!
It would be cool to see if you graph velocities like in the 3b1b video
I am liking the new editing style
The reason why Euler integration is normally approximate is because it assumes v to be constant throughout a time step, resulting in setting x += v, where in theory it should be x+= integral of v dt.
In this case the objects are moving conserving momentum, so v is a piecewise constant function and, as long as the time step is smaller than the smallest distance between two consecutive collisions, the algorithm will give exact results.
The most effective way to calculate Pi by far.
easter egg found:
the lenght of the video is 31:14, which is pi!
We have an anual competition at our college, where people recite the numbers of pie, last year a 12 year old girl recited over 900 decimal numbers
why does the visualization video of 3blue1brown is so smooth?
Well because its a visualisation Video ; ) maybe he pre calculated it so basically he rendered the video
@@philippg6023 Yes, he does prerender everything. It's a python library he wrote himself. I mean, why should he play it live? It's a video, after all, playing it live and recording it would be a waste of precision and smoothness.
Yup
It's MANIM. 😁
Mathematical Animation Engine written by Grant Sanderson.
You could make the number of time steps dependent on the distance to the wall. That would speed up the longer calculations significantly.
this is the coolest thing ive ever seen in my life
Thanks for blowing my mind with this fact all over again. :)
In the last few videos, your editing was so nice. If possible, please keep it up like this!
All your videos are awesome! But this one must be one of the coolest and funniest I've ever seen!
This is your best video. I love it.
I think that using the speed of both blocks after the last collision can bring more digits to pi ; possibly up to 8 digits for 64 bit double floating point. The slope of that line represent the best rational approximation to get a few more digits of pi.
The current code compute 10 digits of pi and double are 18 digits total.
One extra twist of optimization could be to avoid redrawing the cubes if they didn't move by a whole integer, which is one pixel. We expect no more than 1 order of magnitude improvement here.
This code reminds me the bresingham algorithm to draw circles using integers only.
30:10 For the optics method, the trick is to use complex numbers to represent the angles, rather than explicitly dealing with angles or relying on any kind of trig function.
Using the small angle approximation you can construct a complex number for a particular angle 𝜃 as just 1+𝜃i, and then n*𝜃 is (1+𝜃i)^n.
Here's a quick python implementation: ideone.com/T4UCnV
For the kinematics method, instead of a fixed timestep you can directly compute the time until the next collision as dt = (x1+w1-x2)/(v2-v1) and make that as one single step; then to animate it you can either interpolate between timesteps or you can have a separate fixed-timestep integration that you re-seed from the main integration at each collision. This also lets you play the clack sounds at a more granular time resolution rather than forcing it to be quantized to the animation framerate.
If you're interested I have a python implementation of this that works for an arbitrary number of blocks in an arbitrary number of dimensions, including an interpolation mechanism.
At this point I don't have anything for generating the actual animation, but I can at least plot graphs: gist.github.com/AJMansfield/00d69e1488c2b1eb56b8c4da2ca739dc
Alternately, you can even forego tracking the block positions altogether, since we already know what order the collisions happen in and the position doesn't figure into the momentum transfer equation.
If you take this route you can also simplify things even further and perform the momentum transfer as a single matrix multiply rather than as a number of separate steps.
Here's another quick python implementation of this method: ideone.com/jPBh8C
Wow, thanks for this thorough explanation and code samples! Much appreciated!
This is my favorite video you've done!
Nice hint with the video length (31:41)
And offcours awesome video as always I find it cool how you are so motivated and you actually made me want to learn a few digits of PI myself so I made an app that lets you train PI like a vocabulary trainer. I think you would like it
The song was the best thing ever, you should make an album!
Ok, so you were singing with the amazing grace melody. gotcha , divine number.
I watched the videos from 3blue1brown when they were released and I also absolutely fell in love with the clacking, hahaha! I like seeing I'm not the only weirdo in this world :3
The best crossover, EVER!
I was just about to do the same thing! Good work! Happy PI day!
I love the clacking too !
You make me feel happy. Thanks
when I study too much , I just take a break and watch your videos . Great work , you are making this world a better place by making silly mistakes ;)
Thank you for the serenade in pi, much appreciated.
AMAZING DEMONSTRATION!
This may be my favorite Pi video ever!
The man can code and serenade!
I just programmed it on my phone up to d=9, was a bit tricky to get right but not that bad...
Essentially the main part of code is:
public boolean iterate()
{
if(v1>0)
{
cols+=2;
double tempV1 = getNewV1();
double tempV2 = getNewV2();
v1 = tempV1;
v2 = -tempV2;
return true;
}
if(Math.abs(v2)>Math.abs(v1))
{
cols++;
double tempV1 = getNewV1();
double tempV2 = getNewV2();
v1 = tempV1;
v2 = -tempV2;
if(v2
so glad I am alive to see this
Dan, just precalculate the collision without simulating velocity in steps. All you really need to do is calculate the moment of the collisions, not what's in between
Your computer must be insane to be able to handle that whole thing in any reasonable amount of time.
What I thought about doing is: instead of doing a simulation that checks collision through coordinates, you could just evaluate whether the blocks will collide or not or if the smaller block will hit the wall, like so (block 1 is the smaller one, with speed v1 and block 2 is the bigger one, with speed v2):
if v1 > 0 and v1 < v2, the blocks will never collide again;
if v1 < v2, block 1 will hit the wall;
if neither is true, blocks 1 and 2 will collide with each other and change speeds based on the formula.
Based on this idea, I created a program in C++ that does exactly that, but by 11 digits the imprecision got too big and the results stopped matching :\
you could make the time steps increase proportionally to velocity and inversely to distance
close distance + high velocity = lots of tiny steps
large distance + low velocity = few large steps
I loved that video, glad you could remake it!
I programmed this algo right away after watching 3b1b video about it.
phantastic how this works. would be interesting how this correlates to a circle
Watch 3blue1brown’s video
You can speed up the calculations by a lot if you just set timeSteps to 6 ** (digits - 1), instead of 10 ** (digits - 1).
You won't miss any counts, I've tested it with 11, and it didn't miss a single number.
Very cool Daniel. Interesting the creativity that you have.
Your videos time also represent first 4 digit of pi😁😁😁.. love your video 🙌🙌🙌
Awesome Video man !
This guy belongs at NASA.
awsome as allways :) only thing missing is having the block scale based on their mass
The song is definitely hallelujah
is it coincidence that the length of the video is equal to the value of pi*10?
No
But pi*10 = 31.415926...? Length of video is 31:41.
pi*10^1 lol
Awesome name "collision clacking magic wonderfull thing!" , That's the coolest name ever!
Good stuff Mr Shiffman!
I really like 3blue1brown’s Collision Clacking Magic Wonderful Thing.
Click click bzzz weeeeuuuuuuueeeewwww bzz click click
The editing on this video is amazing !
amazing Π fun. I'd like ou to show basic workings for how physics formulas are derived. it's not that hard to run through conservation of momentum and energy quickly. years since I did it but we only had calculators and spreadsheets to do such models in those days!
cursed uppercase pi
This is awesome!
This guy is more of a comedian than a programmer
That pi song sounds oddly like that one "Hallelujah" song ...
Can we get a code based Ukulele album? I'll happily master it for you.
I think a better way to fix the precision issues would be to use a variable timestep. You can predict exactly when the next collision will be so you can be sure you get it right.
Yes, great suggestion!
This idea have been discussed in more detail in another comment trail. The two choices are skipping until close to collision then allow the current code to resume looping from 0 to 9 times to detect the collision and find the pi digit or go past collision and back track with a loop similar to the present code.
:D I tried to make this simulation when it came out and it it worked but was rly buggy because there box went on the the other side of the "wall" thing
Thank you so much :D
the video was fab and the song was terrifying 🤣😂
I watched the 3blue1brown vid and didn't get what they were were saying but maybe i get it now
Right as i saw the title i knew it was about 3blue1brown's vid
my first action after the video : editor.p5js.org/Auxence/sketches/sbDLdX_85
seriously I needed a second wall for endless clapping XD
Dan be like:
* clack *
*NOICE*
23:50 The face of pure surprise
I love it when you normalize the speed of the video just to make us listen your pi song hahdhahshhsjjsdjjdjd so nice
I created a third box with the same size as box2 and gave the x value to 1200. It gave me the digits of 2*pi :)
it would be cool if you would do the squares size to depend on its mass, so it would look realistic (it would look awful and probably crash the browser after 3 digits, but it would be entertaining anywyas)
Smallest the cube can be is 1 pixel to be visible. At 1000:1 the other cube would take entire screen of 1080p video :)1
Very nicely edited video
That was amazing
4:11 there is potential for a "Gods Plan" parody here
This was the first thing I ever programmed in Processing!