Skybar

Test it! Also be careful, since alembic can contain sub-frame data that you might need. Caching this to a bgeo per frame will lose that.

Not sure if you want to do it that way, but a single Transform Pieces SOP works fine instead:

In this case, wouldn't you actually want || ? If you have 1 && 1 it will loop, but if one of them changes it will stop - 1 && 0. But with 1 || 0 it will still continue if either one of them is still true, so it will "wait" until both are false, 1 || 1 = true, 1 || 0 = true, 0 || 0 = false.

It doesnt guess. By default it binds @ as float. There are some predefined attributes that Houdini knows is a vector, like P/v/N and other default ones. You typically dont have to define those. But for any custom attributes you do have to declare what they are. Its a good habit to always do f@, v@ etc

if(random(@ptnum) > 0.5){ f@randrot = 45; } else{ f@randrot = -45; } Or use Attribute Randomize SOP:

Difficult to interpret exactly what you mean, example file?

Do this in a prim wrangle to create the point: int newpt = addpoint(0, @P); //create point in the center setpointattrib(0, "N", newpt, @N); //Prim normal to N removeprim(0, @primnum, 1); //Remove the original geo

Hey! You could compare the bounding boxes, and unpack only those that overlap. Here are 2 similar methods for that Hope it helps! unpackbbox_dv.hip

Hard to help without seeing what you are doing, but yes, attributes are only written and geometry is only created at the end of a wrangle after the code has been run.

You probably have some unconnected points in there that will render as a sphere by default. You can change this setting to turn that off.

I think its normal that it gets slower the more nodes you have. I once had a scene with literally thousands of nodes, mainly inside HDAs and nested HDAs (the vellum nodes are particularly nasty, many of them contain sooo many nodes). It took a good 5-10min to open that scene.

If you're doing subsequent booleans you should turn off Detriangulate, it can mess things up after the first boolean. Also be vary of cutting planes that only intersect a piece of geometry half way. If it doesn't go all the way through it will cause some big problems with additional booleans.

Slapcomps is great, if only for yourself, to be able to judge how your FX will hold up. It's usually easier to get it approved too if it looks good and is shown in context. You dont have to be a compgod, but it definitely helps. Say you're doing sparks, showing the particles against black will probably get you nowhere - but if you apply a glow and put it on the plate with some basic roto it might get approved straight away. It depends on what effect you are doing too, a rigid body sim might not need a lot of comp but a magic effect is probably consisting of mostly comp to create the effect.

Its probably because a wrangle is an HDA, and it seems to only show the cooktime for itself and not what it contains. You could always send in a bug for it!

It's something with transforms. If you look inside the HeightField File SOP, it samples the COP in the XY Plane and then transforms it to ZX. If you do that too it will work.

Not exactly sure what is going on, but if you unlock the smokeobject and change the Voxel Sampling to Edge XZ on the flame field it will match. Thats the only thing I changed. Or you can transform your source field with half a voxelsize in X and Z (0.015 in this case), seems to have the same effect pretty much.

It's usually easier (and more inviting for people to help) if you share a hipfile showing where you are stuck, it can be difficult trying to decipher what you are trying to do let alone fix it through text.

Yeah seems a bit weird. Probably an attempt to solve something with math (tying it gravity?) instead of just exposing the correct parameters. Which is weird if it's supposed to make it simple, because we get a few more parameters that are harder to understand for buoyancy - instead of just having the 3 well known ones (direction, amplitude and ambient). Delete that expression in Bouyancy Lift on the Gas Buoyancy DOP and use it normally seems to work well.

Depends on what you mean exactly. In your example you can create a detail attribute and grab it in the parameter with expression, for example: detail(opinputpath(".", 0), "amount", 0) That will grab the value of detail attribute called "amount" from the node that is connected in the input.

The OpenCL node errors in your scene for some reason (im on 18.0.416), so can't test. But your problem is most likely reading and writing to the same attribute in the same kernel. You want to use a Write Back Kernel for this. If you hover over the "Use Write Back Kernel" it explains a bit what happens.

For most volumes you will need a velocity volume and use velocity blur. For this case you could also create the volume -> pack it (Pack SOP) -> then move it with a Transform SOP. The transformation data will then be on the packed object and it will blur correctly.

I think the main problem is that you are adding disturbance everywhere all the time. A popular method is to use the speed of the velocity field as a control field for example, so you scale the disturbance amount with how fast the smoke is moving.

For Deformation Motion Blur (stuff happening in SOPs), you have to set "Geo Time Samples" to at least 2 on the Mantra ROP.

Too much disturbance probably.

VDB Activate -> Expand