JohnMarston

https://www.sidefx.com/index.php?option=com_forum&Itemid=172&page=viewtopic&p=188167&sid=2598370321780a68a52c6b00644fefa7 Might be the issue- I haven't opened the .hip so I hope it is!

You're a saint, thank you!

Hi, I've run into a bit of a pickle where I'm trying to scatter based on a map. This would be all well and good- pipe the luminance into Cd, scatter based on Cd- but the geometry I'm trying to scatter on is basically a single polygon. There are no points with which to interpolate the Cd attribute. Is there a way to have Houdini scatter based on the map applied to UV coordinates without Houdini just interpolating in between the UV values on the points? see attached file for the issue- works fine with tons of geo, not so fine without any. scatterOnMap.hip

You can tweak your rotational velocity directly by wiring in a geometry wrangle* to either the pre-solve or post-solve inputs on your rigid body solver and messing with the @w attribute (rotational velocity). For example, v@w *= 0.9; will set the rotational velocity to 90% of what it would normally be on each frame. This will have the same effect as applying a rotational drag to it.

@fredhopp - that's beautiful! thanks for sharing, a lot of cool techniques in there.

That's because it's a local variable (I think). You can create a detail attribute before it's piped into the popnet with an attribute create, set it's value to $NPT, and then fetch that detail attribute from the node it was created on inside the popnet (ie, detail("../../attribcreate1/","numpts",0)). Or just set the pop source emission type to all points rather than points. Much easier.

The point relax node allows one to pipe in a pscale so points of differing scale would be repelled with respect to that. I do think that your best bet would be the phyllotaxis though - by nature, at ~137.5 degrees it produces the best packing algorithm. Then you can just vary the size by a bit with some noise or pscale.

Pack the geo with another assemble sop after the first assemble (on the left-hand branch, not down through your group/foreach branch) and it works fine. I think the reason it's stretching is it's mapping each point from your input geo, of which there are much more than 6, to the 6 particles. Once it's gone through the first 6 points, it loops around and starts over again. ie, points 0-5 are "correctly" mapped to particles 0-5 of your animated geometry. Once it gets to point 6 (ie 7, because we start at point 0), it loops and maps it to your 0th particle; point 7 to your 1st particle, etc. etc. If you check the point numbers you'll see this is consistent. Give it the same number of points to work with (ie, pack your geometry) and everything works fine.

They're actually arranged via a phyllotaxis pattern, common in nature: https://en.wikipedia.org/wiki/Phyllotaxis A search on vimeo revealed this: So it's a bit simpler than you thought. Thanks nature! Should get you started in the right direction.

It still is I just upped the buoyancy lift on your file to 200 so it moved fast enough that you could notice it. I'm trying have my fire spread over gasoline from a molotov cocktail, so unfortunately it has to be moving pretty fast, otherwise this technique would probably work. gasUpresTest_Timeshift_dv.hipnc

Yeah it does! Unfortunately, I don't think it's the answer to this problem. I volume resized it to be constant, and then timeshifted, and it still has the fading effect. I threw together a quick video that shows the difference between the gasupres method (left) and the timeshifted, static size volume method (right). You can still see the stepping. It's a convincing substitute when there isn't much change in the size of the volume or the slow-motion effect isn't too extreme, but if either of those are a factor, it becomes apparent what's really happening. (Unless, of course, I'm doing it wrong somehow, haha!) comparison.mov

I haven't heard of a static volume before, and I can't seem to find it in the documentation. Would you mind elaborating a bit?

That was how I originally tried to slow it down, but it ends up not really working out- it works great for particle systems because each point has a unique ID and x/y/z coordinates that can be used to interpolate their positions somewhere in between the two frames that are actually rendered to fake the in between frame, but because pyro is a volume it doesn't work so cleanly. It introduces a stepping issue where it sort of fades from one frame to the next rather than actually calculating the motion in between. I've just thrown together the same .hipnc but with timeshift this time and set up a mantra node so if you render it out it's pretty clearly visible. Shouldn't take more than a minute or so of rendering to see what I mean. That's why I've been using the gasupres instead- it actually re-sims the in-between frames. gasUpresTest_Timeshift.hipnc

Hey all, I've been trying to take a written out pyro sim and slow it down with a gas upres setup. However, I've run into an issue where the retimed simulation seems to lose detail in the flames when rendered. I've attached both a picture that shows the example in my original simulation and then a .hipnc that has a simple example that shows the same behaviour. Has anyone run into this before? And if so, what did you do to fix it? I have a theory that it involves the shape tab on the upres solver lacking some of the parameters that the pyrosolver contains, but I'm not sure how I'd add those parameters to fix it. Thanks for any help! gasUpresTest.hipnc