Finding Normal Distance to Zero-Thickness

   2134   6   1
User Avatar
Member
9 posts
Joined: March 2017
Offline
Hey everyone!

Can anyone point me in the right direction for how to determine on air-tight geometry the distance it would take to push each point inward along the normal (like the Peak nodes does, if you give it negative numbers) until it hits the other side, getting pushed in at the same rate?

Right now if you use the Peak node with negative numbers of increasing magnitude on a mesh that has parts of variable thickness, the thinner parts will eventually start turning inside-out. What I want is for them to stop right before that happens and stay at a thickness of zero, so they squeeze down to invisibility, while the thicker parts of the mesh continue to push inward.

Thanks!
User Avatar
Member
253 posts
Joined: July 2006
Offline
Hey, I don't know if this is what you're looking for, but it might give you ideas.

Attachments:
2nks17.gif (2.3 MB)
erode.hiplc (224.2 KB)

User Avatar
Member
9 posts
Joined: March 2017
Offline
Thanks for the reply!

That is the look I'm trying to achieve. However, I probably should have explained my needs a bit more. Specifically what I need is a value that is that distance to zero thickness, which I can transfer over to vertex colors or UV values, because this is for a game mesh. The actual squeeze along the normal direction will take place in the game engine on the polygonal mesh, not in Houdini, and I need a value to clamp the push distance for, on a per-vertex basis. Also that clamping will drive opacity, so the vertices that hit zero thickness can be made invisible.

Your solution of converting to a VDB and eroding is very cool and works fine for Houdini, but won't work for my needs on this game.
User Avatar
Member
253 posts
Joined: July 2006
Offline
Ok, so how about: Inside a solver sop, shoot a ray ( intersect function in vex ) along the point normal towards the eroding mesh, so that when it no longer hits it you record the last succesful distance.

Edit: Also you should check that your hit point doesn't jump, cause that means your ray missed the spot for which it was intended.
Edited by A-OC - Nov. 27, 2018 17:47:33
User Avatar
Member
9 posts
Joined: March 2017
Offline
That did the trick, thanks!

For anyone stumbling upon this in the future trying to solve the same problem, here are a couple things to note that I learned along the way:

The intersect node checks against a default cube that is not shown in the scene at all, unless you feed it the geo you want specifically. Maybe this was a noob mistake on my part (I've never used that node before), but it wasn't well documented. My assumption was that it would find the first collision with anything, and I was struggling for a while that I was getting a result that did not make sense. The solution was to feed it the geo to collide against.

When projecting inward to check collision with the opposite inner face of the same model, it will instead collide with itself, giving a ray of zero length. The way to get around this is to stick a Peak module on the geo on the version you're checking for collisions, with a tiny push outward (I used 0.00001), just enough to let the ray pass inward.

A good way to keep it from jumping through from a missed ray check between solver frames is to compare the previous frame's ray value versus the current one. The rays should always be shrinking, so if the current one is larger than the last, that means it punched through, and you should replace that with 0 to stop it moving.

A-OC, thanks again for pointing me in the right direction!
User Avatar
Member
253 posts
Joined: July 2006
Offline
Hey, I just devised a way to do it in 1 frame, all inside a point wrangle:

Convert your geometry to SDF, vdb from polygons, fill interior. Then in the point wrangle create a for loop, and start sampling the sdf in small steps, like ray marching, starting from each point towards the inside along the normal. The sampled values will be decreasing, starting from 0. So just when they start to increase back, break the loop and store the sampling distance as an attribute.

Edit: You might want to consider using the sdf gradient vector instead of the point normal as your direction vector.
Edited by A-OC - Nov. 29, 2018 22:13:44
User Avatar
Member
9 posts
Joined: March 2017
Offline
Thanks for the alternate method. I've already set up the original one though, which works for me, so I'll stick with that. But it's good to know that the other way is also a possibility.
  • Quick Links