Isooffset

[Marc]

Hey all you clever people.

Has anyone tried to use the IsoOffset SOP for more than just the initial "What the hell is this?" phase? I seem to be getting two surfaces created, one inside the other. This would actually be very useful for what I'm doing, but currently there doesn't seem to be any way to reference either one.

Anyone played with this?

M

[edward]

I've never used the IsoOffset SOP but what do you mean by "reference"? Does the Connectivity SOP help?

[Jason]

I've never used the IsoOffset SOP but what you mean by "reference"? Does the Connectivity SOP help?

21501[/snapback]

Is your geometry hollow? Are the primitive normals all facing outward? Closed polygon shapes should produce a solid volume but you may need to mess with the volume representation parameters a bit to get the best and cleanest result. This could probably be used to build a cute cage for Simon Barrick's Warp SOP... Simon, tried that? The build tetra mesh is quite interesting too

One very unfortunate thing about the Volume (SDF) representation is that its instantaneous - that it gets converted to regular ol' polys before you get the chance to take advantage of the Volume Signed Distance Field. You do get to swell or starve the volume for the mesh generation, but that's about it. I wish that the Volume SDF could be added as a geometry type alongside polys, metaballs and patch surfaces and allow some access to their intrinsic properties.

For example, we had a character running about with this cloth simulation that had the clothing interpenetrating the skin. I wanted to quickly generate a Volume for the skin and push the cloth out to the limit surface (+ a little bit). This was not possible in this exact way unfortunately - but I came up with another plan. Having access to the Volume info would've let me instantly get the distance (and direction) to the nearest surface with the theoretical volume() and volumegradient() calls and I could've snapped the cloth to the skin. While not a perfect solution; definitely a lot of fun

SESI, are there any plans to support SDFs as a geometry type? A Volume SDF (+ a nice general transform) would be very useful indeed! Also - how hard is it to implement a custom geometry type in the HDK?

[Daniel]

One very unfortunate thing about the Volume (SDF) representation is that its instantaneous - that it gets converted to regular ol' polys before you get the chance to take advantage of the Volume Signed Distance Field.  You do get to swell or starve the volume for the mesh generation, but that's about it. I wish that the Volume SDF could be added as a geometry type alongside polys, metaballs and patch surfaces and allow some access to their intrinsic properties.

For example, we had a character running about with this cloth simulation that had the clothing interpenetrating the skin. I wanted to quickly generate a Volume for the skin and push the cloth out to the limit surface (+ a little bit).  This was not possible in this exact way unfortunately - but I came up with another plan.  Having access to the Volume info would've let me instantly get the distance (and direction) to the nearest surface with the theoretical volume() and volumegradient() calls and I could've snapped the cloth to the skin. While not a perfect solution; definitely a lot of fun

SESI, are there any plans to support SDFs as a geometry type? A Volume SDF (+ a nice general transform) would be very useful indeed! Also - how hard is it to implement a custom geometry type in the HDK?

21502[/snapback]

Well, not exactly a new geometry type. But I wrote a simple vex function with the hdk that will return the distance and gradiant to a sdf given a 3d location. The vex func can then be used in other vex sops, pops, shaders, etc. for volume tests. The sdf class is pretty straight forward. Unfortuantly I wrote this for work, so I can't post it, but it should be easy to reproduce.

I'd like a generic sdf format that's standalone so it would be easy to take sdf's generated in houdini or elsewhere and use then in other software like renderman or any other custom software we have. There are all sorts of uses for them

daniel

[Jason]

I'd like a generic sdf format that's standalone so it would be easy to take sdf's generated in houdini or elsewhere and use then in other software like renderman or any other custom software we have.  There are all sorts of uses for them

Here's an idea: it's not too efficient (size-wise) - but it is easy - to simply throw out a grid of points much in the same way that you can i3dconvert to and from i3ds to bgeos.

I'm a big fan of the fun properties of SDF's - from dynamics, modeling to rendering directly. I hope we see more of them. Having access to them really increases the oooh! factor.

[Marc]

While I agree with the need/desire for the SDF as a geometry type, the connectivity SOP works great, thanks Ed.

M