Boundary Particles and Fluid Particles spawn in disjointed locations

[smokelore]

Hi Scrawk! This repo is really fascinating and I'm having fun digging around in it, but I wanted to check that the behavior I'm seeing is expected.

For this image I haven't done anything to the base code, and I've enabled rendering only for the "Boundary Particles", "Fluid Particles" and "Lines". "Run" is set to off. "Simulation Size" is set to MEDIUM, but it behaves similarly for LOW and HIGH settings.

As you can see, the red Boundary Particles have spawned in disjointed planes. I was expecting these boundaries to form the same lines defined by the "Draw Lines" rendering, forming a continuous box.

Similarly the white Fluid Particles form disjointed planes. Running the simulation causes the Fluid Particles to form a cross-like structure with a plane for each dimension.

This doesn't seem right, and it reminds me a bit of the issues I've had when I've used compute shaders and GPU instancing with improper thread-counts, group sizes, or stride.

Please let me know if I'm running this simulation incorrectly, or if there's anything I can do to help resolve the issue I'm experiencing.

Cheers!

Unity version: 2019.2.21f1 GPU: RTX 2080 Legacy Rendering

[Scrawk]

I checked on Unity 2019 and 2020 and its working for me.

If run is not checked the compute shaders are not run so I dont think its a stride issue.

The particles are drawn using instancing and require a argument buffer to be created which might be the issue.

Since its working on my GPU (GTX 980) it might be a bug in the way Unity creates the buffer or in how the driver works in your GPU but other than that I am not sure what the issue is.

[smokelore]

Thanks for the input! It helped narrow my search for the source of this issue.

I've been trying to isolate the problem and I've created a simpler test case which produces the same kind of error.

I set the Fluid boundaries to the box defined by Bounds.min = (-8, -8, -8) and Bounds.max = (8, 8, 8).

I then replaced the code in ParticlesFromBounds() that determines the positions of the boundary particles such that it would very simply create a square of boundary particles (just one side of the boundary box).

I then removed the "CreateBoundaryPsi()" call in the constructor of FluidBoundary.cs because it looked like it could be altering the simple positions I was passing in. The result looks like this:

As far as I can tell, with CreateBoundaryPsi() removed, there are no ComputeShaders operating on these position values. I've checked where Graphics.DrawMeshInstancedIndirect() is used to instantiate the boundary particles, and it seems totally fine.

Based on what you've said, it's possible that our GPUs might behave differently running this project. I haven't been able to find what would be upsetting my GPU, and I've got a good bit of experience writing Compute Shaders and GPU Instancers for this RTX 2080. Kind of at a loss.

Anyway I'm going to keep trying to get to the bottom of this, but if you see anything in this comment that gives you any clues as to what is going on, please let me know!

Appreciate all your help so far!

[smokelore]

And just to verify -- the boundary particles shouldn't look like the OP if the project is functioning properly, correct?

[smokelore]

Just verified this issue on a separate machine that also has an RTX 2080. Running in Unity 2020.1.6f1 this time.

[smokelore]

I should add it seems like the Fluid Volume runs fine and the simulation is accurate, despite the Fluid Particles being all over the place.

[Scrawk]

Its not meant to look like that. The Boundary particles should be in a neat box around the outside.

If the fluid sim still works it must be still getting the correct positions so its probably just the rendering of the particles using DrawMeshInstancedIndirect thats the issue.

[Gamgie]

Hi everyone.

I have the same bug here on RTX 2060 and Unity 2020.2.3f1. I'm actually pretty noob with all this so I didn't find any solution yet. Maybe someone here will find a way to avoid this weird behavior.

[rainbowkittie]

Turns out it's a pretty simple fix! The position in the shader just needs to take in a vector4 instead of a vector3 and then the read of the position in the shader needs to take the x, y, z values instead of just the whole position variable.

So basically:

StructuredBuffer<float3> positions; --> StructuredBuffer<float4> positions;
unity_ObjectToWorld._14_24_34_44 = float4(pos, 1);  -->  unity_ObjectToWorld._14_24_34_44 = float4(pos.x, pos.y, pos.z, 1);

[1330571]

Turns out it's a pretty simple fix! The position in the shader just needs to take in a vector4 instead of a vector3 and then the read of the position in the shader needs to take the x, y, z values instead of just the whole position variable.

So basically:

StructuredBuffer<float3> positions; --> StructuredBuffer<float4> positions;
unity_ObjectToWorld._14_24_34_44 = float4(pos, 1);  -->  unity_ObjectToWorld._14_24_34_44 = float4(pos.x, pos.y, pos.z, 1);

I have changed from GTX To RTX, and the same problems occured after the change. this fix works fine for me

[Scrawk]

Nice job. Knew I should have stuck to vec4 for everything but did not cause any issues on my gpu went with vec3.