Community Reputation

About jamesr

Personal Information

Oh yeah I see that. I guess that sort of works, but I'd stay away from doing it that way since it's not really working as expected. You shouldn't actually need to put the v@ in the second wrangle in this case.

If all you want is a static noise field for the pyro to swim through, you can just use a curl noise in a gas field vop. If you want, you can just copy and paste the one inside the Gas Turbulence microsolver inside "compute_turbulence".
Inside the gas turb, it uses a vec4, with the fourth component after the position vector being time. So it doesn't matter if the pulse duration is off, it's still moving through time by default, because pulse duration is connected just to the offset parameter. You can unhook this and just use pos (vec3) to drive the position of the noise and run your pyro through it.

The problem is that you're mixing vex variables and attributes. The following code is incorrect (not really sure why it's not erroring out...)
@Cd={0,0,0};
vector @a1={0,0,0}; // Here is your problem
f@b=0;
@Cd=fit01(relbbox(@P), 0.5,1);
@a1=fit01(relbbox(@P), 1,0.5);
instead of doing
vector @a1
you want to declare the vector attribute as
v@a1
Here's your file with the stuff fixed. I like to prefix the attributes with f, v, p, 4, etc all the time when I'm coding. You don't technically have to each time, and I don't think most people do, but it helps me avoid any confusion on the type especially in places where houdini is pickier about it, like in DOPs.
I also added some spaces to make it a bit more readable . You may want to consider getting more descriptive with your attribute/variable names!
q1_fix.hipnc

Here is how I would approach this:
1. Draw out 10 curves. This will give you 10 primitives. Make a merge node and connect them all in there. After that, connect a null and call it something like "REF_ALL_CURVES"
2. Make a primwrangle. Create an attrib called something like "prim_id" and make it equal to primnum (i@prim_id = i@primnum).
3. Make a Null and call it something like "CONTROL". Add an int parameter to it called "cluster" or "wedge"
4. Put a blast node and in the "group" parameter, set it to @prim_id==`ch("../CONTROL/wedge")` and set the entity to "primitives" and "delete non selected". This will isolate one curve at a time
5. Drop another null as a reference point and call it like "REF_CURVE" so you can easily point to it later
6. Do your particle sim as normal. For the curve input, point it to that REF_CURVE null
7. Do your DOP import however you wanna getting the particles out of DOPS. After that lay down your cache node.
8. Inside a ropnet, or the /out context, put a wedge ROP. Uncheck random samples, and click the + sign to add a wedge parameter. Inside "channel" point it to the parameter on the CONTROL node you made in step 3. Set the range to be 0 to nprims("../path/to/REF_ALL_CURVES")+1 . This will keep it nice and procedural.
9. In the cache node, make sure to change the file name! Pick whatever directory you like, but make sure to add $WEDGENUM to it so it will write different sims! Here's an example of a path:
$JOB/geo/magicdust/v001/magicdust_particles_v001_$WEDGENUM.$F4.bgeo.sc
10. On the wedge rop, hit "render wedges". Check the directory to make sure it's all working...
11. To bring them back in, just make a for each (number) loop in sops. Connect a file sop to it. There should be a 3rd node, the meta import node, which I usually rename to "m" for shortness.
12. In the file sop, construct the same filepath, but instead of $WEDGENUM, do the following:
$JOB/geo/magicdust/v001/magicdust_particles_v001_`detail("../m", "iteration", 0)`.$F4.bgeo.sc
This will load all your sims back in!
Good luck! I hope I explained it okay.

I think if your shot is laid out, and you know where the explosions are going to go, pre caching a few and either scattering or hand placing them ia the most flexible route. If you or your sup don't like a certain sim, it's easy to just swap in a new one or add more in certain places and rotate/scale them

Hmm I see what you're saying. But would it be difficult to just sim 3 levels of detail? Like a lo/med/hi and assign that as an attribute to your instance points so it picks up the right foreground/midground/background sequences?

I think a good approach for you would be to develop a sort of "master" sim that has the look of the explosion you want. Or, if they are to be drastically different, maybe 3-4 main sims.
You could then run them as wedges, changing different "seed" parameters (like seed and offset in various noises, etc) to get different slightly different looks.
If you name them like
explosion_$WEDGENUM.$F4.bgeo.sc
you'll get a set of explosion sequences. Then you can scatter some points, and give them some random rotations about their Y axis (just turning one explosion 90degrees can sometime give you as totally different looking explosion depending on the camera!)
You can load the vdbs as a packed prim and use an "activation" or "index" attribute to say what frame you want to the explosion to start on, and set the unexpandedfilename intrinsic to load different frames on the points
(see toadstorm's post for a better explanation at the bottom)
Loading the caches in as delayed load VDBs will be quite efficient at rendertime, too.

First you could start by checking out Mixamo for dancing models. That part should be pretty easy to find online. The rest is pretty straight forward. If you're not sure of what to do, you should definitely start with the shelf tools. probably the "Emit Particle Fluid" one. The important part is going to be computing the velocity first though. Before you activate the shelf tool, lay down a "Trail" SOP and set it to "Compute Velocity". This will make sure that the interesting point velocities that you're getting from the dancing motion make it into the fluid.
You can scale that effect by changing "scale source velocity" in the sourcevolume node in DOPS. The rest should be fiddling with some turbulence forces, gravity, drag etc to your liking. You can also use POPs in the Particle input of the solver and Gas nodes in the Gas input, since FLIP uses both.