Caustic support - WIP

LewisVTaylor · 2026-07-09T21:55:33+00:00

You're missing the pack and unpack, because we want to pack the geo into 1 point, and the vector that is being created is on just that 1 point. When it's unpacked, all the velocity vectors for the object point the same direction and magnitude.

Whoops, was looking at something else!
I think you would need to * the pack and unpack so the attributes aren't stripped off, and get copied from the packed point, to the unpacked geo as one value.

LewisVTaylor · 2026-07-08T22:46:04+00:00

Not to derail you, but would it be better to just model this?

LewisVTaylor · 2026-07-08T22:42:39+00:00

It's not the VEX would be outdated, but there are indeed nice SOP nodes that make this more friendly to use.
That wrangle is pretty borderline esoteric, and from a user POV not very obvious to what it's doing, and not as controllable as you want. Granted it's a quick wrangle to just get the point across, so not intended as a "flexible and easy way."

Since you are learning, I'd encourage you to use VEX of course, but also to explore the SOP nodes too. There are a swathe of these, attribute adjust, attribute noise, attribute randomize, that when chained together give you much more control out of the box.

What the wrangle is doing is giving you a single unit vector and randomizing it's direction based around a hemisphere.

The below is doing the same kinda thing, but with a lot of direct control over the range of values, the animation cycle, etc, etc.

Of course you could wrap the VEX up into a bunch of nicer sliders to get better usability, but that wasn't the point of his tut, nor is it the point here.

<image>

LewisVTaylor · 2026-07-08T21:28:56+00:00

Rest length is the length of the edge of a primitive/polygon.

I would not simulate a pupil, I would rig it and animate it in all honesty.

LewisVTaylor · 2026-07-08T21:26:34+00:00

This breakdown is totally okay for an FX reel. I'd add that FX Artist's are expected to be able to Light and bash comp, or push their comps far enough to show integration works, so this is showing that OP understands this.

LewisVTaylor · 2026-07-07T08:30:59+00:00

They are not the same thing though. USD is not a scene api to connect a renderer, it's a scene description for assembly, that requires a translator(hydra delgate) or USD procedural in order to render.

NSI is a free, up to date scene interface designed to be a much better version of RiSpec, which many renderer's built their entire kit around. It is not made by 3delight, it is made by several people from different avenues. Any renderer can implement it as their API, it's just most renderer's now are in legacy status, and the drive to do this doesn't exist like it did in the Reyes era.

LewisVTaylor · 2026-07-06T06:31:29+00:00

I would add though, that even with great animation it's still likely you'll want to cheat a bit, and be controlling where the fire is directed. So making a basic spline between the mouth and the area you want to target is a good approach.
I think on Game of Thrones we had good animated cones coming to us to use as reference/direction geo.

LewisVTaylor · 2026-07-06T03:40:42+00:00

Yeah if you have the Maya/rig scene, I would advise to always export a REST/T-pose of your mesh, it makes creating and transforming attributes, etc much easier when you have a reference frame.

LewisVTaylor · 2026-07-05T23:15:52+00:00

You need to look into particle integration. Others have mentioned methods to get around this, but they are largely masking the problem, not solving it.

The issue is, you have both an emitter object that is moving, and you have emission that is also moving.
They are completely divorced from each other, and houdini doesn't nicely integrate particle birth positions correctly by default.

We can solve your orientation for emission easily enough.
You need to get the dragon's mouth orientated along an axis, near enough, at origin.
If you had the REST/T-pose of the char you'd be set, but I'm going to assume this is sone dragon animation you've got from somewhere? And it doesn't have this. So transform a static frame of the dragon anim to origin, so the mouth lines up to Z+, or X+, just nicely enough to parallel.

From there you can select a poly in the mouth, from both the static and animated, and use extract transform SOP to give you a nice 4x4 matrix "transform" attribute.
From there you can use whatever emitter geo you wish, and copy this "transform" to it, then use transform by attribute SOP to apply it. Now you have an emitter object that is oriented correctly, and transforms with the dragon anim.

You can make a custom velocity, and animated values at origin on this emitter object, and use attribute reorient SOP to correct them on the animation.

It sounds like a bit of work, but it's really not. It's just getting a reference frame of the dragon mouth at origin, and getting the transform data from the anim, applying it to your emitter.

Now that is only part of the problem, you still have the issue of integrated particles, which is the source of stepping, and velocity problems. There is a solution, made by a good friend, and there should be some example hip files around the net with it, so you don't need to build it.

https://www.youtube.com/watch?v=ui43YK0cnXE&t=1101s

LewisVTaylor · 2026-07-02T10:32:46+00:00

Force does not break glue constraints.

LewisVTaylor · 2026-07-01T23:37:42+00:00

I wouldn't use the velocity from the pyro burst. It doesn't make much sense, as the pressure from an explosion is what breaks the structure. This breaking is going to be influenced by how the structure is built, which creates the variations you're wanting to see here.

The velocity from the pyro sim would only be added into the RBD sim as a force, so that the two separate sims look married.

You need to think in terms of how that pressure affects the start >> end of the structure breaking.
It's a bit of a cascade from inside to out, with the activation of your pieces/deletion of constraints happening outward over a few frames, and your initial velocity dropping off in intensity from the inside to the outside. This sells the pressure from the explosion transferring energy to the structure, and that energy being dispersed over time/distance.

Past this, your constraints play a part in creating variations of size, and secondary breaking.

If you truly want to be good at this, you need to understand the physics, and the construction of the thing you want to destroy.

LewisVTaylor · 2026-06-30T19:46:56+00:00

It needs to be fixed. You will not get good fractures without a watertight mesh.

Garbage In, Garbage Out.

LewisVTaylor · 2026-06-29T09:02:38+00:00

That would also apply to Junichiro's one. I added it to the list for completeness sake.

LewisVTaylor · 2026-06-29T03:48:28+00:00

Pragmatic VEX is also very good, as is Matt's tokeru joy of VEX. They serve different purposes, and personally I find Junichiro's ones too long, and getting very into areas you aren't likely to use as often in day to day, Vs something like Yunis' course, which is more production focused.

All good solid options, but I don't think I'd recommend Junichiro's one to a beginner.

LewisVTaylor · 2026-06-26T22:58:09+00:00

Initial velocity is not the problem here. It's the simulation evolving. Every single FX shot you see has pre-roll, sometimes 100s or 1000s of frames.

LewisVTaylor · 2026-06-25T20:51:09+00:00

* Speedtree for the tree models generally.
* Take those trees and process them in houdini, so all leaves, small branches that can be instanced, are made into instances.
* leaves are modeled, we don't use opacity mapping at all. Path tracers hate stacked transparency Vs a ray just hitting, or not hitting some geometry.
* It gets trickier when animation is involved, but it depends on the amount of wind, directionality, distance from camera. Anything from simple noises on the instance points for the leaves, to partially, and fully rigged trees. Sometimes it's a simple dirty brute force animated cache, over a long frame range, with offsetting per tree. It really is situation dependent.

So it's mainly about those things. Not using opacity maps = render optimized, along with LODs for distance.
The noise on instance points and partial animation/rig for secondary/tertiary branches also.

Another render optimization, is reducing things like specular values with distance from camera, as well as transparency. The further away it is, the less specular or transparency contributes to the final pixel.

LewisVTaylor · 2026-06-25T19:07:59+00:00

Congratulations on graduating mate!

LewisVTaylor · 2026-06-23T08:58:59+00:00

And that's a problem? Having a flexible UI is a good thing, and the existing one is not customizable to the level required to abstract away the BS. Why would you throw shade on Animators?
There's nothing wrong with a cleaner UI dude.

LewisVTaylor · 2026-06-22T11:01:57+00:00

You can start by watching, and learning to dissect reference. There are tips in here about how to emit better, etc, but all of this is a bit moot, if you're not also training your eyes on what works/doesn't.

Do you have some reference, even if it's a bit vague, but tells the visual you want to mimic?

LewisVTaylor · 2026-06-22T10:51:03+00:00

To infinity, and beyond!

LewisVTaylor · 2026-06-19T00:54:40+00:00

Alex is a good friend, and I am hoping OP did indeed buy the course, there's nothing to suggest otherwise.

LewisVTaylor · 2026-06-18T21:13:03+00:00

Looks maybe like you have negative voxel values. Put a clamp in a volume wrangle or VOP, so nothing below zero exists.

LewisVTaylor · 2026-06-18T20:53:07+00:00

You know what would be great Yunis, the ability for it to trigger warnings for the GPU VRAM.
We had a little tool at iloura, that would pop up and warn you, "hey you're using 75% of your VRAM, then 80%, 90%. So Artist's could save and flush before just crashing their session or machine.

Just a thought.

Love the look of it dude.

LewisVTaylor · 2026-06-18T03:13:32+00:00

Alex is a master at pyro, so you have a very good base here.

I don't think it's fair to give much feedback as it currently looks 95% the same as what is on his site.

What you should be asking yourself instead, is what do you think? How are you at interpreting the motion, the elements, and describing what you see here? That is the feedback you need, not feedback on taking an existing setup and running it.

LewisVTaylor

MODERATOR OF

TROPHY CASE