09-09-2022, 07:32 PM
(This post was last modified: 11-11-2022, 08:34 PM by nanimo(null).
Edit Reason: anti-spam blocked me from posting full post content
)
I would like more than 4 channels of UserData.
My Slime Player Character quickly filled up the 4 userdata with:
Motivation: Solid surfaces write 1, Air 0, values dilute to 0, such that only particles near the surface can move, with some moving in desired direction, and some "pushing back" against the surface
Bigness: Each square cell of fluid writes a factor of it's Mass to the particle at the center, which then dilutes outwards. Bigger slime sticks more, smaller slime drops slide off stuff.
Stranded: Particles "Inside" write 1, otherwise sharply dilute to 0. Particles on edge of big-enough slimes hover around 0.7 value, Particles on edge that is a "thin strand of slime" drop to 0.1, and are killed, so that thin strands do not awkwardly hold together large Blobs of Slime, or wrap around edges of objects and prevent Slime Splitting
Teams: An Orange/Blue "Team Signal" writes 0 or 1 to nearest particles, and particles near 0 or 1 Teamness accept input from either "Player 1" or "Player 2", with values around 0.5 being an idle grey that get no input
Workaround?
I can imagine an awful Workaround to the 4-channel limit, by creating one set of intangible "Zombie" Fluid per extra 4 Channels I want. It would copy Position and Velocity, and dilute fluid, and any of my calls to GetUserData(particleIndex, dataIndex) would would send dataIndex 0-3 to "real" Slime, and dataIndices 4-15 to any of the "Zombie" slimes. My need for more UserData has not reached the point to attempt such a disgusting (and probably grossly computationally wasteful) solution.
If Implemented
More UserData would allow me to allocate 2-3 channels to "Team", allowing 4-8 individually-controlled regions of Slime, instead of 2. I could add 1 for Temperature, 1 for Digestion/Energy, a few for Harmful Chemicals. I would especially like to allocate 2 channels to "Applied Forces on x/y axis" such that I can use diffusion to get more "Equal and Opposite Forces", ie applying additional braking where I notice "500 Force magnitude on a particle last frame"
From: Multiple user data and more flexible diffuse
Is there some Compile-Time #pragma technique, locked at runtime, that would maintain performance for 99% of users who stick to 4 channels of UserData?
Type of UserData changing from ObiNativeListVector4 to Vector8, Vector12, Vector16 sounds hairy already. I don't know how it would be implemented.
Adding a 1-4 int picker to ObiFluidEmitterBlueprint is probably totally insufficient, it has to be project-wide, for all fluids, right?
short text message to appease the scripts
My Slime Player Character quickly filled up the 4 userdata with:
Motivation: Solid surfaces write 1, Air 0, values dilute to 0, such that only particles near the surface can move, with some moving in desired direction, and some "pushing back" against the surface
Bigness: Each square cell of fluid writes a factor of it's Mass to the particle at the center, which then dilutes outwards. Bigger slime sticks more, smaller slime drops slide off stuff.
Stranded: Particles "Inside" write 1, otherwise sharply dilute to 0. Particles on edge of big-enough slimes hover around 0.7 value, Particles on edge that is a "thin strand of slime" drop to 0.1, and are killed, so that thin strands do not awkwardly hold together large Blobs of Slime, or wrap around edges of objects and prevent Slime Splitting
Teams: An Orange/Blue "Team Signal" writes 0 or 1 to nearest particles, and particles near 0 or 1 Teamness accept input from either "Player 1" or "Player 2", with values around 0.5 being an idle grey that get no input
Workaround?
I can imagine an awful Workaround to the 4-channel limit, by creating one set of intangible "Zombie" Fluid per extra 4 Channels I want. It would copy Position and Velocity, and dilute fluid, and any of my calls to GetUserData(particleIndex, dataIndex) would would send dataIndex 0-3 to "real" Slime, and dataIndices 4-15 to any of the "Zombie" slimes. My need for more UserData has not reached the point to attempt such a disgusting (and probably grossly computationally wasteful) solution.
If Implemented
More UserData would allow me to allocate 2-3 channels to "Team", allowing 4-8 individually-controlled regions of Slime, instead of 2. I could add 1 for Temperature, 1 for Digestion/Energy, a few for Harmful Chemicals. I would especially like to allocate 2 channels to "Applied Forces on x/y axis" such that I can use diffusion to get more "Equal and Opposite Forces", ie applying additional braking where I notice "500 Force magnitude on a particle last frame"
From: Multiple user data and more flexible diffuse
(18-11-2021, 09:44 AM)josemendez Wrote: FYI, the reason why there's only 4 user data channels is because 4 is the length of the SIMD registers used to perform vector operations. This means operating with pairs of user data with 4 components is very efficient. In addition to this we know the data for particle n is at n*4 in the data arrays, making memory access efficient too. Using a variable size for the amount of user data channels would make both accessing the data and operating with it considerably less efficient.
Is there some Compile-Time #pragma technique, locked at runtime, that would maintain performance for 99% of users who stick to 4 channels of UserData?
Type of UserData changing from ObiNativeListVector4 to Vector8, Vector12, Vector16 sounds hairy already. I don't know how it would be implemented.
Adding a 1-4 int picker to ObiFluidEmitterBlueprint is probably totally insufficient, it has to be project-wide, for all fluids, right?
short text message to appease the scripts