Weird Example in Processing

milanow

Hey guys, I found something really really weird. I really cannot figure out how this happened.

Not sure if you have seen "the Nature of Code". You can check the link below, http://natureofcode.com/book/chapter-2-forces/ And trace to "Chapter 2.5 - example 2.2", you will see how an ellipse move affected by a constant acceleration (wind+gravity).

Here is the problem, why these ellipse move lower and lower after bouncing in the window? It's not in real life, it's a program. This code there only changes the direction of velocity by code if(location.x > width){ velocity.x*=-1;}. So actually it doesn't lose any "energy".

Actually same problem happened in x-axis, you could find out these balls can never return back to x-value of 0.

Please help me out.

TfGuy44

Is the actual code for that example anywhere? It's likely that there is some dampening in the actual code, or the ball might be losing some force due to rounding, or changing directions past the screen edge.

milanow

link here, https://github.com/shiffman/The-Nature-of-Code-Examples/tree/master/chp02_forces/NOC_2_2_forces_many

Theoretically, all of these ellipse have the "ability" to come back to x or y value of 0 at times. But as you may see, they never did except one ellipse among them, it could bounce back to y-value of zero every time.

milanow

Okay I got it. yeah I do. It does lose some velocity when checking edges.

koogs

It does lose some velocity when check edges.

no, it loses velocity all the time because of the two forces being applied, the wind and the gravity.

there'll be code somewhere that does velocity = velocity + acceleration and then somewhere else that does position = position + velocity

koogs

it says as much in section 2.3 of the linked book

milanow

@koogs Just ignore the wind (wind = 0) the ball would be still bounce lower and lower.

The problem happens in the "checkEdge()" function. Ellipse's location.y would exceed/be larger than height. Even though the gravity equals like 0.2 for example, the velocity.y would go up to 0.2, 0.4,..., 22.4, ... so supposing that height equals 600, location.y at last frame is 560, and the velocity.y is 46.6, next frame the location.y would be 606.6 > 600. As the code wrote, when location.y > height, location.y = height. Thus to say, the velocity.y as a scalar loses velocity of 6.6 in every bouncing.

koogs

the ball would bounce lower and lower BECAUSE OF THE GRAVITY even without that sloppy coding that you describe.

(which, btw, would help it bounce higher - if it starts moving upwards from 600 rather than moving upwards from 606.6 then it has a 6 pixel gain, not a loss. velocity is reversed but otherwise uneffected)

Chrisir

**1. **

remark

    if(location.x > width)
          { velocity.x*=-1;}

this has a flaw when it stays in the zone > width it can lead to stuttering (going neg, pos, neg.....)

better:

if(location.x > width)
          { velocity.x =- abs (velocity.x); }

(always neg)

**2. **

when it comes to very small units and the ball should stop moving you can stop it hard:

if (abs(velocity.x) < 0.01) { 
    velocity.x = 0.0;   
    pos.x = 0; 
}

milanow

@koogs Yes I got u

milanow

@Chrisir True