Hi All,
I can write an sdf.simdata file via iso offset sop and have the corresponding DOP for that geometry read the simdata for collision in dops. So the question is how come I cannot use a render ROP to write a SDF .simdata file and then have a the corresponding dop object read that simdata for collision. I am not sure what I am missing, in this example scene the box uses a traditional method and the torus gets the rop .

Best

Rob

It's a shame that something that is really important only is possible with the isoofset node, I currently have the same problem, I want to use an openvdb sdf for collision but after the *. bgeo conversion is not possible to use it in dops as volume collision because there is no tool to convert the primitive to *.simdata.
:?:

You can cache a collision volume in sops using the isoffset node (sdf) as a bgeo, read it back in with a file sop. In dops you can set the Collisions / Volume on a static object to “volume sample” and set the proxy volume to your file node (or a null). There's no need to use a .simdata file for collision volumes.

For openvdb – you'll still have to convert it to a houdini volume first, but this workflow will still work.

I think that it doesn't make much sense to resample again in dops; With a *.simdata file we'll create a very complex sdf with openvdb for example or with an isofset node and then use the voume sops arsenal to modify the created volume to then inject in to dops for collision as *.simdata. (because there is no other way around, I think)

Cheers!!

It doesn't resample if you set the proxy volume, it just uses the volume from sops. I've been using this method with great success for a while now.

If you look inside the RBD asset you can find the SDF representation DOP taking the data from the two sops above, one for the proxy static and the other for the deform proxy. The node resamples the proxy geo or volume to use as collision.

I certainly feel a RFE coming on > Caching the data from a iso offset seems very clumsy > give me a render rop any day.

Rob

Yes I can see that, but I'm pretty sure when you're setting it to proxy volume it's fetching it straight from the sop and using it directly from there. It's impossible to tell without seeing the source code for the volume representation dop. You can see what happens by modifying the isoffset on the fly, and displaying the collision volume in dops. If you transform the volume (leave the geo where it is), you'll see it move in dops. If it was “resampling” it based on the transformed volume I would expect weird results in the resulting collision volume displayed in dops. It doesn't make sense for it to be ‘resampled’ to me. It'd be nice to get some clarification from SESI on this / possibly better documentation. I've attached an ‘extreme-ish’ example… (something you'd never use in production though) you can see it's clearly using the exact sdf from sops. I don't believe there is any kind of ‘resampling’ going on, though I could be wrong of course since I've no idea what's under the hood of the sdf representation node.

Thank you Ian!!!

Yes is like the SDF representation dop bypass when is in volume sample mode, even if I dropped down to zero the division size the volume comes pure from sops.

Thanks for the File Ian !

Rob