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 
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
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.
Ok, but to be clear I must be able to use a SSBO through the fragment shader in the OpenGL CPP TOP sample right?
I can confirm it is possible to use SSBOs in a CPP TOP if anyone was wondering like myself. It’s a much flexible way to route data in and out of your GLSL shader. Apologize for drifting on the point of this topic, thanks Malcolm
This is great!
I had a couple of questions maybe the pro’s in the room can help with?:
- What is the best way to have Kinect interact with Flex particles? (either 2D silhouette or 3D cloud/mesh). I can’t seem to alter shape of collision SOPs to achieve this once the sim is running, and force fields can only be spherical (I think @vinz99 alluded to a solution here but it’s beyond my level). I guess you could have a force field for each joint in a Kinect skeleton, but that won’t work with arbitrary objects.
- If the above is not possible, could a good workaround be to create a 3D grid of tiny force fields and alter strengths/size much like using instancing? or is that likely to grind the whole thing to a halt? (not tried that yet)
- How do we use the anisotropy output? (or rather, I second the idea of a screen space fluid shader because those papers are hard to wrap a head around)
Amazing stuff though!
Unlike in Bullet, the Update Collision Shapes parameter on the Actor COMP currently has no effect on Flex static collision shapes once the simulation is running, but it should be possible to implement for Flex as well. I’ve added that as an RFE.