Name attributes are the most important things when making constraints for RBDs.
Create a name attribute for your object/fractured pieces by laying down an Assemble node, without the Packed option enabled. Create your constraints with this geo (it will retain the Primitive Name Attribute, and pass it down to the Point level once you've used Connect Adjacent Pieces)
In another branch, use another Assemble node to follow up the previous Assemble node, this time with Packed enabled, but the others disabled. Now when you add your constraints to your DOP network, they'll be able to find the correct Pieces to attach to.
ALSO make sure your object names are all unique.
Names. Names. Names.
Another "quick" way to make rest lengths for your constraints is to do a Convert Line node just before the Primitive Wrangle (where you do s@constraint_name="thingy"). This is important for Hard Constraints.
A general rule for constraint types - Hard Constraints will provide overall flex between pieces.. Glue Constraints will keep the pieces all together.
Hard Constraints react to Force, Glue Constraints DO NOT.
Glue Constraints react to Strength and Impact. Hard Constraints DO NOT. *
*unless you tell them to in a SOP Solver - eg. if (@force>chf("breakThreshold")*@strength)
But this is you explicitly adding Strength into the mix... Could be any old attribute.
Friday, 8 March 2019
Wednesday, 6 March 2019
point deform tricks
The point deform node is very useful to wrap deform high res geo with lower proxy geo.
To help it along in the case of overlapping objects, you can offset the objects.
Create a point class attribute for both the high res and proxies.
Then move the pieces both high res and rest-position low-res using @P+=i@class
The deforming proxy geo will stay "as-is".
By seperating the geo in this way you can avoid "some" intersections...
To help it along in the case of overlapping objects, you can offset the objects.
Create a point class attribute for both the high res and proxies.
Then move the pieces both high res and rest-position low-res using @P+=i@class
The deforming proxy geo will stay "as-is".
By seperating the geo in this way you can avoid "some" intersections...
Monday, 14 January 2019
set animation curves to infinite, etc.
In the graph editor, right click the channel (eg. translate Y) and click Channels>Channel properties..
Here you can change the In and Out to whichever infinity-behaviour you'd like.
Here you can change the In and Out to whichever infinity-behaviour you'd like.
stick noise to geo
Something super simple and dumb that I'm surprised I've never used beforehand!
To keep a 3d noise value from,say, a point-vop sticking to Geometry, make a rest-position value before the object is meant to start animating. There is a handy Rest SOP for this.
To keep a 3d noise value from,say, a point-vop sticking to Geometry, make a rest-position value before the object is meant to start animating. There is a handy Rest SOP for this.
Tuesday, 2 October 2018
emitting only 1 particle per point per frame
Obviously stole this from ODforce:
if you want just 1 particle emitted per point at a given frame, the basic expression would be in the rate of the source node of your pop network
if you decide to put it in the impulse rate :
npoints(opinputpath("../",0))
and turning off the const. activation
if you decide to put it in the const rate
npoints(opinputpath("../",0))*$FPS
and turning off the impulse activation
don't forget to put the emission type to points(ordered) or you won't have a particle per point
this will hower emit the exact amount of points your emitter sop has per frame, so if your emitter has points that last 2 frames, you'll have 2 particles per point after 2 frames.
*Also, you could use $NPT/10 instead of npoints... Dunno if this works
When would you use this?
If you have a source which is changing point count each frame, eg, a pattern of cracks being animated (like when Godzilla is underneath a road)...
I think the $FPS version helps when it comes to substeps etc like with Maya, where you need to divide the perframe emission to account for the substeps...
The first option works well if you divide the emission count (just add a /10 or whatever after the expression)
Monday, 25 June 2018
Gas field in specified area, alternate...
But wait, there's more!
Another approach I've found on the webs, is to make a Gas Match Field, which makes a new field based on some other value.. eg. Density or Temperature.
You can actually specify a Density that is not the Pyro-sim's density, by using a Source Volume (turns out they don't always have to go into the last input). Point that to your custom volume
Finally, set the control mask to your new field.
All three of these nodes should be plugged into a single merge, which then goes into the Velocity Update of the pyro solver. (or the advect...)
I think this approach might be more flexible, if you are using it to refer to an internal pyro-value like Density or Temp?
Another approach I've seen skips the external source volume and copies the Temperature from the pyro solver itself. They use Gas Match to make a field which is "equal" in size/type to Temperature,
Next they use a gas calculate node to copy the Temperature to the custom field,
Finally, They use a gas field wrangle to fiddle with the newly created field. Normalise values, or do whatever..
They use the custom field as a mask for dissipate & turb.
Quite a neat way to mess around with the temperature.
Another approach I've found on the webs, is to make a Gas Match Field, which makes a new field based on some other value.. eg. Density or Temperature.
You can actually specify a Density that is not the Pyro-sim's density, by using a Source Volume (turns out they don't always have to go into the last input). Point that to your custom volume
Finally, set the control mask to your new field.
All three of these nodes should be plugged into a single merge, which then goes into the Velocity Update of the pyro solver. (or the advect...)
I think this approach might be more flexible, if you are using it to refer to an internal pyro-value like Density or Temp?
Another approach I've seen skips the external source volume and copies the Temperature from the pyro solver itself. They use Gas Match to make a field which is "equal" in size/type to Temperature,
Next they use a gas calculate node to copy the Temperature to the custom field,
Finally, They use a gas field wrangle to fiddle with the newly created field. Normalise values, or do whatever..
They use the custom field as a mask for dissipate & turb.
Quite a neat way to mess around with the temperature.
Gas field only in specified area. Stolen from the Sidefx site
-
In the DOP network, add a SOP Scalar Field node after the Pyro object.
-
Turn on Use SOP Dimensions.
-
Set the SOP path to the path of the fog volume object (for example
/obj/mask_object
). Make sure Use Object Transform is on. -
Set the Data Name to something indicating the purpose of this field, for example
NoiseMask
.
-
-
Create a Gas Turbulence node and connect it to the fourth ("Advection") input of the Pyro solver.
-
On the Bindings tab, set the Density Field to the name of the mask data, for example
NoiseMask
. The effect of the node is multiplied by the value of this field. -
Use the controls on the Turbulence Settings tab to control the amount of turbulence added.Important thing to note - by default the control field will not be 100% in control.. You'll see some "leakage" of turbulence. This is because the Control Influence is set to 0.5 by default.. Whack it up to 1, and maybe tweak the remap-graph to fine tune the effect of the turb/whatever.
-
Subscribe to:
Posts (Atom)