Collision free instance painting

[Bird]

the you could use that OptiX based raytracer to render and bug of falling points, and see how that looks.

Setup looks like this but I can't figure out how to get the updated particles positions while the engine is running. Here's my NewtonCallback::OnTransform().

Code: Select all

void NewtonCallbacks::OnTransform (ndInt32 threadIndex, const ndMatrix& matrix)
{
    RenderableNode node = weakNode.lock();

    if (node->getState().isFluidMesh())
    {
        ndBody* const body = GetBody();
        ndBodySphFluid* const fluid = body->GetAsBodySphFluid();

        const ndArray<ndVector> & positions = fluid->GetPositions();
      const ndVector& p = positions[0];

        LOG (DBUG) << p.m_x << ", " << p.m_y << ", " << p.m_z;
    }
}

When I run Newton the particles never move, probably because I don't know what to do in the Update function of ndBodySphFluid

Code: Select all

class NewtonParticleVolume : public ndBodySphFluid
{
 public:
    NewtonParticleVolume (NewtonStateRef& state, ndFloat32 particleRadius);
    ~NewtonParticleVolume();

    void Update (const ndWorld* const workd, ndFloat32 timestep) override
    {
        // What goes here? If it call Execute() then Newton crashes
    }

 private:
    NewtonStateRef state = nullptr;
 
};

[Bird]

Never mind, I got it working be removing the empty override of the Update() in my class that inherits from ndBodySphFluid

This is 64k particles rendered as Spheres in my raytracer.
https://youtu.be/NhL5MHGuP8s

[Julio Jerez]

Ah cool,
It look slow because I have it hack to a fix tome step, fir debugging, late I will removed that,
Them see if I can come up with some setti g to make look more like liquid.

But that is still quite cool
Thanks.

The video tells me a few things.
- to make the effect practical in cpu we are going to limited to some much smaller number like 10k maybe 16k
But I think that's still good enought for small puddle of fluids, smoke, fire, debris,

This is because the shp is a very stiff system to integrate, and we are going to have to either Rk4, or sub sample havetlly.

But, that's not really a big problem, because the cpu is the test case, the effect is already async, and the production silver will be opencl, and there we hope for at least 12 to 200k all fully practical on an entry level gpu.

I also see that the repulsion force between particle is too, strong much higher that I expected, but that could be a bug or a calibration issue.
This is why the time step is set short, but after I debug that we can make voter videos.

[Bird]

I just revisited SplishSplash and it's come a long way since I last looked. I believe the author was a contributor to Flex. Some very nice clean code there. I've never seen Imgui looking so good.

https://github.com/InteractiveComputerG ... lisHSPlasH

They get some nice looking results on the cpu with around 10k particles
https://youtu.be/PJqD5sXvmZY

[Julio Jerez]

That's only 10k?
It looks very impresive endeed.,

I am targeting for a little better that that, but using real secund order mechanic, not position base physics.

It was bad as it was using impulse bases, now they are doing position base physic, and that is not equation of motion, to me that little better that BS. Just a glorify least quadratic optimization that make the object minimize interpenetration but that not not behave physically ally correct.
I rather do nothing g, if I have to ho that route.

[Bird]

No, I think there's a cuda based nearest neighbor tool but the main library is cpu based. The examples run too slow to be on the gpu

[Julio Jerez]

I am writing the sphere reference, so that we can see more interting demonstration, them we can see where we are.

After the calibration and polygonal mesh collision, I think we can be in the same ball bark.

But have no plan to make it a fluid library, this is just a feature.

I am planning to have liquid, games, fire and granular materials,
Who's are jus variance of the same solver.

[Julio Jerez]

one thing that baffles me is how, all the stuff about graphics is not really what is suppose to be.
I am trying to make a shader that render a sphere from a quad.
it is quite a trivial operation.

-basically you transform the particle to viewspace.
-build the quad in view space.
-calculate the radius but projecting the origin and the corner, and subtract the differences. this will give the radius in pixel space.

in the pixel shade
-calculate the pixel distance to the origin, and is bigger smaller that the radius reject the pixel,
-calculate the normal at the surfance of the sphere of that pixel, and apply light.
-the end.

the first step is to write a build board render that make the quad out of each particles. liek th acode below.

Code: Select all

         ndFloat32 radius = particle->GetParticleRadius();

         radius *= 16.0f;
         ndVector quad[] =
         {
            ndVector(-radius,  radius, ndFloat32(0.0f), ndFloat32(0.0f)),
            ndVector(-radius, -radius, ndFloat32(0.0f), ndFloat32(0.0f)),
            ndVector(radius,  radius, ndFloat32(0.0f), ndFloat32(0.0f)),
            ndVector(radius,  radius, ndFloat32(0.0f), ndFloat32(0.0f)),
            ndVector(-radius, -radius, ndFloat32(0.0f), ndFloat32(0.0f)),
            ndVector(radius, -radius, ndFloat32(0.0f), ndFloat32(0.0f)),
         };

         for (ndInt32 i = 0; i < positions.GetCount(); i++)
         {
            const ndVector p(viewMatrix.TransformVector(positions[i]));

            ndInt32 j = i * 6;
            pointBuffer[j + 0] = viewMatrix.UntransformVector(p + quad[0]);
            pointBuffer[j + 1] = viewMatrix.UntransformVector(p + quad[1]);
            pointBuffer[j + 2] = viewMatrix.UntransformVector(p + quad[2]);
            pointBuffer[j + 3] = viewMatrix.UntransformVector(p + quad[3]);
            pointBuffer[j + 4] = viewMatrix.UntransformVector(p + quad[4]);
            pointBuffer[j + 5] = viewMatrix.UntransformVector(p + quad[5]);
         }
      }
      glDrawArrays(GL_TRIANGLES, 0, pointBuffer.GetCount());


as you can see neither the vertex shader or the pixel shade can do that, simple because they can emit data.
now for a 64k buffer that number of point is now 384k point (about 4 meg buffer)
this part alone is what make the rendering so slow.

you would thong that the ideal candicate for this is a Geometry shader. that will reduce the bandwidth by a factor of 6 in the CPU.

but now enter the self-appointed experts, they all agree that Geometry shader are bad, because the write back to memory.

to me writing back to memory in teh GPU should be still better than the CPU making the buffer and coping it across the PCI buffer.

I read one expert that say that it is better to have a compute shader making the triangle list the issue a Gl synchronization point and the call Draw triangle list with a share resource.

I have not doubt that they are probably correct, but that beg the question what are Geometry shaders good for them?

[JoeJ]

I have not doubt that they are probably correct, but that beg the question what are Geometry shaders good for them?

The new mesh shaders would be best here. Mesh shaders can even call 'sub routines' in form of amplifcation shaders, with all data flow keeping on chip. So you can generate geometry without touching VRAM.
If i remember this right, don't have the feature myself.
I have some hope we might get a similar execution model for compute shaders supporting larger workgroups.

But i don't see anything wrong with geometry shaders. Ofc. they might have some performance issues, but iirc they only become a real problem with high tessellation factors. A matter to try out, as mostly.
And iirc, only AMD HW might need to move the vertices to VRAM, while NV does not.

Compute shader is an option too. Needs VRAM if you generate vertices, but maybe easier to use than studying Geometry Shader API details.
Splatting to framebuffer directly from CS would be probably more promising. See the recent success of the 'visibility buffer' approach, as used in UE5, or earlier on Dreams.
This would open op some stochastic scattering, followed by some filtering + TAA to approximate transparency.

But i doubt you want to go there. You don't even have shadows in your demos, hehe
Otherwise there also was some NV paper about 'screenspace fluid' about some tricks.

[Julio Jerez]

well, I am just going to a Geo shader,
to begin with I wrote equivalent of the same thing I am doing in the cpp code

Code: Select all

#version 330 core

uniform mat4 projectionMatrix;
uniform vec4 shadeColor;
uniform vec4 quadSize[4];

layout (points) in;
layout (triangle_strip, max_vertices = 4) out;

in vec4 color[];
in vec4 origin[];
out vec4 quadColor;

void main()
{   
   vec4 posit = origin[0];

   quadColor = color[0];

   vec4 quad0 = posit + quadSize[0];
   gl_Position = projectionMatrix * quad0;
   EmitVertex();

   vec4 quad1 = posit + quadSize[1];
   gl_Position = projectionMatrix * quad1;
   EmitVertex();

   vec4 quad2 = posit + quadSize[2];
   gl_Position = projectionMatrix * quad2;
   EmitVertex();

   vec4 quad3 = posit + quadSize[3];
   gl_Position = projectionMatrix * quad3;
   EmitVertex();

   EndPrimitive();
}

in my opinion this has to be better that coping 6 time the memory, in the cpp code,
in fact, the Geo shade copy data to memory, it is using 2/3 of the memory, since the Geo generates strip and has a command to end the strip which use 4 point for a quad, while in CPU is not possible to brake strips, so you either use a triangle list with 6 points instead of 4 for the Geo shader, or using indirect or instance tricks.

I will be stunt surpriced if this is not at least 5 time better that doing in CPU.
cpu: 6 vertex in memory and copy across the PCI channel
geo shader: 2/3 the memory and half the transformation.

[Julio Jerez]

I hooked it up and it is in this function
void RenderParticles(ndDemoEntityManager* const scene)

I still have the cpu version in #if 0the new one is about from 10 to 20 times faster.
It is getting 2000 fps where the other is below 100.

it is black and the moment, but all I need to do is add the color and make so that is a sphere, in the pixel shader. but that's just a triviality.
after this we can rest that rendering is not going to be the bottleneck.

if you runing it and set it to 4 or more thread, it is quite fast.
and is kind of cool to see all the black dot looking like an ant colony.

[Bird]

I moved up to a simple pathtracer. This is about 90k particles. I don't know why yet but anything much higher than that cause my app to freeze.

https://youtu.be/QWw1a8LcHTA

[Julio Jerez]

is that's ours??
I am afraid to ask?
anyway, the shader make it possible to debug even in debug, which is cool.

the 90 k, I think I know what isit, but if that is no our, them is not that.

[Julio Jerez]

and the next step in to reject pixels outside the radius. so the shader look like this

Code: Select all

void main()
{
   float r2 = dot(quadUV, quadUV);
   if (r2 > 1.0)
   {   
      discard;
   }

   pixelColor = quadColor;
}

next is the light value which is just the projection of the uv that pass the test to teh sphere surface like this

quad.z = sqrt (1 - quad.x * quad.x - quad.y * quad.y)

the normalized value of quad is the normal for lighting.

and that should be enough for the presentation. we can always add but that out zide the scope of Newton.

[Bird]

the 90 k, I think I know what isit, but if that is no our, them is not that.

Yes, that's Newton. I run Newton and the renderer on separate threads and I can see that Newton is still working away when the app freezes. So I think the problem is in the renderer.