Archived post by lewis.taylor.

your primary driver is _what_ scale are you rendering at? everything else is just a scaling factor going from that to the preferred working scale of the solver. Pyro will handle very small values, and very large ones fine, so you don’t tend to mess with the working scale. 1m is 1m for example.
FLIP is notorious for being fiddly as small scale, so anything under 1m in real world size you tend to work in larger scales. Example, simming liquid pouring in to a glass, real size might be 0.1m, but you would generally work at 10x that in FLIP. But on the other end, if the scene is 10m or 100m or 1000m you would leave FLIP at normal scale.
Bullet similar deal. Anything with pieces under 1-2cm can be a pain, so we routinely work 10x in scale. But if your smallest piece is going to be decently sized you might not change working scale at all.
Vellum is roughly based around real-world, so pretty much never change this working scale.
Heightfields, it really just comes down to working in the scale that the solver/defaults are built around.
At the end of it, you’re really only talking about working in the scale best for the solver/technique, and then scaling to render scale for output/lighting.

Archived post by mattiasmalmer

it is a bit of a hack to say the least. i grab the normal, tangent and bitangent. make a matrix and transform the raydir into it. use the X and Y coords of that to offset the uvs based on the height in a bitmap. (i do a little loop to incremetally do this but thats just for quality.)

here is the Parallax mapping hipfile. could be fun for decals and such.

Attachments in this post:
http://fx-td.com/houdiniandchill/wp-content/uploads/discord/20251109/25/25/parallax.hiplc
http://fx-td.com/houdiniandchill/wp-content/uploads/discord/20251109/25/25/image.png

Archived post by lwwwwwws

alright here’s something – it uses a similar method to mmColorTarget but is mostly in SOPs, I think it would be quite awkward purely in COPs unless there’s python or expression access to pixel values now in 21.0… it can restore quite busted chart images like the left one back to ACEScg primaries and it’s fast enough to update as you drag the handles around <:tide_pod:415308365942620161> i realise i’ve done this in apprentice which wasn’t very clever of me but maybe an adult could adapt it to be a bit smoother anyway, maybe inside a COPs HDA

Attachments in this post:
http://fx-td.com/houdiniandchill/wp-content/uploads/discord/20254609/23/25/Screenshot_2025-09-23_at_23.21.30.png
http://fx-td.com/houdiniandchill/wp-content/uploads/discord/20254609/23/25/Ls_MatrixFromChart_v01.hipnc

Archived post by igor.elovikov

here is the contact sheet packer inside native copernicus context very hacky and very fast though

relies on couple of hacks: * access to time dependent source inside “simulated” block – so packing is basically frame by frame sim * “custom” Time Shift COP based on h21 python snippet
so how is this reliable i’m not sure

here is the hip (i cleaned up it a bit)

i wonder now if i can remove time dependency on time shift (though may be it’s just not possible and I need a stash after that)

hm, the above just leads me to an interesting conclusion
looks like `$F` (`hou.frame()` or `hou,time()`) are evaluated in simulated block context this is basically just one backdoor to inject dependency in block
it’s just one number but can be exploited already for example a packing variations of any op like this example where sdf shape dependent on frame. it’s still cumbersome but randomized contact sheet from *any* operator is quite possible

no, i think i got it wrong, here is what i got from analyzing evaluating path sorry if this is known, but i think it’s quite interesting for block programming
* Compiled block is baking block to apex graph. No expressions, all parameters are evaluated and baked – so no easy iteration and requires this hack of either layer with int or geometry with detail attribute (considering it has a feedback), parametrizing operators is very hard, at least for now, I guess in future sidefx adds additional evaluating context * Simulated block – _all_ expressions are evaluated, this is not an apex execution, it’s a live network. No need for iteration hack – iteration is `$F`. Way easier to parametrize (all expressions are “live”) but getting the result at X iteration is hacky, but easily solveable via Python COP and pulling layer at specific frame

Attachments in this post:
http://fx-td.com/houdiniandchill/wp-content/uploads/discord/20253509/23/25/sheet.gif
http://fx-td.com/houdiniandchill/wp-content/uploads/discord/20253509/23/25/sheet-as-sim.hip
http://fx-td.com/houdiniandchill/wp-content/uploads/discord/20253509/23/25/image.png
http://fx-td.com/houdiniandchill/wp-content/uploads/discord/20253509/23/25/cop-frame-expression.hip