Structures Preview | Deformable & Liquid Voxel Physics 

There are elastic forces that help keep the shape, either from the stress tensor or springs. The particles are advected with the grid velocity. If you use density summation the rest density should be the initial density. For elastics it also helps to have more particles per cell so that it has adequate resolution when stretched.

@@GrantKot so the forces keeping the particles together are separate from the actual mpm simulation? because something i noticed is that the ship seems to be divided into small chunks and those chunks move but the particles within those chunks seem to be attached to those chunks. so like, the forces on the particles move the chunk and that chunk moves the particles?

Yeah, here it's based on shape matching. Take a look at Matthias Muller's publication list. Basically first the particles are advected (G2P), then the shape matching clusters calculate forces that the particles scatter to the grid (P2G). Then I also have the viscoelastic model which each particle keeps track of its local deformation and generates elastic forces.

It would be a similar concept to the multigrid pressure. Currently I have particles that can keep track of their deformation gradient and fracture but the stiffest it can get is very soft jelly. The clusters give a coarser resolution mesh that can be operated on and makes it easier to get stiffer objects.

At this stage, mostly just rendering cube per particle. The chunking system on the CPU worked well to keep them rendering from front to back to allow the GPU to use early-z testing. Later on, used DDA/Amanatides to march through voxels.

Base MPM is a bit sticky because everything is handled on the same grid. There is an extension called Compatible Particle In Cell that I will try out. Currently my main focus is to get the general data into shape so I can improve the renderer, eg be able to sort objects front to back, keep track of voxel colors.

Hi, yeah, it's not really active anymore. If you want you could ask some questions here as well.

@@GrantKot Well, basically, I have only two concerns right now. The first one being the grid approach. I've tried allocating static 3d grid but that turned out to have it's own limitations like 1) allocating memory for an empty space 2) boundaries being strict. Using dynamic grid boundaries solves the second limitation, but the first one still remains. So I switched to using a fast hashmap, which leads to losing some fps, however gets rid of allocating memory for an empty spaces. My goal is to make the simulation boundless and keep a reasonable framerate. What approach would you recommend to use? / Or which one you use? Perhaps there is a library for sparse grids or whatever?

@@GrantKot The second concern is about collisions. I can't wrap my head around the grid collisions. In your previous demo showcase, your viscoelastics slide off the "toilets" and other obsticles. The best I could achieve with grid collisions is when particles just stick to the grid, which is basically multiplying the velocity and mass of the cell by 0, reminding more of your temple demo. Do you raytrace for the collisions or is there a simple trick I'm missing?

@@PchlaPddy I think there is the Taichi library which might have some sparse grid stuff. Do you sort your particles to tiles? This can make sure you don't have too much overhead with the hashmap. Especially if you also do grid tiles. I just use distance field to handle collisions between particle and blocks.

@@GrantKot No, I don't sort them to tiles. And yes, I have quite the overhead for using the hashmap, it's the most inefficient part of my code in fact. Is there an article about sorting particles to tiles? I don't think I get the overall idea of this. Anyways, do you think using hashmap is a good idea? I've tested that fps drop is not too significant for the benefits it brings, around 20% in my tests.

Yeah, I've been thinking about it, maybe once I get the voxel colors working for static and dynamic structures.