The loop index always increments by one.
a) You could use a while loop and do the increment yourself.
b) You could multiply the index value by your step size inside the loop
c) You could add an extra variable that you feed back that increments by your step size to go along with the base increment.
b & c require dividing your length by step size.
Found 390 posts.
Search results Show results as topic list.
Technical Discussion » Increment of New For Loop VOP
- jlait
- 6245 posts
- Offline
Technical Discussion » flip fluid perparticle pscale
- jlait
- 6245 posts
- Offline
1) For speed the flip solver assumes constant pscale. You could open it up and turn off these assumptions in the particle transfer, but you'd run into #2:
2) FLIP particles aren't volumes, but are more like just markers. So increasing pscale affects how they transfer to the background grid, but will not affect how much space they take up.
If you are animating scale in order to get them to fatten up and take more room, you should use divergence instead.
2) FLIP particles aren't volumes, but are more like just markers. So increasing pscale affects how they transfer to the background grid, but will not affect how much space they take up.
If you are animating scale in order to get them to fatten up and take more room, you should use divergence instead.
Technical Discussion » Preventing volume loss in long FLIP sim
- jlait
- 6245 posts
- Offline
How far did you lower the magnitude? I ran at 0.02 separation & turned off equalize for testing how the gravity waves propagate. With the slow motion of a single cog + 9.8, things stay very flat as you experienced. Dropping two orders of magnitude to 0.098 and I got waves forming in front of the moving spoke.
Technical Discussion » Preventing volume loss in long FLIP sim
- jlait
- 6245 posts
- Offline
I think you are using stick-on-collisions that will lock the surface particles to the collider's speed. I'd play with those settings or disable it. Likewise, FLIP rather than APIC might give you more splash. APIC is better for preserving vortices which is what this sort of cross-directional flow should be inducing.
Very glad to hear it is stable, though. A lot easier to add splash to something stable than the opposite.
Very glad to hear it is stable, though. A lot easier to add splash to something stable than the opposite.
Technical Discussion » Preventing volume loss in long FLIP sim
- jlait
- 6245 posts
- Offline
In a perfect world, FLIP particles will never cross the collision boundary. The pressure projection is supposed to create a velocity field that moves around it, and they are supposed to follow that field. Of course, this doesn't happen, so the particle collision is needed for these wayward particles.
The “Particle” method does particle to polygon collisions. This lets you hit thin plates and things that didn't get rasterized by the collision SDF. So it is our default. But Move-Outside should usually be faster as it just need a single SDF lookup to do the detection. The kill umoveable is greyed out in particle mode because the particles are never tested against the sdf, so we won't know to kill them if they get on the wrong side for some reason.
The rotation method I refer to is when you have *no* SOP level rotation on the VDB. At the SOP level, you have your gear be non-deforming. Instead, at the object level you rotate the gears. When you bring this object in as a static collider, you don't have to turn on the use deforming geometry as the geometry isn't deforming. But you will pick up all the rotation & velocities from the object motion for free. One catch is to not use any object scales. They may work, but object-level scales will bite you eventually, so just avoid.
The “Particle” method does particle to polygon collisions. This lets you hit thin plates and things that didn't get rasterized by the collision SDF. So it is our default. But Move-Outside should usually be faster as it just need a single SDF lookup to do the detection. The kill umoveable is greyed out in particle mode because the particles are never tested against the sdf, so we won't know to kill them if they get on the wrong side for some reason.
The rotation method I refer to is when you have *no* SOP level rotation on the VDB. At the SOP level, you have your gear be non-deforming. Instead, at the object level you rotate the gears. When you bring this object in as a static collider, you don't have to turn on the use deforming geometry as the geometry isn't deforming. But you will pick up all the rotation & velocities from the object motion for free. One catch is to not use any object scales. They may work, but object-level scales will bite you eventually, so just avoid.
Technical Discussion » Preventing volume loss in long FLIP sim
- jlait
- 6245 posts
- Offline
I think the particles streaming to the center is because “Kill unmoveable particles” is off. So when particles inevitably end up too deep in the collision SDF they can't find their way out, they stay live and count against your total volume.
Anyways, from your file, some notes:
1) Large rotations like this might be best with the “Swirly”, or APIC, kernel as opposed to the “Splashy” or FLIP default.
2) Optimization: You can pre-scatter the points on your geometry before animating them. This avoids 0.5 sec substep of scattering time.
3) Optimization: The VDB resolution in collision source defaults to matching the fluid separation. But you can destroy the channel reference and build it at a lower resolution for faster results, especially when iterating & debugging. You can also turn off Fill Interior.
4) Optimization: The volume expression is pointing to the OUT_Volume which is Time Dependent. Thus you recompute that 1 second boolean every frame. Instead add a timeshift after the boolean and delete the $F expression so you only have to compute the volume once.
5) To understand what the equalize volume is doing better, you can turn on Add Divergence field on the flip object, then enable the divergence visualization. By default you get a two-tone plane that lets you know if it is trying to add or remove volume, so you can see if it is getting the desired direction right. You'll see it is desperately trying to add volume, so is correctly detecting the collapse, but isn't doing so with enough force. The “Integral Coefficient” can be boosted to do this. You can try setting the goal volume to zero and watch how quickly the volume collapses. With this test I had to boost it to 100 to keep things from compressing.
6) Substepping. Rotational motion is something that loses volume as the fluid cuts the corners as it rotates.
7) Collisions. In this case you have multiple rigid bodies that you've put into a single collider, forcing VDB creation every frame and risking something odd going on. For example, the VDB rasterization may pop between frames giving some spurious motion. Instead, if you could express them as separate objects and bring them in as non-deforming but rotating objects, it would be a help. This also means you don't have to worry about the extra points as the objects won't be moving locally. I understand this may not scale to other setups, however.
I've done some of those changes in the attached which I've simulated to frame 308 with it looking okay…
Anyways, from your file, some notes:
1) Large rotations like this might be best with the “Swirly”, or APIC, kernel as opposed to the “Splashy” or FLIP default.
2) Optimization: You can pre-scatter the points on your geometry before animating them. This avoids 0.5 sec substep of scattering time.
3) Optimization: The VDB resolution in collision source defaults to matching the fluid separation. But you can destroy the channel reference and build it at a lower resolution for faster results, especially when iterating & debugging. You can also turn off Fill Interior.
4) Optimization: The volume expression is pointing to the OUT_Volume which is Time Dependent. Thus you recompute that 1 second boolean every frame. Instead add a timeshift after the boolean and delete the $F expression so you only have to compute the volume once.
5) To understand what the equalize volume is doing better, you can turn on Add Divergence field on the flip object, then enable the divergence visualization. By default you get a two-tone plane that lets you know if it is trying to add or remove volume, so you can see if it is getting the desired direction right. You'll see it is desperately trying to add volume, so is correctly detecting the collapse, but isn't doing so with enough force. The “Integral Coefficient” can be boosted to do this. You can try setting the goal volume to zero and watch how quickly the volume collapses. With this test I had to boost it to 100 to keep things from compressing.
6) Substepping. Rotational motion is something that loses volume as the fluid cuts the corners as it rotates.
7) Collisions. In this case you have multiple rigid bodies that you've put into a single collider, forcing VDB creation every frame and risking something odd going on. For example, the VDB rasterization may pop between frames giving some spurious motion. Instead, if you could express them as separate objects and bring them in as non-deforming but rotating objects, it would be a help. This also means you don't have to worry about the extra points as the objects won't be moving locally. I understand this may not scale to other setups, however.
I've done some of those changes in the attached which I've simulated to frame 308 with it looking okay…
Technical Discussion » Preventing volume loss in long FLIP sim
- jlait
- 6245 posts
- Offline
First, note that for collisions only the velocity along the surface matter. However, these velocities are determined by finding the closest point on the collision surface & reading its velocity. In this case you have a tube which only has points at the far ends - this means the water near the sphere only ever sees stationary velocities, as there is no sample points along the arms to report local velocities. This causes the water to be surprised when the arms keep moving. To fix this, the attached adds a bunch of scattered points to the arms so there are points to read the velocities from. (This is also important for getting more accurate velocities with rotation as we only read linear velocity…)
Next, I should have checked this with the first file, since it is a very common problem. But with strange acceleration one should always double check colliders are doing what you expect in the sub-frames.
Bottom right corner of the UI, above “Auto Update” is a button to bring up the playbar controls.
Turn off Integer Playback, change step to 0.1. Then display only your collider and step forward. You'll notice it jump forward every half frame. This is because the rotation is set to $F which is integer frame, setting it to $FF will clear that up. As soon as the flip sims started to substep it would get strange teleporting colliders, thus strong discontinuities. The deforming object shelf tool hides this by turning on the “Blend Between Frames” option.
Next, I should have checked this with the first file, since it is a very common problem. But with strange acceleration one should always double check colliders are doing what you expect in the sub-frames.
Bottom right corner of the UI, above “Auto Update” is a button to bring up the playbar controls.
Turn off Integer Playback, change step to 0.1. Then display only your collider and step forward. You'll notice it jump forward every half frame. This is because the rotation is set to $F which is integer frame, setting it to $FF will clear that up. As soon as the flip sims started to substep it would get strange teleporting colliders, thus strong discontinuities. The deforming object shelf tool hides this by turning on the “Blend Between Frames” option.
Technical Discussion » Preventing volume loss in long FLIP sim
- jlait
- 6245 posts
- Offline
I would recommend using deforming collision shelf tool rather than the collision source setup. The collision source works best for Pyro and isn't recommended for FLIP now.
The popping I think is being caused by vacuum forming behind the object as it frees up new fluid cells, the fluid is under pressure from your force so gets squirted into those cells when they become available.
In attached I've also changed it to move-outside collison and delete unmoveable to ensure nothing sinks to the core.
The popping I think is being caused by vacuum forming behind the object as it frees up new fluid cells, the fluid is under pressure from your force so gets squirted into those cells when they become available.
In attached I've also changed it to move-outside collison and delete unmoveable to ensure nothing sinks to the core.
Technical Discussion » Preventing volume loss in long FLIP sim
- jlait
- 6245 posts
- Offline
You do not need a pop solver, the flip solver already has one. Instead wire your pop vop into the “Particle Velocity” input of the FLIP solver (the first purple input)
Attached I've done that & cleared the paths (as your file refers to stuff not present there…) This causes a sphere to rip apart under your force since you have different gravity in Z than you have in XY.
Note this sort of pressure-force can be unstable, you are relying on pressure projection to remove it, so any asymmetry in your input will cause things to flow.
Attached I've done that & cleared the paths (as your file refers to stuff not present there…) This causes a sphere to rip apart under your force since you have different gravity in Z than you have in XY.
Note this sort of pressure-force can be unstable, you are relying on pressure projection to remove it, so any asymmetry in your input will cause things to flow.
Technical Discussion » Preventing volume loss in long FLIP sim
- jlait
- 6245 posts
- Offline
For FLIP, I'd recommend instead to apply forces directly to the particles using microsolvers. You can use the POP VOP wired to the purple inputs to do this. Be sure to add to the force value, not replace it, however.
Technical Discussion » Take point position P.y,P.z,P.z to channel TX,TY,TZ?
- jlait
- 6245 posts
- Offline
The point expression can be used to read attributes, such as P:
point("/obj/alembic1/blast1", 0, "P", 0) point("/obj/alembic1/blast1", 0, "P", 1) point("/obj/alembic1/blast1", 0, "P", 2)
Technical Discussion » Iteration and Conditional VOP nodes woes...
- jlait
- 6245 posts
- Offline
Simon van de Lagemaat2
I've said this before but the best learning resource is a heavily annotated scene.
I like that the best myself, as well. We try to provide this through the example files on nodes. Loop VOPs seem to be lacking in those though :<
Technical Discussion » Iteration and Conditional VOP nodes woes...
- jlait
- 6245 posts
- Offline
noc2
But Jeff, that's the whole point of documentation imho. If I already knew my way around, what would be the point in seeking reference, am I right?
To be clear, I was not disagreeing with you! I was saying it isn't easy to do.
I believe our attempt to try and address the new users problem is to try and have high level pages deal with the concepts, rather than rely on individual node documentation. Individual node documentation tends to be very focused as it is often used as reference to remind oneself what the parameters did. Looking through our docs, it looks like what should have happened is you should have found yourself on this page:
http://www.sidefx.com/docs/houdini/shade/looping [www.sidefx.com]
which actually contains a link to that video. So the important questions are:
1) Did you manage to find that page?
2) Is that page useful, and if not, any ideas how to improve it?
Technical Discussion » Copy sop, point order on first copy reversed
- jlait
- 6245 posts
- Offline
N tells which way to point the Z-axis of your input. But this isn't enough information to know where to put the other two axes. They need to be perpendicular to N, but you could spin them any which way.
The up vector is to tell you which way to put the y-axis. It is rotated around N until it is lined up.
So if up and N point in the same way, you are back to the same problem of being able to orient in any direction.
The circle's curve has three main directions:
Tangent - the direction it is pointing in
Normal - The direction outwards, based on curvature
Binormal - The direction perpendicular to those two.
Thus while your N is perpendicular to the curve, so is (1, 0, 0) because your curve lies in the YZ plane.
The up vector is to tell you which way to put the y-axis. It is rotated around N until it is lined up.
So if up and N point in the same way, you are back to the same problem of being able to orient in any direction.
The circle's curve has three main directions:
Tangent - the direction it is pointing in
Normal - The direction outwards, based on curvature
Binormal - The direction perpendicular to those two.
Thus while your N is perpendicular to the curve, so is (1, 0, 0) because your curve lies in the YZ plane.
Technical Discussion » Iteration and Conditional VOP nodes woes...
- jlait
- 6245 posts
- Offline
It is very hard to write docs that don't assume you already know the answer :< I'm sorry they failed you with this.
We did do a masterclass specifically on loops with H15
https://www.sidefx.com/tutorials/h15-masterclass-loops/ [www.sidefx.com]
that tries to go into this and explain it…
We did do a masterclass specifically on loops with H15
https://www.sidefx.com/tutorials/h15-masterclass-loops/ [www.sidefx.com]
that tries to go into this and explain it…
Technical Discussion » Copy sop, point order on first copy reversed
- jlait
- 6245 posts
- Offline
The problem is that only specifying normal does not precisely specify how to orient your points. We need an up-vector as well to try and figure out how to rotate the point around the normal. In this case, the -Z point happens to pick an inverted rotation from the rest, thus the strange twist.
You can specify an explicit up vector of 1,0,0 so the normal orientation will be consistent, then adjust the transform to get the right profile, as shown in the attached.
I would recommend the Copy to Points and the new Point SOP, however.
You can specify an explicit up vector of 1,0,0 so the normal orientation will be consistent, then adjust the transform to get the right profile, as shown in the attached.
I would recommend the Copy to Points and the new Point SOP, however.
Technical Discussion » Preventing volume loss in long FLIP sim
- jlait
- 6245 posts
- Offline
Put down the Gas Equalize Volume node inside of DOPs. Click on the ? on its parameters to get the help for that node. Scroll to the bottom and there are the example files that use that node. The Flip one is the one you want. If you already have the help server running, the link I provided would work.
Compute volumes by using the Measure SOP on polygonal geometry, set to “Volume”. The use Attribute Promote to sum these polygon volumes into a single Detail volume.
Compute volumes by using the Measure SOP on polygonal geometry, set to “Volume”. The use Attribute Promote to sum these polygon volumes into a single Detail volume.
Technical Discussion » Alternate implementation of "Gas Project Non Divergent" node
- jlait
- 6245 posts
- Offline
Javid Pack2
The node seems to calculate the pressure field AND tweak the velocity field to make it divergent free. I'd rather not waste effort on something that will take me many, many hours to figure out, so I thought I'd ask here:
Isn't updating the velocity field from the pressure is just a matter of adding the gradient of the pressure to the velocity?
The code for the projection is approximately this:
1) Compute divergence of the velocity field
2) Add in the user provided divergence
3) Solve for a pressure field giving the divergence field
4) Add gradient of pressure field back to the velocity field.
If you just want to replace step #3, you can mimic the other steps by using Gas Analysis to compute divergence & gradients, and Gas Linear Combine for the addition operations.
I'm a bit uncertain if velocity is where the feature vectors should come from; there is two extra degrees of freedom here that have nothing to do with the resulting pressure that your system will have to train out. I'd suggest pulling feature vectors from the divergence field instead. Formulated this way, a deep convolutional network starts to look like a multigrid V cycle with the weights being what you train…
A research problem I'd like to see addressed is using this to learn an algebraic multigrid solver that can properly handle collisions in smoke sims with multigrid by training the correct weights to deal with collision masks.
Technical Discussion » Preventing volume loss in long FLIP sim
- jlait
- 6245 posts
- Offline
We have a volume controller you can use to adjust volume up or down. The only real problem with it is figuring out what you want the goal volume to be (especially if you have sources…) But in static sims you can usually compute the volume of your initial fluid and use that.
Put down a Gas Equalize Volume DOP and check its help card for a help card example:
http://127.0.0.1:48626/examples/nodes/dop/gasequalizevolume/EqualizeFlip [127.0.0.1]
Put down a Gas Equalize Volume DOP and check its help card for a help card example:
http://127.0.0.1:48626/examples/nodes/dop/gasequalizevolume/EqualizeFlip [127.0.0.1]
Technical Discussion » Group Combine output group question
- jlait
- 6245 posts
- Offline
You are extruding by individual components. So each face is separately extruded and generates an internal face between them.
Extrude by connected components instead.
Use the Split Group to select where to dice up the connected components to get the four separate extrusions.
Extrude by connected components instead.
Use the Split Group to select where to dice up the connected components to get the four separate extrusions.
-
- Quick Links