Same person that wrote gitlet[1], as seen on HN a few weeks ago. Personally I'm extremely happy to see HN so supportive of well commented and documented code.
Annotated code: Circles bouncing off lines
51–60 of 70 posts
Re: Annotated code: Circles bouncing off lines
#52Nice code. Thank you. Are those ball-to-line collisions energy preserving? I believe they are... However it seems there might be an edge case, where moving a colliding circle until it no longer intersects the line, might cause it to skip past another line. Because of this, the lines should not intersect each other. Sorry to ramble but I love this sort of stuff. Collision detection is covered well in many game develop…
circle.velocity.x -= 2 * dot * bounceLineNormal.x;
circle.velocity.y -= 2 * dot * bounceLineNormal.y;
The collisions currently reverse the velocity of the circle relative to the line by subtracting to cancel and then subtracting again to negate.
I found a slightly nicer-looking effect can be gained by making the factor ~1.8 to simulate 20% energy loss in collisions.
Obviously, any magic numbers in the code are not relevant for its purpose of demonstrating a simple mathematical concept in a literary style. I'd love to see more examples of this kind around HN as it's a quick way to learn/refresh the odd concept.
Re: Annotated code: Circles bouncing off lines
#53Reminds me of a simple physics system I wrote a couple of years ago [0]. After writing a cloth simulation [1] I figured that all I needed to make them into collidable boxes was to have each dot collide with each line. I went in very very small steps, iterating each thing to ensure I understood it. The code was super verbose and I learned a lot from this about linear algebra, cross products, vector projection etc. I a…
The tearing is awesome, haven't seen that before in cloth simulations.
Re: Annotated code: Circles bouncing off lines
#54I don't know if the OP reads this, but one very minor note about the core of the update loop. From the POV of the circles, it is effectively:
for each circle:
if circle is penetrating:
apply collision impulse
remove penetration
integrate forces (gravity) to update velocity
integrate velocity to update position
for each circle:
render circle
For this case, the effect of this is probably invisible (I couldn't see it). With slower moving objects, higher gravity, or less elastic collisions, this can cause objects to 'sag' or appear springy. A simple change in order helps:
for each circle:
integrate forces (gravity) to update velocity
integrate velocity to update position
if circle is penetrating:
apply collision impulse
remove penetration
for each circle:
render circle
Re: Annotated code: Circles bouncing off lines
#55Earlier quoted context omitted.
I wonder if the weaving in literate code is one of the things that could only have been invented to deal with Pascal. It is useful to be able to rearrange the presentation even in JavaScript, but I doubt it would be enough of a pain point for people to invent weaving in an alternate history were literate programming was born on more flexible languages.
I wrote a literate-programming compiler to deal with JavaScript programming (any language works, but js is the one I use the most); it use markdown as the language in which the code is embedded. For me, prototype setup and async stuff seemed to naturally lead me to want to differ in the ordering between how I write and how the program is laid out. I find it quite liberating to not care what order I write the code in,…
The weaving steps seems especially useful for web programming, because of the different languages. For the narrative, you could show HTML, Javascript, CSS, and Python backend code mixed together. The weaving puts them all into separate files for execution.
Re: Annotated code: Circles bouncing off lines
#56I don't know if the OP reads this, but one very minor note about the core of the update loop. From the POV of the circles, it is effectively: for each circle: if circle is penetrating: apply collision impulse remove penetration integrate forces (gravity) to update velocity integrate velocity to update position for each circle: render circle Because interpenetration is resolved before integration, the integration step…
I do not understand. Since this is executed in a loop, for the circle it looks like ...-penetration-integration-penetration-integration-penetration-integration-... in either version. Why does it matter between which steps the circle is rendered?
Re: Annotated code: Circles bouncing off lines
#57I don't know if the OP reads this, but one very minor note about the core of the update loop. From the POV of the circles, it is effectively: for each circle: if circle is penetrating: apply collision impulse remove penetration integrate forces (gravity) to update velocity integrate velocity to update position for each circle: render circle Because interpenetration is resolved before integration, the integration step…
I do not understand. Since this is executed in a loop, for the circle it looks like ...-penetration-integration-penetration-integration-penetration-integration-... in either version. Why does it matter between which steps the circle is rendered?
(Edit: I can be clearer, using your approach - more verbose explanation trimmed)
In the linked version we are doing
... move, draw, de-overlap, move, draw, de-overlap ...
So the move might cause an overlap, which we'd draw on screen. Having objects routinely interpenetrating a little (by a frame's worth) can appear springy, as if they aren't made of rigid material.
Better would be
... move, de-overlap, draw, move, de-overlap, draw ...
Re: Annotated code: Circles bouncing off lines
#58I don't know if the OP reads this, but one very minor note about the core of the update loop. From the POV of the circles, it is effectively: for each circle: if circle is penetrating: apply collision impulse remove penetration integrate forces (gravity) to update velocity integrate velocity to update position for each circle: render circle Because interpenetration is resolved before integration, the integration step…
I do not understand. Since this is executed in a loop, for the circle it looks like ...-penetration-integration-penetration-integration-penetration-integration-... in either version. Why does it matter between which steps the circle is rendered?
In the original version it's possible that a penetrating object gets drawn, in the modified version penetrating objects are always resolved before the drawing happens.
Re: Annotated code: Circles bouncing off lines
#59Reminds me of a simple physics system I wrote a couple of years ago [0]. After writing a cloth simulation [1] I figured that all I needed to make them into collidable boxes was to have each dot collide with each line. I went in very very small steps, iterating each thing to ensure I understood it. The code was super verbose and I learned a lot from this about linear algebra, cross products, vector projection etc. I a…
The tearing is awesome, haven't seen that before in cloth simulations.
Thanks. If you find it enjoyable to watch I'd recommend you to do a youtube search because there's actually a lot of it.
As for the implementation, it is extremely simple. For anyone interested just do a search for "verlet cloth".
EDIT: I'd specifically recommend this one [0]. It looks quite simpler than many on youtube but it feels more real.
Re: Annotated code: Circles bouncing off lines
#60I did the same thing a few years ago (scroll down past the tutorial/examples for the annotated code)
http://sparecycles.github.io/litijs?template
(but litijs itself is an undocumented hack) http://sparecycles.github.io/litijs?litijs