Yesterday, 10:58 AM
(This post was last modified: Yesterday, 11:24 AM by josemendez.)
Hi!
This isn't a bug per se, but a limitation of the Compute backend that has its roots in GPU's (or more accurately, HLSL's) inability to allocate memory dynamically. This means we must allocate a fixed amount of memory, and drop data when we reach that maximum.
Particles in the compute backend have a hardcoded limit of 32 potential contact pairs each. Once you get past this amount of potential contacts, particles will start to randomly drop contacts every frame. This means they may drop their contact against the floor for a few frames, then get launched upwards next frame when they do keep the floor contacts but decide to drop different contacts. Which contacts are dropped and which ones are kept is decided essentially at random, since it depends on the order in which threads are executed as they find and append potential contacts for further processing.
Note that this limit affects potential contacts (not actual contacts/collisions). This is why particles will act up when they're merely near a crowd of colliders, even if they don't touch them.
You can increase this limit by opening up ColliderGrid.compute, near the top you'll see this define:
You can set it to 128 for instance to increase the amount of potential contacts allowed by each particle, at the cost of more memory. I didn't expose this limit in the solver inspector's Memory Budget section (like I did with other memory limits) because we doubted anyone would hit it, but now I see I was wrong
.
The Burst backend doesn't have this limitation, as it can dynamically allocate more memory if needed.
kind regards,
This isn't a bug per se, but a limitation of the Compute backend that has its roots in GPU's (or more accurately, HLSL's) inability to allocate memory dynamically. This means we must allocate a fixed amount of memory, and drop data when we reach that maximum.
Particles in the compute backend have a hardcoded limit of 32 potential contact pairs each. Once you get past this amount of potential contacts, particles will start to randomly drop contacts every frame. This means they may drop their contact against the floor for a few frames, then get launched upwards next frame when they do keep the floor contacts but decide to drop different contacts. Which contacts are dropped and which ones are kept is decided essentially at random, since it depends on the order in which threads are executed as they find and append potential contacts for further processing.
Note that this limit affects potential contacts (not actual contacts/collisions). This is why particles will act up when they're merely near a crowd of colliders, even if they don't touch them.
You can increase this limit by opening up ColliderGrid.compute, near the top you'll see this define:
Code:
#define MAX_CONTACTS_PER_SIMPLEX 32You can set it to 128 for instance to increase the amount of potential contacts allowed by each particle, at the cost of more memory. I didn't expose this limit in the solver inspector's Memory Budget section (like I did with other memory limits) because we doubted anyone would hit it, but now I see I was wrong
.The Burst backend doesn't have this limitation, as it can dynamically allocate more memory if needed.
kind regards,