Loading...
Logo
Processing Forum
Hello!
Long time reader, first time poster. hah!

I am working on a Processing Genetic Algorithm applet, which uses Fisica to run simulations.

Since a Genetic Algorithm requires that results be reproducible (otherwise offspring will not reflect their parents successes), I am needing Fisica to produce the same results given the same context and set of parameters.

My research has shown me that Box2d is deterministic (should be reproducible), but not if the timeStep is linked to a variable frameRate .. as Processing's draw() function is.

This issue is addressed in many articles (eg.  UNA games - Fixed Time Step), but I don't seem to be able (with a limited knowledge of other languages) to be able to port their methods to Processing.

You can see a simple simulator I've created here -  A Simple Simulator .. (click to reset bricks) .. but every click produces different, though similar results.

Can anyone guide me to a solution?

Thanks in advance,
Leif

Replies(4)

Let me at least report that I tried some stuff and can only confirm your point. Hmm, hadn't used Fisica before, but you would say that they would build determinism in Box2D to begin with? Guess not. While some code is pretty easy to translate between languages, that code you link to doesn't seem so easy to transfer. Perhaps someone with knowledge of C++ can take a stab at it.
Well -- I seem to have solved my problem.
.. and perhaps Fisica does manage it (to a degree).

I implemented a timeStep accumulator, using this (very helpful) tutorial :  http://gafferongames.com/game-physics/fix-your-timestep/ -- but found it DIDN'T solve the problem.

Yet, I noticed that everytime I ran the applet, the first simulation resulted exactly the same (as previous first simulations), though successive simulations in the same test diverged. hmmm.. 

So --  in between simulations, I created a new instance of the World class (removing the old one), and reinitialized Fisica entirely. (instead of simply removing all geometry, then placing new geometry in the exact same origin positions (w/ same origin forces)).

For some reason this works -- and I don't need the accumulator code at all.

I'm still not sure why calling World.clear(), and then placing new geometry in exactly the same context again doesn't produce the same results -- but still I am happy that I found a workaround.

Hope this helps someone.
L

Well -- Looks like I was happy too soon.

It seems that reinitializing the Fisica World again and again quickly gets me an : OutOfMemoryError.

I had figured that if I assigned a new class with the same name, it would overwrite (or simply free up) the old memory.
Isn't this the case?

draw(){
      world = new FWorld();
      < .. do stuff.. >
      world = new FWorld();
}

Wouldn't the memory used by the first 'world' be freed up when I assign it the second time?

Is there any way to force garbage collection on this? I imagine some part of the Fisica library is keeping a reference to each new FWorld I create, and thus it sticks in memory.

Any help would be appreciated,
Leif



I can't comment on Fisica as I haven't tried it. But your analysis seems correct. Either a reference of the old world remains somewhere, in which case the library should be fixed, not much can be done on the user side (but check if you haven't missed some closing API), or for some reason the memory isn't freed immediately. I don't know why this can happen, but it seems somebody else had a similar problem and had to free memory regularly: https://forum.processing.org/topic/memory-management