Jump to content

eetu's lab


eetu

Recommended Posts

My darling from the Lightwave days; Grit accessibility shader.

 

I did upload a version of it on my early days in Houdini-land, although the ur-original is from '98..

This one isn't that much different, added a few more features and made a proper asset out of it. If it seems to work for you guys, I'll put it on Orbolt.

 

From the node help;

 

Grit is an accessibility shader, that is, it tries to figure out how easily accessible a location is.

 

Conceptually it can be thought of as how big a sphere could fit here and still touch this spot.

 

Whereas ambient occlusion tries to figure out how much of the above-horizon hemisphere is occluded by shooting a lot of rays and seeing how many of them hit ot miss, Grit only regards the nearest distance any of the rays hit. Also, Grit only shoots a single fan of rays around the normal instead of trying to fill the whole hemisphere with rays, because of this it should always be signicantly faster.

 

When used with the negated normal, Grit finds exposed edges instead of hidden crevices.

 

Some examples of using grit as a mask:

brass-kitty_weepul.jpg

weepul, lw

Grit_kuva01.jpg

iiro, houdini

 

Attached is the HDA and a very simple hip.

ee_grit_test.hip

grit.otl

  • Like 3
Link to comment
Share on other sites

  • 2 weeks later...

(consolidated to this thread as well, for completeness' sake)

 

Deep ID

 

If you save out an ID value for each of your samples in a deep exr file, you should be able to extract perfect masks or remove all samples associated with an object/primitive.

Sounds nice, no?

 

Here's a hip and nuke file to play with, as well as an example exr.

Example images of removing one motionblurred object in post, in the nuke file you can pick whichever you want.

(If I remember correctly, it's been a while and I don't have Nuke on this machine)

 

post-2678-0-24240200-1407929071_thumb.jp

post-2678-0-16055700-1407929073_thumb.jp

post-2678-0-64206700-1407929074_thumb.jp

post-2678-0-21852700-1407929075_thumb.jp

example EXR (too big to attach)

 

 

deep_id_v003.hip

deep_id_v003.nk.zip

  • Like 2
Link to comment
Share on other sites

(consolidated to this thread as well, for completeness' sake)

 

Deep ID

 

If you save out an ID value for each of your samples in a deep exr file, you should be able to extract perfect masks or remove all samples associated with an object/primitive.

Sounds nice, no?

 

Here's a hip and nuke file to play with, as well as an example exr.

Example images of removing one motionblurred object in post, in the nuke file you can pick whichever you want.

(If I remember correctly, it's been a while and I don't have Nuke on this machine)

Cool! Small tip: Instead of those Inline VOPs using Renderstate(), you have the Render State VOP :)

Link to comment
Share on other sites

  • 4 weeks later...
  • 4 weeks later...

This time something that might even be useful, a tonemapping COP.

I've recently worked on game tonemapping, and thought why not implement some of the operators in Houdini. This time written in VEX.

Operators I implemented are from Reinhard, Insomniac Games and John Hable.

 

Some of the parameters can be a bit opaque, so I implemented a simple preview of the curve overlaid on the image.

 

A preview video

 

I guess I should do this in Nuke too..

tonemap_example.hip

tonemap_shot1.png

tonemap_shot2.png

ee_tonemap.otl

EDIT: a version patched by @fsimerey to work with newer houdini versions is at 

 

Edited by eetu
  • Like 4
Link to comment
Share on other sites

  • 1 month later...

Simulating sand/snow as a two-phase variable viscosity flip fluid.

sandcastle.png.eb3d3df31cee361f6b081010d7efd40a.png

 

Something I've been dabbling in every now and then since last year and that awesome Disney mpm paper. I of course wanted to duplicate their stuff, but soon saw that it would be a huge job to try and build a proper material-point-method system in DOPs. I decided to try and bring some of the behavioural aspects into the more familiar flip system, in whatever way they could be expressed in it.

 

Here the main idea is to think of sand/snow as a two-phase fluid -- it's either free flowing (viscosity zero) or clumped/solid (viscosity million) and certain conditions can change it's state between those two phases. The main driver for phase change here is strain magnitude, calculated with a Gas Strain Integrate DOP. Another factor is pressure; I've tried using it to both decrease and increase the phase change threshold - thinking of sand and snow respectively. I've also approximated compressibility by mixing in a bit of pre-nondivergent velocity with the nondivergent. I also have a material strength field that ends up creating a lot of visually interesting features.

 

This is of course far from perfect, but does give birth to some interesting behaviours. I've tried to counter some of the peculiarities by e.g. modifying the strain with velocity (matter in free fall is under no stress and thus can easily harden again) and depth from surface (internal pressure values can be nonphysically high with flip). Also I'm doing negative vortex confinement and negative surface tension to suppress fluid-like behaviour, I'm not sure whether that does bad things to the energy balance. Overall this needs a lot of tweaking for any situation and it seems to be hard to create a generic tool out of this, so that's why I'm just giving out the raw r&d hip here.. :)

 

 

Some older snow-like tests, which still had a more straightforward variable viscosity approach instead of variable material strength that drives the viscosity phase change:

snowtest.jpg.46937f5aeec58d9a437d592a73e15c1d.jpg

(well in reality this is all mud-like, but that doesn't sound so cool;)

 

The hip is not meant to be usable as-is, but rather as an inspiration for inquiring minds on how to build custom stuff into the flip solver.

As for documentation I'll just say that the main parameter is the Phase Change Threshold in the strain_to_viscosity gasfieldvop inside the solver..

mpm_dev_h64castle.hip

Edited by eetu
fixed images
  • Like 3
Link to comment
Share on other sites

  • 4 months later...

A bit more growth stuff, this time with more control - it tries to grow along a curve.
ee_kassel.thumb.jpg.3e622130989de0981ed736d1df313306.jpg
 
40MB mp4 render and 28MB mov opengl preview.

I also tested a hard boundary, it is a very explicit way to control the effect, but the result is not too organic, plus it lacks a sense of directionality.

 

Edited by eetu
fixed image and links
  • Like 6
Link to comment
Share on other sites

Woh, that is way cool eetu! Is this also done w/ Python HDAs? Very, very cool. Cellular automata is something I have a hard time wrapping my head around, but I enjoy looking at examples in Houdini - things tend to make more sense here :)

 

Thanks! This is no cellular automaton, this is a poly surface being abused within a Solver SOP. Trying to follow the quaddel path here..

Link to comment
Share on other sites

I'll just consolidate the raytrace uv baking shenanigans from this thread into here. The original scene is from Sebkaine.

-------------------------------------------------------------------------------------

 

How to bake to UVmaps with PBR

 

Ok, I tried this before and failed, but this time I kinda got it. Quite hacky, but here we go.

  • First, render out an uv-unwrap of P and N using micropolygon mode.
  • Second, and this is optional, dilate P and N in COPs.
  • Thirdly, bake with PBR, using a lens shader that picks up the P and N from the above map, and shoots each ray back at the surface from 1mm height or something.

post-2678-0-48627800-1427318765_thumb.jp

 

Being Houdini, this can of course be trivially automated. It's not perfect and can need a bit of tinkering, but in a pinch it could be usable   :)

I have used the lens shader method before with mesh/nurbs primitives to bake some effect things, but by itself the method can only work with geometry that is a single primitive. This time I first thought I'd bake out a map with primitive IDs which the lens shader could read, but soon realized it would be a lot smarter to just bake out the P and N. It took a while to get the map dilation to work - I had all sorts of weird stuff happening before I realized the COPs dilate doesn't like negative numbers..

 

post-2678-0-23118800-1427318819_thumb.jppost-2678-0-95736600-1427318717_thumb.jp

 

ee_uvlens_bedroom.hip

 

-----

 

How to bake to point colors with PBR

 

Ok, here we go!

 

1) In a lens shader, determine the sequential number of the pixel we are in, think of it as a point number, and fetch the P and N of that point in your geo.
2) As before, use those to fire a ray back at the surface from a millimeter up
3) After rendering, in a vopsop, do the inverse operation of 1) and calculate u and v coordinates for the N'th pixel, where N is the current point number. Fetch the color in that pixel and set point Cd attribute to that.

 

post-2678-0-41607500-1427319006_thumb.jp

post-2678-0-18478000-1427319004.jpg

 

Step 2 is prone to fail with polygon edges, as the ray might or might not hit the surface when fired from/at an edge vertex. One could fire 4 rays and pick the shortest one or something like to fix it.
There is a very weird flipping going on, as you can see, the color of the blue light is on the wrong side. Looks as if z is flipped somewhere, but I can't figure out where.

One could probably trace rays "by hand" from the points, but I suppose the only way to get all the sampling goodness out of mantra is to render actual pixels.

bake_pbr_vertices.hip

 

----

 

(also check Skybar's quickie fix for the flipping problem in the original thread)

 

 

  • Like 3
Link to comment
Share on other sites

  • 3 weeks later...

Eetu your posts are a godsend for us trying to figure out high end ideas. I fell in love with the unified growth stuff and saw that you were dabbling in it. I would love to hear how you tackled the self intersection testing in the sdf. In my tests, as soon as i try to converted the growing poly into vdb's and back, the surface just blends with itself creating a smooth blob. How did you get it to stop growing as it is about to intersect?

Link to comment
Share on other sites

Hey, I do not convert vdb back to polygons, I just use the vdb distance field value to check for intersections. Inside an attribute vop sop I calculate the new, "grown", position for current point, check if that new position would be inside the volume, and based on that I use either the old or the new position. See the attached file for details, it has the follow-curve and hard boundary versions of this.

 

I just held a two-day workshop on growth techniques at Bartlett School of Architecture this week, and quite liked it, maybe I'll make a video tutorial on this stuff.

They also graciously 3d-printed one of the growth structures, I think this was frame 800 of the attached:

 

post-2678-0-99514900-1429353304_thumb.jp

 

 

quaddel_v016.hip

  • Like 7
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...