eetu's lab

[moondeer]

...https://vimeo.com/36791437 .. houdini boxes for the win

i would love to see this hip. possible?

its just so damn pretty...

[old school]

Now that H12 has released, you gotta try out the new faster instancing with the boxes. Loads and I mean LOADS faster than H11!

There's even a cvex plug-in for the instance procedural where you are handed a transform to manipulate the instances. One of my very top new features in H12!

[Magnus Pettersson]

i would love to see this hip. possible?

its just so damn pretty...

Thanks! Yeah sure, I have attached the hip file

Now that H12 has released, you gotta try out the new faster instancing with the boxes. Loads and I mean LOADS faster than H11!

There's even a cvex plug-in for the instance procedural where you are handed a transform to manipulate the instances. One of my very top new features in H12!

I did try the instancing out in the beta and it is very fast! Realtime scrubbing in the viewport of this file I never got the point instance procedural to work tho, i just got:

mantra: ptinstance couldn't find object '/obj/points' . But i havent installed the golden build of h12 so it might be fixed.

If you know how to get these boxes out (or similar example) with the point instance procedural and with the scaling of the boxes z axis with the speed attribute please share, since im pretty lost in the cvex world to get that transform stuff right (well first i need to get the instance procedural working in the latest build hehe).

fluidboxes_fx_v003_mtp.hip

[Jason]

There's even a cvex plug-in for the instance procedural where you are handed a transform to manipulate the instances. One of my very top new features in H12!

Of course this new procedural isn't mentioned anywhere, not even in the Whats New. Tut, tut! SESI should definitely promote all the new features -- put together a video demo'ing EVERYTHING new, in a few ways -- lest they undersell themselves. And no demo in the helpcard for the Point Instance Procedural either..

[rtarantino]

I totally agree with Jason. When I saw "instance procedural" in menu, I thought FINALLY!! but so far I can not make it work... At least need help(including cvex future)!!

[Jason]

I totally agree with Jason. When I saw "instance procedural" in menu, I thought FINALLY!! but so far I can not make it work... At least need help(including cvex future)!!

I'd encourage you to post your experiences and frustrations with it on the SESI forums, just to get some info straight from the horse's mouth.

[eetu]

After checking out the "classic" Lagoa teaser video, I started thinking if something like the crumbly stuff in the beginning could be done with variable (high)viscosity FLIP fluids.

Well, this falls short of the Lagoa stuff, but it's an interesting look anyway, I think.

(click for anim)

It's quite simple really, I just init the per-pixel viscosities with a VOPSOP noise inside a SOP Solver, behind an Intermittent Solve DOP set to run "Only Once".

Hip attached for inquiring minds.

variable_viscosity_v005.hip

Edited November 29, 2020 by eetu

[0rr]

really good looking. just like wet sand.

[zarti]

..

Well, this falls short of the Lagoa stuff, but it's an interesting look anyway, I think.

..

interesting ?! .. ?

[lisux]

Ir is looking great etuu.

Love to see the flip solver doing so well.

[rafaelfs]

It's quite simple really, I just init the per-pixel viscosities with a VOPSOP noise inside a SOP Solver, behind an Intermittent Solve DOP set to run "Only Once".

Really cool! I'm just wondering here why exactly you used the second input in the FLIP solver, what was the "insight" here for such decision?

Cheers

[eetu]

Really cool! I'm just wondering here why exactly you used the second input in the FLIP solver, what was the "insight" here for such decision?

Heh, hard to remember, but looking at the help now:

2nd: "the ideal place to add solvers that manipulate the particle velocity or position still farther..."

3rd: "This is the best place for field-affecting microsolvers to be attached..."

4th: "The main use for this input is to add or remove particles..."

from those it looks to me that the 2nd one would be the closest guess for manipulating per-particle attributes

[rafaelfs]

I see, I kind of understood that too, but was led to discard the option because of the specificity of the language...

Thanks again

[eetu]

The regular voronoi-cells are starting to look boring. How to make them more interesting?

One of the things you can do is scale the object, do the voronoi and scale back - that way you can get things like splinters.

But you can take things further, all you need is a deformation that is reversible and has a defined value everywhere in space.

Now that's not always easy. If you just bend something and then apply the opposite bend operation on the result, it will look very different that what you started with.

One way to get deformations like that to be reversible, is to use lattice deformation.

Deform your lattice, then use the lattice SOP on you geo, shatter, then apply the lattice SOP with the source and target lattices interchanged.

There are some inaccuracies with this approach, and the target doesn't match the original geometry exactly.

For more interesting patterning, let's dive into freeform deformations with a VOP SOP.

One's first idea might be to apply noise to a geo, shatter, and then apply the same noise but with a negated amplitude.

This does not work, as the same noise function will be computed at the displaced positions, resulting in different values,

and the reverse operation results in a mesh that doesn't match the original.

So, after doing the deformation and the shattering, we need to get the noise value in the coordinate system we had before deformation,

and - ta-da - that's what rest coordinates are for. This almost works, but not quite, but the resulting mesh is still not 100% what we started with.

This is a subtle problem, but happens because of the new points created in the shatter process, even though they have nicely interpolated rest

coordinates (which is very nice). If you have a new point created halfway between existing points, it's rest value is in between, but the

noise value at that midpoint is not necessarily at the midpoint of the noise values at the original points..

So, what finally worked for me was simply storing the actual deformation value to each point, then the reverse operation for each original

and new point brings them right back to where the original surface was.

What about the inside geometry, an insightful reader might ask, and rightfully so. By default the Voronoi Shatter SOP seems to propagate the rest/deform

values from the outside surface to that piece's newly created inside surface. This means that the coincident points, and thus polygons, get different values depending

on their piece membership, and this results in an intersecting jumble inside the mesh. AttributeTransfer to the rescue - with that you can get interpolated values inside the

mesh. It might not be a perfect interpolation, but it doesn't matter that much, as long as coincident points get the same values.

In the end everything pretty much works, but there are still some artifacts with some inconvex pieces that need to be ironed out. I guess this all should be done inside the shatter tool for

maximum quality.

And then, a somehow directable tool would be more useful..

Edited November 29, 2020 by eetu

[Green-Man]

Cool technique! Thanks for detailed description and all the stuff you share here.

[eetu]

As an addendum to the above, you can of course direct the voronoi shatter by fracturing the geometry first yourself, to create fault lines.

Here's a box cut first with spheres, and then run through the regular voronoi shatter.

It's much better to do the voronoi shatter independently for each piece in a foreach loop, otherwise the voronoi cuts will slice through all your pre-created pieces. This way the cuts will be in different places for all pre-created slices, and the fault lines you want to see work better.

modeled_voronoi_v06.hip

Edited November 29, 2020 by eetu

[dvfedele]

This thread is just amazing!!! LOVE the example files...learning so much.

[eetu]

I got frustrated that cloth no longer affects rigid bodies, only the other way round.

cloth_rbd_b.mov

For some sort of a simple replacement, I create a vector volume from the N attribute of the cloth in a SOP Solver.

Then I apply that as a Field Force to the RBD Objects. Think of it as a repulsion field. The cloth is pretty rigid/plastic here.

cloth_rbd_a.mov

This is by no means a great replacement, but if you really really need that feedback effect, you could try something like this.

(For example, the feedback force here is constant - not proportional to the "impact" force of the colliding RBD object.)

[eetu]

Oh, and here is the hip for the above.

cloth_rbd_feedback_v003.hipnc

[Pazuzu]

Thanks Eetu very clever solution!!!!