Any Plans for Liquids?

[Leadwerks]

Our new engine has a voxel raytracing system that gives fast reflections everywhere. Our new water system doesn't use any special reflection code, it just uses the same PBR reflections as every surface in the renderer. So we have the ability to make reflective water in any shape.

I was wondering what your thoughts are on liquid/gas simulations in the future, taking advantage of many-core CPUs? It seems like this might be more limited in scale but more accurate and useful than a GPU-based system?

[Julio Jerez]

Yes SPHD (smoth particles hydro dynamics) is a big plan fro newton 4

Now that we have a unified solver that and also spring bags particles seem the next step.

Part of the problem that remind with particle hydrodynamic are two cases.
1 like you said, since this is a volumetric problem it can only be limited to case that can be model with relatively small number of particle, stuff like spills which are surface cases, or small volumes like glass of water, bathtops, water tank, shallw rivers,, etc.
Stuck like river swimming pool, oceans, and other large volume I like to the people who sale hardware.

2 the surface reconstruction, is a huge problem, I will try to add a part le splatter first, and see how that works.

But yes, those effect are part of the plant.

[Leadwerks]

Sounds great. I am more interested in small physics puzzles with water. I don't think simulating a big body of water if important, because we have FFT waves for that that look good.

[Bird]

That's excellent news. I've been using Flex in my projects but it's no longer being developed. SplishSplash is another opensource SPH project
https://github.com/InteractiveComputerGraphics/SPlisHSPlasH

the surface reconstruction, is a huge problem,

I use Openvdb for that and it works great
https://www.youtube.com/watch?v=VqfG-TATGJE&ab_channel=HurleyworksInc

But even though it is highly multi-threaded, it can only generate a mesh from particles in real-time in for the simplest of simulations in my experience. Looks like NVIDIA is making a gpu version that should be much faster
https://developer.nvidia.com/blog/accelerating-openvdb-on-gpus-with-nanovdb/

[Leadwerks]

The visuals are probably something that goes on the game engine / renderer side. Looks like some interesting ideas.

[Julio Jerez]

yes the rendering, but the mesh reconstruction is a computation geometry problem.
doing with sprite Splatting is probably the easiest way, because with today hardware Geometry shaders are a given. however, with todays expected high quality rendering, sprite splatting isn't going to be accepted by people with high end GPUs.

the second method I am inclined to try is the marching cube or marching tetrahedra.
this is probably the method used by that paper posted by Bird.
I believe that for relatively small size of particles the method can be used in real time.
this method is probably more aligned with today rendering theniques and hardware including ray tracing because you get triangles meshes to draw.

I am also positive that since SPHD has so much correlation (meaning the position of one particle is predictable because if the previous position, that an increment algorism can be developed that build the mesh incrementally)
the Mesh reconstruction is by far mush harder than teh actual physicals simulation.

But the answers is yes, we are doing the SPHD simulation and the mesh reconstruction in that order, we leave the rendering to the graphics engine.

[Julio Jerez]

alright now that 4.00 is a some more or less stable point I will start adding the laminar fluid body
I better to start early so that we knwo hwo is going to couple with teh rest of teh engine.
and it is about time we add that kind of funtionality.

I am expecting to handle around 4 thousand particles in CPU in real time, which should be enough for a handling few small water or Gas system in an app.

4 thousand joints at an average of 16 pairs for calculating the incompressibility, density and viscosity
is about 64000 items, a modern cpu should handle even with one core.
so let us see what we get.

[Bird]

Great. I'm looking forward to trying it out!

[Leadwerks]

I believe Portal 2 used marching cubes:


Geometry shaders have performance problems, FYI, because they have to sync with the CPU, or something like that. If I have just a 3D grid of mesh IDs that would be fine.

[Julio Jerez]

I am not going to use geometry shader,
for now I will just use instancing for displaying the particles. and I will render them as small spheres.

later after all the physics is working, I will try the marching cube for visualization, but that will by optional, maybe a function BuildMesh or something like that.
this is how the interface looks so far.

Code: Select all

class ndBodyParticleSet: public ndBody
{
   public:
   D_NEWTON_API ndBodyParticleSet();
   D_NEWTON_API ndBodyParticleSet(const nd::TiXmlNode* const xmlNode, const dTree<const ndShape*, dUnsigned32>& shapesCache);
   D_NEWTON_API virtual ~ndBodyParticleSet ();

   D_NEWTON_API virtual ndBodyParticleSet* GetAsBodyParticleSet();
   D_NEWTON_API virtual void Save(nd::TiXmlElement* const rootNode, const char* const assetPath, dInt32 nodeid, const dTree<dUnsigned32, const ndShape*>& shapesCache) const;

   const dArray<dVector>& GetPositions() const ;

   D_NEWTON_API virtual void AddParticle(const dFloat32 mass, const dVector& position, const dVector& velocity) = 0;


you can see function const dArray<dVector>& GetPositions() const ;

that will be the set of particle that makes the fluid, and will be the minimal interface.
then teh othe funtion will be BuildMesh that create a mesh of point and normals using some surface reconstruction algorithm,

this is the base class for all particle effects, we will have springs for cloth, the fluids and probably the position base dynamics for soft bodies. and that will complete the set of particle effect for 4.00

[Julio Jerez]

I just added the instance rendering, and 8000 spheres are rendered at 200+ fps in my system.
but my GPU is Radeon rx480 not exactly at high end gpu.
is anyone try and let my know thsi will be a good metrics to see what we can expect.

It seem that in the end doing the marching cube may be a faster that rendering a bunch of spheres or sprites. although those spheres are very dense geometry.

anyway I am now ready to code the physics of the effect.

[Bird]

I'm seeing a little over 1100 fps

GPU: NVIDIA Geforce RTX 2070 Super 8GB
CPU: 8 core Intel i7-9700K@3.60GHz 32GB

[Julio Jerez]

ah very good, that encouraging.

as a test I change from sphere to a small box, and I get 1700 fps while teh spheres is 200+ for 8000 of them. this mean that yes makin the marching cube mesh is the way to go.

My hope is that we can do one or tow 4 to 8 thousand particles at in less than a millisecond in cpu,
so that is practical for usage.
well now on to the physics. simulation

[Bird]

well now on to the physics. simulation

Heh, that looks like a whole lot of scary math to me.
https://interactivecomputergraphics.github.io/SPH-Tutorial/pdf/SPH_Tutorial.pdf
https://interactivecomputergraphics.github.io/SPH-Tutorial/

[Leadwerks]

Our new engine can handle tens of millions of particles.