So, here’s the idea: essentially, I’ll be trying to evolve creatures to perform certain tasks like walking, jumping, or swimming. These creatures will be evolved in a 3d world with physics to hopefully produce creatures that move somewhat like those found in the real world.
This idea was inspired by Karl Sims’ similar project, “Evolved Virtual Creatures.” After reading his paper on the subject, I’ve come out with a few ideas on how mine might work. First of all, I will likely be using an evolutionary algorithm to “teach” my creatures instead of a deep learning algorithm. In this context, I think this will provide some pretty large benefits, including being able to mutate the creatures’ physical structure instead of just its nervous system. Other than the basic genetic algorithm, I’ve also been looking into an algorithm known as NEAT (NeuroEvolution of Augmenting Topologies) which could produce some good results.
So far, I’ve began prototyping a physics engine in 2d using soft body dynamics (found here). This is different from what Karl Sims used (rigid body dynamics), but I think it will produce some pretty amusing results nonetheless. Unfortunately, this approach is beginning to present some issues. Most notably, the physics engine can be unstable at times. Luckily, I do think I might have a solution to this.
A soft body is comprised of point masses and springs. Gravity, collision logic, and any other forces are applied to each of the point masses, while springs ensure that the body retains its shape by trying to keep its two end points (which are themselves point masses) at a set distance apart. The problem arises because any simulation is not continuous, meaning it is broken up into certain steps. In my case, the size of these steps are determined by the frame rate. So, if a spring becomes too stretched or compressed in a single frame (or time step), it might try to exert a massive force in the opposite direction in an effort to correct the distance, but overshoot and cause a chain reaction that blows up the simulation. The solution to this problem is to check if the simulation will blow up in the next frame (using the Courant condition), and add more frames if it will. Obviously there’s a bit more to it, but that’s the general idea.