Snap-to-grid

What did you draw?
Post Reply
exfret
Posts: 585
Joined: Sun Jul 28, 2013 8:40 pm

Snap-to-grid

Post by exfret »

Why is the GSim so bad at setups involving snap-to-grid? This one disintegrates after about 2 rotations, even on a speed of 0.1:

Code: Select all

Gravity Fun at TestTubeGames.com: [ForceGr: r^-2,Qual: 1,Zoom: 1,xSet: 0,ySet: 0], [x0: -95,y0: 95,vx: 3.75,vy: 0,t0: 0,who: 2,m: 1000,c: 1], [x0: 0,y0: 95,vx: 0,vy: -3.75,t0: 0,who: 2,m: 1000,c: 1], [x0: 0,y0: 0,vx: -3.75,vy: 0,t0: 0,who: 2,m: 1000,c: 1], [x0: -95,y0: 0,vx: 0,vy: 3.75,t0: 0,who: 2,m: 1000,c: 1]
And in this one, the combined star goes of the four quickly goes to the bottom right:

Code: Select all

Gravity Fun at TestTubeGames.com: [ForceGr: r^-2,Qual: 1,Zoom: 1,xSet: 0,ySet: 0], [x0: 0,y0: 95,vx: 0,vy: 0,t0: 0,who: 2,m: 1000,c: 1], [x0: 95,y0: 95,vx: 0,vy: 0,t0: 0,who: 2,m: 1000,c: 1], [x0: 95,y0: 0,vx: 0,vy: 0,t0: 0,who: 2,m: 1000,c: 1], [x0: 0,y0: 0,vx: 0,vy: 0,t0: 0,who: 2,m: 1000,c: 1]
Why is this? Could it be something to do with snap-to-grid rounding? Why is it so consistently wrong? Also, I was having some problems with the saving. It seems that when things collide, the save code is only for the collided objects, not the objects that made the collision. For example, the 4-star collision's save code became this:

Code: Select all

Gravity Fun at TestTubeGames.com: [ForceGr: r^-2,Qual: 1,Zoom: 1,xSet: 0,ySet: 0], [x0: 46.50928,y0: 46.50928,vx: 4.862226,vy: -4.862226,t0: 19.63284,who: 2,m: 3000,c: 1]
I had to make set t0 as 0, because otherwise, the sim wouldn't put down the star because the time doesn't run when nothing's been put on the screen. I would suggest making loading codes different from making your own so that there can still be a delay from the start to when stuff happens. You should also be able to save the code at a specific time, so that you could give the initial parameters as well as the positions and what not of the objects right before the thing happens that you're showing off. That way, people don't have to wait for the thing you're showing them, but they can still see the initial configuration. About this code in particular, the fact that the star's mass is 3000 instead of 4000 seems to hint that the bottom right star wasn't included in the collision... I also tried it by putting the stars in their places in different orders, and it got different results, consistently... Also, here's the after-collision code for the spirally first save:

Code: Select all

Gravity Fun at TestTubeGames.com: [ForceGr: r^-2,Qual: 1,Zoom: 1,xSet: 0,ySet: 0], [x0: 0,y0: 0,vx: -3.75,vy: 0,t0: 0,who: 2,m: 1000,c: 1], [x0: 0,y0: 95,vx: 0,vy: -3.75,t0: 0,who: 2,m: 1000,c: 1], [x0: -24.88799,y0: 29.59021,vx: -1.319129,vy: -5.348654,t0: 240.473,who: 2,m: 2000,c: 1]
Of course, this leads to radically different save codes, as the merged star only appears at t=240.
Nobody ever notices my signature. ):
User avatar
testtubegames
Site Admin
Posts: 1148
Joined: Mon Nov 19, 2012 7:54 pm

Re: Snap-to-grid

Post by testtubegames »

Awesome run-down of some issues you encountered. I think there's a few things afoot here, and I don't think the snap-to-grid is responsible.

1. The first code you posted, with the four stars looping, does break down after a few cycles, but I think that's just a necessary instability. As in, the four stars are in a highly symmetric arrangement, but any small error would compound and lead them ever more off the symmetric course. And some amount of error is a necessary evil of doing simulations. You could up the quality, if you'd like. Instead of 40 calcs per frame, maybe do 200, see if that helps. You'll still have problems eventually, though.

2. The four stars *do* combine into one weird star heading off speedily. Yes, there is something wrong there -- and good eye noticing that the mass was 3000, not 4000. I think you're correct that something funky happened where that 4th star didn't really get added in. The density was also NaN, so there's definitely a bug. I'll track it down.

3. The issues of how load codes work. Right now, they just look at the current objects on the screen. So it's funky with collisions, or objects that are deleted/destroyed. I would like to improve how the codes work, so they aren't so simplistic in that way. Also, it might be nice to set the world time (upon loading) not to zero, but to earliest-time-of-object-drawn minus ten. So if you go back in time and draw objects, the load code won't ignore those. And that'll give you a moment of time before things appear.
Post Reply