search

RoboticSwarmControl / SwarmControlRedux

This is the Node reimplementation of the SwarmControl website.
MIT License
2 stars 1 forks source link

Check performance on 'varying position' game #20

Open crertel opened 8 years ago

crertel commented 8 years ago

From Aaron:

http://swarmcontrolredux.herokuapp.com/games/varying-number

This game froze on me with 491 robots. That is odd because on the old website (http://www.swarmcontrol.net/task/maze_positioning) with 481 robot the game play is fine. On the new one:

- With 412 robots, it the lag is annoying
- With 362 robot the game play is fine 402 the lag was also terrible 260 fine
crertel commented 7 years ago

Tested with step size 60 hz, velocity iterations 8, position iterations 3.

This seems to be choppy with 371.

(probably read this before the following)

When we switch back to using a fixed timestep for the physics simulation, it runs "correctly". That is to say, a fixed amount of progress is made as quickly or as slowly as the browser can draw. The method I'd settled on from the article linked above is the more accurate one, decoupling the rendering framerate from the physics simulation.

So, in the current (fixed) case, if rendering a frame takes 100msecs and we've picked 100hz as the update for physics, the solver will run 10 times. That works, but also means that chugging occurs.

If we decrease the number of solver iteartions for the velocity and position, that helps a bit, but I think that the sheer number of bodies colliding (>400) is the source of the lag. Fiddling with the timestep size that gets used (the 100hz figure in the previous example, though we use 60hz in the simulation) somewhat helps, but again it's hit or miss.

I'm happy to return the solver back to its previous behavior, but I think doing so is not good methodology. Maybe we should just limit the number of robots?

crertel commented 7 years ago

What do you think @aabecker?

aabecker commented 7 years ago

The ideal solution greadually slows simulation time if the users computer is slow.

Aaron T. Becker

Assistant Professor of Electrical & Computer Engineering, University of Houston youtube.com/aabecker5/

On Mon, Nov 21, 2016 at 5:56 PM, crertel notifications@github.com wrote:

What do you think @aabecker https://github.com/aabecker?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/RoboticSwarmControl/SwarmControlRedux/issues/20#issuecomment-262094145, or mute the thread https://github.com/notifications/unsubscribe-auth/AEGkJCAldmRzOjNNYtFZrF3iJuqLGDolks5rAiGbgaJpZM4Kcr3i .