Nvidia Flex Build

Strangely, just opening the flex snippets with the new build, they aren’t running. They say “Unable to create texture. something/something/actor4 does not have an Nvidia Flex buffer”

Wait, nevermind, I had to hit “start” on the comp

1 Like

Yeah, this is something we’d like to do, perhaps in the form of a Flex palette COMP.

1 Like

Very cool and fun to play with eric!

I did notice, not sure if I’m missing something, its a bug, or limitation of Flex ( don’t think so) but in the forcefield example it doesn’t seem like I can get a second force field to apply. If I add another, and deactivate the audio reactive one you had in there, then I can see the second force field starting to work, so I assume bug?

As well I recall some Vincent’s work in this had “secondary particles” that were generated from certain properties of the fluid sim, often used for wave “spray” and the like. Is that a feature of Flex that could eventually be incorporated somehow? Perhaps another particle data TOP that could be grabbed via the Flex TOP if the solver was configured to generate those extra particles?

So stoked for this stuff to be getting built in!

P

Thanks for the feedback, Peter.

Multiple force-fields are supported, so that’s a bug. I’ll look into it.

I believe what you’re referring to are diffuse particles. I’ve added a way to fetch diffuse particle position/velocity, anisotropy, and density info using the Flex TOP via the output parameter. Additionally, I added parameters to the Flex Solver COMP to control diffuse/anisotropy properties of the simulation.

Just a little bit more work to do but it should be ready to release soon. I can post a build here once it’s ready and I think we’ll also be adding it to the main 30k soon.

Here is a link to an updated Flex build, which also includes the latest experimental changes:

I also expect Flex to be included in the next experimental release.

Overview:

  • added Anisotropy, Density, and Diffuse Position/Velocity output options to Flex TOP
  • added a sample rate parameter to the Flex Solver COMP, as well as a bunch of new ones under the Properties page, most notably the diffuse particle parameters.
  • added an option to define simulation boundaries using a bounding box (SOP)
  • bug fixes
1 Like

The anisotropy output is a 2D array texture. Is that going to be supported with a CPP TOP in CUDA mode?

I haven’t actually tested, but I think it should just work. Does it not?

Me neither… but it’s not so important. I also noticed a TOP input from my CUDA plugin is cleaned with zeros with this build.

Hey Eric!

Great stuff, thanks for the quick additions and fixes! A couple other thoughts after playing with it some:

  • is it easy to get the life ( normalized, absolute or both?) of the diffuse particles out?

  • does flex support any other sorts of forces, or just radial fields? In old shader based particle systems i’ve made up things like vortex and spiral forces, just curious if there is anything like this in the Flex API available.

  • I was wondering if something similar to the bullet feedback could be implemented where we get the ability to get feedback back into the system by manipulating position and velocity ( or maybe force acting on each particle?) and sending it back into the solver via textures would be interesting or possible. I don’t really know the implications but seems like a way to really “touchify” the implementation like the Bullet features have done.

  • i definitely second the desire for a screen space fluid shader example as well, could be quite sweet!

Great stuff, I hope to post some of my investigations as soon as I can!

-p

I just tested this. The setup code actually works if I only write to layer 0, but breaks for more.

CUDA Programming Guide "A layered texture can only be a CUDA array by calling cudaMalloc3DArray() with the cudaArrayLayered (…) flags ". So maybe you have to enable it when allocating outputFormat->cudaOutput[0]?

The diffuse lifetime should come in as a normalized value in the alpha channel of the Diffuse Position texture, but I see now that it’s zeroed out. I’ll fix that.

Flex supports other forces for different materials, wind with cloth for example, but for fluids I believe it’s only force fields. There are a few different force field modes but they don’t determine radial vs. vortex. However, you should already be able to achieve a vortex effect with the current force fields by lowering vorticity confinement on the Flex Solver COMP. Unfortunately this is a simulation property so you can’t have different force fields with different behaviour in a simulation.

We do have plans for a feedbacking system in Flex similar to the one in Bullet, not sure when that feature will make it in though.

1 Like

Are you still having the issue with the inputs just being 0?

No, its fine with the 2020.20020 build

@eric.b thanks for the great work, I knew it was a matter of time when I heard about it at the summit :wink: I have to play with it more.

One thing that would be great, but I’m not sure how, would be to expose the ability to create the custom callbacks that the solver accepts. That’s how they do the sample force field in the sdk, that’s how I was creating a force field derived from a texture for https://vincenthouze.com/fluid-structure-360/ and that would answer @archo-p requests about manipulating positions and velocities post solve :wink:

This
https://docs.nvidia.com/gameworks/content/gameworkslibrary/physx/flex/_static/api/_nv_flex_8h.html#ac5427457488ab3f2de91cf65335dda08

Ideally it would work like GLSL TOPs, with a text DAT and the cuda kernel would get recompiled, but I’m not sure if that’s possible without recompiling the whole thing, I’ve never attempted it.
It does get hairier if the custom callback is to have access to other TOPs too…

Anyway just thought I would leave that here, will go play with the new release now!

1 Like

@vininja We don’t support outputting a 2D texture array with C++ at all right now, so I’m not 100% sure I follow your case. At any rate, I don’t allocate the memory using cudaMalloc, since they are OpenGL textures, so I’m just mapping the resource.
Having said that, it does seem like the layered access to GL texture arrays doesn’t really work well, and can only access the first layer. Seems to be a limitation of the GL-interop with CUDA. I can make the cudaArray point to any single layer, but there isn’t a way to give you a single pointer to the entire array of textures.

Yes that was my original question, it’s fine. What I did was to declare and bind a layered surface/texture to the cudaArray inside my kernel, then attempt to write into several layers which indeed gave an interop error.

Are you able to do what you want with a GLSL compute shader instead?

I’m packing particle data into a texture. But I might have a separate set of particles, so having layers like “pages” would simply be a “nice” interface. I’m using a cuda kernel to read directly from a device pointer.
Can I do that in a GLSL compute shader? Maybe passing the pointer in through a SSBO?

No way to use SSBOs currently in the GLSL TOP. You’ll just have to access the texture using texelFetch() and calculate the (x,y) coordinates from your desired particle using the w/h of the texture.