Skybar

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.