Collision free instance painting

[JoeJ]

no, in each dimension is encoded with 14 bits, that 16384

Ok, that's big.
But i could not believe it, because 16384^3 = 4GB of RAM, if each cell would be only one byte.
Thus my confusion.
You would need something like a sparse grid,
or hashed grid (reusing grid cells for multiple world positions),
or no grid at all (e.g. sorting particles by morton code and searching them by that).

So how the hell can you have a grid that large?

Btw, I realized my proposal about a scrolling grid isn't as easy as thought. Probably is was thinking about a simulation based on euler grids, where adding space at the boundary is trivial. But with particles it's not and would be probably too expensive to be practical.

[Julio Jerez]

Again that not the number of cells, it the space a cell can be in grid cordinates.

I notice a very weird behavior, the particles tend to move in one direction.

It seems that the calculation of the neighbor is skewed to one direction.

For example. Say a particle of fluid is deep submerge in the fluid.

In this case the pressure gradient should be zero according to fluid mechanics.

When using sph, the particle is surrounded by a kernel of some radius.

The Kernel can only cover a finite number of particles,

If the number is evenly distributed, on average the pressure gradient should be zero.

But since that number is discrete, it is not zero, there is alway a residual pressure value.

This is not a bug of mine, this is an intrinsic problem with SPH algorithm.
The way is get resolved is that, instantaneously the pressure is not zero, this cause a particle to have some small residual pressure that moves it in the direction of the gradient.

But as the particle moves, it them capture, a different set of neighbors and this time the pressure gradient point in different direction. So on average over time the pressure gradient is zero.

But the result is a small jitter in the motion.

The only way to fix that is by having a kernel big enoght to cover a large number of neighbors.

In my case, since I am moving the origin to the location of ther aabb, the cause the number of neighbors to always be skew in one direction.
I have to diuretics the aabb so tha it can only be at interge og the cell size, but I try twice fail miserably.

Over the weekend, I will make break the problem in two parts, the part that calculate the neighbors and the part that calculat the physics.

The I will write a naive method for getting the newborn so that I can debug the physics.
Them afte the physic is solved, I will go back to the fast way of calculating the neighbors, using the naive as the base line.

[Julio Jerez]

ah, what do I know, I just added that quick check to make sure that aabb is quantized to integer multiple of the grid size. and the behavior is much nicer.
before I was using this

Code: Select all

   ndVector grid(gridSize);
   ndVector invGrid(ndFloat32 (1.0f) / gridSize);

   box.m_min -= gridSize;
   box.m_max = ndVector(box.m_min + grid * (invGrid * (box.m_max - box.m_min)).Floor() + grid + grid);

   m_box0 = box.m_min & ndVector::m_triplexMask;
   m_box1 = box.m_max & ndVector::m_triplexMask;


now using the code below, make the particle spread go a lot more even in all directions.

Code: Select all

   // add one grid padding to the aabb
   box.m_min -= grid;
   box.m_max += (grid + grid);

   // quantize the aabb to integers of the gird size
   box.m_min = grid * (box.m_min * invGrid).Floor();
   box.m_max = grid * (box.m_max * invGrid).Floor();

   // make sure the w component is zero.
   m_box0 = box.m_min & ndVector::m_triplexMask;
   m_box1 = box.m_max & ndVector::m_triplexMask;


if you sync and try again you will see that the big block of particle falls and spread much nicer that before, even the particles at the boundaries get a symmetric acceleration and the splash is more or less rounds. that's a good sign.

It keeps spreading evenly for a while, until those lithe small error do cause the symmetry to break down. but that I believe is the nature of the intrinsic error in the SPH algorithm.

hey that remind me of the big bang, those error in the beginning creep up and cause an even distribution but not quite even. It makes one wonder if the error is in the math used but cosmologist. but I digress.

anyway, with this I will continue to make the visual representation.

[JoeJ]

hey that remind me of the big bang, those error in the beginning creep up and cause an even distribution but not quite even. It makes one wonder if the error is in the math used but cosmologist. but I digress.

It seems work on fluid simulation is a very inspirational source to tackle deep physical / philosophical questions.
It gave me ideas of how life might evolve, how growth works, how mountains may shape, and such stuff

For the SPH problem, i use some falloff so particles coming into kernel range have a weight of zero at the boundary of the spherical range. But i guess that's standard and you have this too. I only use SPH to keep particles in a poisson sampled distribution. So it's resolving collisions, and i do this only in a position correction manner not effecting velocities.
But MPM has it's own issues with a kind of jitter. Sometimes almost isolated particles act totally weird. I guess that's because the velocity field they sample is weakly defined due to very small masses in the neighborhood.

But i don't think fluid needs to be accurate like rigid bodies. The proper compromise between performance and accuracy might be very different for a start.

[Julio Jerez]

Well the reason I say the big bang thing is because all of the simulations of the expansion of the universe, are base on using SPH.
The method was invented in the late 70' by a dude from the Ran corporation name Joseph Managham, fir simulation of nuclear explosion, galaxies simulation, and other astrophysics problems.

This is a statistical method, and I really question the accuracy of those kernels fir such large scale problems.

Before that the method was lagragian and central value transform which is theoretically accurate but it a hard problem for computers.

Another analogy, is the difference between polls and elections.
In general pools are accurate with a margin of errors, but they can be manipulated, skew, and jus be Influency by misinformation.

So after seen how eassy the accuracy of sph fir fluid is not accurate at all, I really question all those documentaries about super nova explosions, galaxies motions or even the expansion. It just happen that they suspetiosllu math the observation using sph, but they fail when using more rigorous lagragian or hamiltonian method.
My guess is that they fudge the kernels to make the simulatio match observations.
But it beg the question, what if the observations are wrong?

That's call postdoc rationalization, and the science Channels are full of that *.

But in any case fur us sph is a good thing to exploit, and there are many different solvers for different type of problems that we can exploit.

[Julio Jerez]

hey Joe or Bird, I now found the last bug, and the patch of particles spread perfectly smooth on the floor. it is a little faster too.
I think with this, I will now move to the visual representation this weekend.
I think I have some bug there, but nothing special.

if any of you sync and test it, you can look for this

ndInt32 particleCountPerAxis = 64;
//ndInt32 particleCountPerAxis = 40;

and try different settings, 64 will make a 64 x 64 x 64 (262k) particles, and I get about for 50 to 60 ms simulation time with four threads, that's the worst case.

Untitled.png (292.08 KiB) Viewed 4925 times

if you test please let me know what numbers you get.
notice that now all the particles remain together, and the patch is spread uniform which is what we expect.

[Bird]

Looking good here

256k particles runs around 25-35 ms
64k particles runs around 7 ms

That's with 8 worker threads.

[Julio Jerez]

nice,
if 64k take 7 ms and 260k take 35,
it is an indication that the cost is better than linear with, since the cost of 260k should be 56 ms.

I'd like those numbers Bird.

anyway this weekend I will write a splat shader, because is hard to calibrate the iso surface not knowing how close the particles are.

there is a clustering issue with the iso surface that has to be resolved.

[JoeJ]

anyway this weekend I will write a splat shader

Personally i visualize using point splats too. I use iso surface only to do further processing on the results.
Point splats are good to track each particle and give better feedback on eventual bugs or bad behavior.

But i propose you add more information to the color, so you can see individual particles not just a blob of equal color.
I use the mass gradient to get a shading normal, and have some simple direct lighting effect based on dot product with some hard coded global light direction. I also use negative product to make the color darker.
That's pretty good feedback already.
I also use curvature, which gives an effect very similar to Ambient Occlusion, and amplyfies the shape.

The cost of this can be quite high ofc., but it's worth it.

[Julio Jerez]

yes I will write a simple sphere shade that draw a ball from a quad so that I can check the sph physics, the point draw is not really correct because the points are 4 pixels size independent of the distance to the camera. but I wrote it like that intentionally because that function is a debug function to see contacts. Not doing it like that, and the contact far away because invisible because of the z buffer fight.

anyway, I now try to complete the iso surface and I found the first problem.
the function was very fast as long as there are many interion points that get rejected.
but as soon as the particles stat to move, now the surface goes from few thousand triangles to hundreds of thousands. that makes sense, for example a 40 x 40 x 40 point is 64 k points,
if the positions are close together, the mesh only covers the surface area, but of the point are all fart apart, now each point made 8 triangles, and that 64k * 8 = 0.5 million triangles.
that quite a hefty amount of data for a single core.

so I guess that form here, the best hope, is make the background thread multicore, and also OpenCL,

I realize that it is not reasonably to expect that real time performance for in a single core for data set approaching a million elements.

that seem like a real big problem, that can Onel be solve by adding more threads.
however, I took a look and the thing to my surprise that part that takes the most time is not making the surface but converting the vertex list to a triangle list.
I made a test that randomize the position so that it generates one of the worst-case mesh like the one below

suspension.png (766.76 KiB) Viewed 4893 times

as you can, see it takes for 24 to 26 ms just to make that mesh. the triangles list cone at about 600 k vertices.

so OI modify the iso surface so that is generate just the vertex list only, then I added a function that is called after the surface is produce, it makes the index list, and this is the result.

Untitled.png (387.37 KiB) Viewed 4893 times

as you can see in 10 ms faster, but it is flat shaded.

The good news, is that generation the vertex list is still under 16 ms, which means that we can be delegated it to a background thread, and if we make the background thread to have a thread pool, then that time can be cut to probable 7 to nine ms, which is on target

anyway, before I go back to the simulation, I will make the background thread use a thread pool, and parallelize the iso surface generator.

[Bird]

I made a simulation with 78,000 particles using NIVIDA's GPU based Flex. Physics time was just about the same as Newton at 8 ms per frame. Just to be clear there's no surfacing going on. Those are just intersecting spheres being rendered.

https://youtu.be/SxrRy7KnuKs

[Julio Jerez]

Oh, so that's good information to know.

I think I am going to stop the surface for a while until we get the physics going. The we can resume the surfacing

There are many tecnique that people has develop over the years, based of sphere splat.

I will make that basic shader. And them see what comes net.

In that video if the have 78k particle, that come to a surprise to me. It was my impression they where on the order on millions, of particles.

But anyway, if that is the case we could probably be in the ballpark. But in cpu.

The one thing I do not like about the nvidia people about the way they do the physics, is that the are full invested on that position base physic, which is not physic, it is simply a glorified least square optimization.

They do very well, but that stuff can only be used for stylized demos, I what to go, for the secund order equation.

But anyway, let us see how our look with particle splat.

I have to say that for not been a smooth mesh they have rendering very well.

They have to be making many Gausing blur passes,
Either way, the rendering is a whole problem all together.

I remember you once say that they had splay rendering as open source. But when I click the link all I saw was slides from a gdc presentation.

[Bird]

I have to say that for not been a smooth mesh they have rendering very well.
They have to be making many Gausing blur passes,

I'm not using Flex for rendering. I'm using a simple OptiX based raytracer for that video. They are just spheres so close together that they look like a smooth surface.

Here's a link to the Flex github repository
https://github.com/NVIDIAGameWorks/FleX

They have CUDA and D3D versions. Here's the link for the opengl shaders
https://github.com/NVIDIAGameWorks/FleX ... dersGL.cpp

[Julio Jerez]

ok I am convinced, I will let the rendering to the app, maybe in the future I can put more effort in getting the iso surface, it seems that the technology for point rendering is simpler and is far mature, with many smart people providing method for rendering. I mean if a race traced can produce that kind of scene, there is no immediate need for alternative.
I do need a way to render better sprite than fox size points. so I will work on that.

in any case I now made the solve async, and the result are not to be believed. here is a profile screen o the 64k block

Untitled.png (44.75 KiB) Viewed 4864 times

as you can see, with async update the simulation can goes across frames, and I have to come up with some interpolation scheme. is has the ability to play sync and async, but right now there is no interface to control the background worker.

here is a screen capture. the fps

suspension.png (287.24 KiB) Viewed 4864 times

wit this is now one to make a better shader for bater representation and also one that render faster,
I think that could as high as 1000 or so fps, the point render is really bad.
and then add more functionality, for example collision with static collision trees.

[Julio Jerez]

I'm not using Flex for rendering. I'm using a simple OptiX based raytracer for that video. They are just spheres so close together that they look like a smooth surface.

hey Bird, if this is the case, and you already has Newton 4 in your plugin in,
the you could use that OptiX based raytracer to render and bug of falling points, and see how that looks.
oh mine, hikes!!!!