Create simplified scene for Sibernetic that runs faster

[slarson]

Should run 10x faster.

cc: @lungd @raminmh

[a-palyanov]

Worm body is composed of about 20 000 particles (13381 elastic particles + 7052 inner liquid particles), whereas for swimming/crawling it is necessary simulate about 300 000 ... 500 000 particles of the environment as well.
On my PC (Intel Core i5-2500K + Radeon R290X GPU) the following computational performance is obtained:

1. worm + liquid (13381 elastic particles + 491127 liquid particles), visualization of all particles and elastic connections between them: FPS = 1.46
2. worm + liquid (13381 elastic particles + 491127 liquid particles), visualization of only worm body elastic particles and liquid particles which contacted worm body: FPS = 2.60
3. worm only (13381 elastic particles + 7052 liquid particles), visualization of all particles and elastic connections between them: FPS = 7.67
4. worm only (13381 elastic particles + 7052 liquid particles), visualization of only worm body elastic particles and liquid particles which contacted worm body: FPS = 21.38 (!)

All mentioned cases are illustrated below with corresponding screenshots.

[a-palyanov]

Even better result is expected when visualization is completely switched off during simulation (just use Sibernetic with additional command line parameter "-no_g").
Simplified scene configuration file which contains worm body only is available here:
https://github.com/openworm/sibernetic/tree/development/configuration/worm_no_water
(old variant)
https://github.com/openworm/sibernetic/tree/development/configuration/worm_no_water_2017.rar
(new variant with improved "muscle cells" geometry)

[cheelee]

I know from molecular dynamics simulations they are able to use implicit solvent models to simplify and speed up computation. Can similar implicit (uniform) environment models be deployed for some of the constrained physical simulations Sibernetic uses?

[pgleeson]

@a-palyanov I've tried the worm_no_water configuration here and it works fine. Short (10ms) simulations with sibernetic & c302 have gone from 214 sec to 68 seconds (also with a bit of a speedup from specifying device=gpu).

Options for changing the device & configuration (worm_deep_water should work too) have been added to sibernetic_c302.py

[nmsutton]

@slarson , @a-palyanov , @cheelee , Something relevant to this effort (in case anyone wasn’t aware of the work) is that I created code and subsequently a pull request for a way to generate simpler scenes using sibernetic’s scene creator: pull request link. In the sample scene I included in the pull request on my pc it accelerates rendering from 4fps to 30fps or 60fps (depending on computing neural signals at the time or not, etc.). To create the simpler scene modeling in blender was used but I provided instructions for people to do that here: doc link. From what I recall the movement data needed to be remapped to different muscle vertices in the simpler model but I was able to get it in a crawling motion: movement video . I successfully got working a different way of generating movement that receives input directly from neural signals: neural movement work . Hopefully this is useful toward Slarson’s goal, I will work on it if I have time but I have been working on a different project recently, if anyone wants to use or advance the code I can answer questions though.

[slarson]

@nmsutton This looks great. Have you joined us on Slack yet? If not, you can find the invite after filling out the form here

It would be great to discuss further over there.

@a-palyanov what do you think about this progress by @nmsutton ?

[nmsutton]

@slarson Thanks for the compliment! I have now joined the slack group, where should I go to discuss things in there?

[a-palyanov]

About movement video: actually looks not very similar to crawling :)
And probably there is a problem with springs stiffness value.
My initial worm body model, in which worm body was represented by 200 layers of particles in head-to-tail direction, was almost perfect for smooth realistic swimming and crawling simulation, but it was too slow (about 2-3 fps).
Next one, with half resolution (100 layers instead of 200) was much faster (30 fps), but already not so smooth and nice.
I also tried 1/4 resolution (50 layers), and found that it is not satisfactory for practical use, although it is very fast. It looked somewhat similar to this movement video.
Looks like good particle-based models need to be represented by enough amount of particles to work properly.

[nmsutton]

@a-palyanov, thank you for the feedback. The crawling-type movement in the video is simplified (lacking some realism) for one reason that it was a basic test of accessing the muscle verticies. As seen the whole muscle groups (left or right side) are moved up and down the same, it was only meant to be a basic movement test but programming more detail into the movement can add realism. I will respond further in the slack group as was recommended by @slarson instead of commenting more on github here. Other people can add github comments if wanted though.