Welcome to od|forum

Register now to gain access to all of our features. Once registered and logged in, you will be able to contribute to this site by submitting your own content or replying to existing content. You'll be able to customize your profile, receive reputation points as a reward for submitting content, while also communicating with other members via your own private inbox, plus much more! This message will be removed once you have signed in.


  • Content count

  • Joined

  • Last visited

  • Days Won


galagast last won the day on May 5

galagast had the most liked content!

Community Reputation

82 Excellent


About galagast

  • Rank

Contact Methods

  • Website URL

Personal Information

  • Name
    Jeff Lim
  • Location

Recent Profile Visitors

4,366 profile views
  1. I'm ran into an issue where: I have a default resampled Line. Calculated Normals using PolyFrame set to First Edge. @N: { 0,-1, 0 } Reversed the Normals using Facet. @N: {-0, 1,-0 } Scattered points, inheriting Normals. @N: { 0, 1, 0 } Finally used a wrangle to check if Normals == {0,1,0} The results were a bit random. Sometime it is true, sometimes it is false. I did find a couple of solutions to work around this for what I was doing, but I believe something in this simple sequence of nodes is not doing its job properly. I just wanted to hear your thoughts about this before (or even if I needed to) send this as a bug. Thanks! negative_zero.hiplc - H16.0.600 Indie
  2. Are you maybe able to do simple copy stamping on a switch node? (Use the Copy [Stamp] SOPs, and check out the stamp() hscript function)
  3. This was a bug, ID = 82496 and was fixed in 16.0.598 But the two suggested methods above works like a charm! Exactly what I was looking for. Thanks guys! I was also able to send an RFE for a direct python way to create the dialog. ID = 82519
  4. Hey Jim, any chance you may have accidentally adjusted the Network View Display Options? Press "D" over a Network View and check out the slider for Maximum Node Name Width. That might be it Mine by default is set all the way to the right.
  5. Although I'm still hoping that there should still be a much simpler setup.. If only there was a way to avoid setting up multiple volumes, and just use the existing collision volumes. Then continue with the attribute approach to set a particle as colliding / not colliding. Need more time to experiment with this! hehe
  6. I tried a couple of things, but in the end, it still had a bit of an effect to the fluid whenever it passes through the collision. I've only minimized the effect.. check the file out to see if it is something highly noticeable. changes/notes: Removed the Fluid Source at the SOPs level because particles are the only ones needed in the setup. Removed the Threshold Collision Weights DOP as the Flip Solver was already doing the same internally (albeit on a different sequence). I increased the Gas Particle to Field -> Max Extrapolate Cells, in the hopes to extend where the cWeight gets applied. H16.0.557 Indie - collisionWeights_v001_jlim_fill_test2.zip
  7. @WhyGee: any chance you could post a sample file? I'm curious why it does that.
  8. Heya Atom, This is honestly the first time I tried looking into what the divergence field does. I've been seeing it before but never bothered using it. Thanks to you, I know now what it actually does I adjusted the scene, hopefully it is what you were after, notes are below: You added a source volume that should pipe in a divergence field, but your volume path is pointing to "/obj/geo1/OUT_source". This source (from Alejandro's setup) does not contain volumes, it only has particles. So the effect is that no divergence data is being written to the divergence field of the sim. You could probably create a new Fluid Source SOP to generate a proper volume for the divergence field, then source it afterwards. Or, in the hip file setup attached below, I simply added a @divergence attribute to the particles and used the Flip Solver's "Divergence by Attribute". So far, the sim does seem to spread out a bit more after adding the divergence. I hope this helps! H16.0.557 Indie - ap_collisionWeights_v001_jlim_2.zip
  9. After studying Alejandro's file, I adjusted it a bit so that you won't have to edit the flipsolver HDA. Here are my adjustments: Pulled out three nodes related to computing the collisionweights. Set the Volume Motion -> Collisions -> Volume Fraction Method to None (to disable internal collision weight computation). So far, everything seems to still work as before H16.0.557 - collisionWeights_v001_jlim.zip
  10. You have an awesome start man, no worries. I can see that you did try and do a lot of experimenting. I'll try and clear up some things for you (to the extent of my knowledge). Be ready for quite a bit of reading. How do I get the gradient working in the vop First off, to better understand how to manipulate volumes, you must first have a clearer idea what a volume really is in Houdini, especially what kind of data it holds. Because these data are the stuff that we going to be manipulating. Let's start from scratch.. a simple Box polygon: Box Let's convert it to a Volume primitive using an IsoOffset SOP (or a VDB from Polygons): Fog Volume Notice the default settings, it is of Output Type: Fog Volume. So from a Box which consisted of points and polygon primitives, we now have these: What happened to the data? Where are the Box's points and polygons info? Those are now gone, you now have to deal with voxels instead. Volume Representation I'm guessing you know much of this already, but just bear with me for a bit Now, I think this is where the interesting part comes in.. How are these voxels accessed in Houdini? You can think of it as manipulating images in Photoshop.. or more precisely, manipulating pixels, but in 3d. The simple description is that voxels are just 3d pixels. So let's keep things simple.. if for instance, we just take a "slice" from the 3d voxel grid like so: Volume Slice We will be left with just this simple 2D flat grid. We could now safely assume that this grid also has coordinate data, like a standard digital image, it has pixel x and y coordinates. X & Y Coordinates Going further to simplify things, let us isolate just the x coordinate for now: X Coordinates Only Notice that these are just rows of repeating sequence of numbers going from 0 to the max resolution of an axis --- in this case up to 9: Max Resolution in X is 9 To recap a bit, we now have a bunch of data to work with: * X Axis Coordinates = {0,1,2,3,4,5,6,7,9} * X Axis Resolution = 9 At this point, you might ask what can we do with these numbers? We can now use it for our Ramp Parameter. But an intermediate step is needed first. Something that is usually called normalization. We need to normalize it.. which basically means convert it to a range between 0 and 1. Mathematics and Computers just love em zeroes and ones! To go about doing that, the simplest way is to do division math. We divide each value in an X Coordinate by the X Resolution like so: The result thereof: Now we have usable values for the Ramp! We can now proceed to feed it to the Ramp and remap the values to build our custom falloff. Here is the manually adjust ramp to represent the falloff for the X Axis: And the resulting values of the remapping: Finally, almost done, we now have the falloff computation and what we need to do is to just pipe these values out as the Density. In VEX, you can see this happening as the last line of the code: In VOPs, you simply wire it out to the Density output: * Remember, since we're manipulating volumes.. we need to use the Volume VOPs variant in SOPs. The resulting volume now looks like this: As you may have noticed, this is just the X-Axis. The last and easiest thing to do is to simply repeat/duplicate the process for the remaining Y and Z axes then multiply them together to form the 3d falloff volume. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Now loaded with the information above, here is how you would apply it in VOPs: First, this shows the equivalent built-it variables that I used in VEX for Volumes: Left: Wrangle | Right: Volume Vop Next, following the 1st block of vex code, we do the conversion from "Integer" to "Float" so that we could divide the values with much more precision. Also, I subtract 1 from the resx, resy, and resz variables because the resolution value returns an amount that did not count from 0. Image showing just the x-axis setup. Apply the same nodes for the Y and Z axis. The 2nd block of code now deals with using the computed value (which is now in the range of 0-1) for the ramp. TIP: Use the same name for the Ramp Parameter for each of the axes to have just a single Ramp Parameter control up the UI. So even if we dropped 3 Ramp Parameter VOPs, with using just a single name "myRamp", there would only be one control to rule them all. Finally, on the last line. We just do a simple multiplication for all 3 values and write it out to density. And of course, here's the updated file: H16.0.557 Indie - box_falloff_vop.zip How do I visualize my gradient to check its working? You must be confusing the term/variable that I used in the Volume Wrangle whose names are "gradx", "grady", and "gradz" as the equivalent of the Volume Gradient VOP, which is actually not. These names are arbitrary, I could have named the variables anything.. like potato: ..And this will still work. So, for rebuilding the box volume falloff, you don't need the Volume Gradient VOP (I'll try and may do a separate explanation of this on a different post >_<) Maybe to rephrase your question: "How do I visualize my volume to check it's working?" And to answer that: For quick and simple visualization, I usually just use the Volume Slice SOP. Play around with it to see what it does. How do I get that inside the DOP to drive the force? I hope this graph would help you visualize the flow: On my example hip file above this post, if you check the Pop Wrangle node inside the particle sim DOP, you'll notice the Inputs tab. That is how the wrangle is reading the falloff volume we created from outside the DOP network. In the VEX code, by using the volumesample() function, we can then transfer the density volume data to our particles using any custom attribute. In this case, I simply created and named it "amt" for amount. (again it can be anything, like banana) Using our newly created variable "amt", it can then be used in inside vexpressions to do our calculations. Like multiplying it against the Force parameter to control the intensity. Note that this is just one method of getting data from outside Dops. You'll discover other ways as you venture out here in the forums I hope you did not fall asleep from this long post, and that my explanation at least made some sense haha Cheers!
  11. Hi, I did a quick check on the mentioned nodes, here's what I discovered: It's possible that the docs was referring to H14's Particle Fluid Surface SOP. Back in H14, that SOP was not an HDA (you cannot dive into it). In the newer versions, the Particle Fluid Surface SOP became an HDA, and once you dive inside, you'll see that the default Method of "Average Position" is internally using the recommended VDB From Particle Fluid SOP. A mention of it can also be seen in a more complete description for the Method parameter in the docs. On my last liquids project, I did use the new Particle Fluid Surface SOP and rendered it as a mesh. Here's a bit of what it looked like in flipbook: I guess it would depend on what look you're going after. Maybe for pretty solid/opague stuff, go with meshed particles. But for softer/smokey bits, go for VDBs/Volumes? As for lava, I usually see samples that looks like meshed particles.
  12. Are you referring to the wrangle that created the box falloff? I was initially gonna do it inside a vop If so, are you up for a bit of a challenge? Could you try and convert that to a VOP? Afterwards post your progress here so that I (or any other member) could maybe throw some pointers?
  13. A-W-E-S-O-M-E!!! I'm digging through it now. Hey Atom, it seems to be missing a custom node to generate velocities. I replaced it with a simple wrangle and a direction vector.. now it seems to be working as intended. I can see the liquid being emitted from the outside, then it passes through the collision, yet it remains inside the sphere. Realy cool setup Alejandro! Thank you for sharing! This opens up quite a lot of workflow options for flip that I wasn't aware of
  14. Just updating this thread for those who may encounter a similar problem in the future. As the anomaly seems to stem primarily from my use of VOP COP Filters, I got a suggestion from support to instead try and use a COP Input VOP instead of Bind VOPs for pulling other planes from any input. I will see if this alleviates the problem on my next venture into COPs. They also mention that the bug is still being investigated. RFE #82228
  15. Hi, Try out this sample file: I used a box density volume, and wrangled it to create a falloff. This is then sampled by the a Pop Wrangle which creates an attribute used as a multiplier for any Force (via vexpressions). H16.0.557 Indie - box_falloff.zip