Jump to content


Popular Content

Showing most liked content on 10/02/2020 in all areas

  1. 1 point
    Only sharing files and links for peoples that want to learn ..including mine self Here its snippets(File) useful for Tricks and Links for Video Tut INC ...WITH FILE. https://vimeo.com/454127040 https://vimeo.com/207724703 https://vimeo.com/305429043 uiHud.hiplc
  2. 1 point
    Currently working on a from-scratch texturing procedure that simulates water running down surfaces. Models shamelessly taken from @animatrix course files. Starting with projected points, the curves run along a volume until they drop onto the next underlying surfaces using nested while loops. The watery effect is achieved in COPs where the texture is drawn based on measuring distance from texture positions to these curves. Alright, enough art, here comes the proof of dripping :
  3. 1 point
    Thank You for those beautiful Solutions and Tricks
  4. 1 point
    Point cloud based / smoothed occlusion texture going the 2D voxel field / SOP import route. This time featuring a butter squab ; ) texture_occlusion_VOL.hipnc
  5. 1 point
    The `transform` 3x3 matrix intrinsic controls both rotation and scale. If you're assigning rotations based on quaternions, you're going to run into scale issues because quaternions can't contain scale information. The `w` attribute is for angular velocity, not rotation, so it won't help you here. What you can do is use cracktransform() in VEX to extract the scale from a matrix as a vector, then use the `scale()` VEX function on your rotated matrix to scale it back to the original value, either before or after your rotation (depending on whether you want your scaling to happen in world or local space). You could also consider using MOPs Apply Attributes to handle this for you.
  6. 1 point
    Hi @lobao, Thanks for following up the progress. Regards a paid tutorial, I think a tutorial is not enough, it has to be a Masterclass or something more robust, this method is not a simple one to deal with, also the pipeline is made out of many different stages that has to be explained in a nice way without overwhelming too much the attendants, so I'm trying to find the best way to do this, maybe a Patreon or a a collection of hips on Gumroad. A Patreon is a good idea, I have many techniques and tools to show, so I think that method would be nice, or maybe people is searching for another way to learn. Who knows! Anyway thanks again to be interested! Alejandro
  7. 1 point
    Hi guys, this is a case of waterfall effect breakdown. Hope you like it ~ https://vimeo.com/vfxgrace
  8. 1 point
    or most of the times you may want to do the opposite, keep your Input_1 as your main stream, but copy the attributes you are accumulating from Prev_Frame geo as a first step as most of the times there is more animated attributes on your source geo than just P, this will keep them all being updated, just selected attribs will be accumulated
  9. 1 point
    In Alejandro Files, AutoDopNetwork>pyro(Smoke Object)>Fields>Rest is checked on but AutoDopNetwork>pyro(Smoke Object)>Initial Data>Add Rest Field isn't checked neither AutoDopNetwork>pyrosolver1>Advanced>Rest Field>Enable Rest. So how can it produce Rest datas? You can see that if you middle click on import_pyro_build>import_pyrofields there are no rest.x rest .y and rest.z, they do appear if you check the Add Rest Field and Enable Rest as previously mentioned. So i don't really understand how the Alejandro file is interesting for the "Rest" purpose. Maybe i miss something. It's good for the explosion rendering. This next thread is a good answer: http://forums.odforce.net/topic/20659-fluid-simulation-what-is-rest-field-for/ it has a link to a project that Ian generously share with the odforce community: http://fx-td.com/?p=329 This next link also help to understand, even if the provided file may turn houdini down: https://www.sidefx.com/forum/topic/31320/ The best answer i've found is in the Steven Knipping tutorials, at the end of Applied Houdini - Dynamics 2 he turns on the rest field and in Dynamics 3 (5b) he explains how to use it. The entire bundle is brilliant, you can watch the 1 out of 6 for free. It's here: https://www.cgcircuit.com/bundle-details.php?val=28
  10. 1 point
    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. 1 point
    Methods to Stir Up the Leading Velocity Pressure Front We need to disturb that leading velocity pressure front to start the swirls and eddies prior to the fireball. That and have a noisy interesting emitter. Interesting Emitters and Environments I don't think that a perfect sphere exploding in to a perfect vacuum with no wind or other disturbance exists, except in software. Some things to try are to pump in some wind like swirls in to the container to add some large forces to shape the sim later on as it rises. The source by default already has noise on it by design. This does help break down the effect but the Explosion and fireball presets have so much divergence that very quickly it turns in to a glowing smooth ball. But it doesn't hurt. It certainly does control the direction of the explosion. Directly Affecting the Pressure Front - Add Colliders with Particles One clever way is to surround the exploding object with colliders. Points set large enough to force the leading velocity field to wind through and cause the nice swirls. There are several clever ways to proceduralize this. The easiest way is with the Fluid Source SOP and manipulate the Edge Location and Out Feather Length and then scatter points in there then run the Collide With tool on the points. Using colliders to cut up the velocity over the first few frames can work quite well. This will try to kick the leading pressure velocity wave about and hopefully cause nice swirling and eddies as the explosion blows through the colliders. I've seen presentations where smoke dust walls flowing along the ground through invisible tube colliders just to encourage the swirling of the smoke. You can also advect points through the leading velocity field and use these as vorticles to swirl the velocity about. The one nice thing about using geometry to shape and control the look, as you increase the resolution of the sim, it has a tendency to keep it's look in tact, at least the bulk motion. As an aside, you could add the collision field to the resize container list (density and vel) to make sure the colliders are always there if it makes sense to do so. Colliders work well when you have vortex confinement enabled. You can use this but confinement has a tendency to shred the sim as it progresses. You can keyframe confinement and boost it over the first few frames to try and get some swirls and eddies to form. Pile On The Turbulence Another attempt to add a lot of character to that initial velocity front is to add heaping loads of turbulence to counter the effect of the disturbance field. You can add as many Gas Turbulence DOPs to the velocity shaping input of the Pyro Solver to do the job. Usually the built-in turbulence is set up to give you nice behaviour as the fireball progresses. Add another net new one and set it up to only affect the velocity for those first few frames. Manufacturing the turbulence in this case. In essence no different than using collision geometry except that it doesn't have the regulating effect that geometry has in controlling the look of the explosion, fireball or flames, or smoke. As with the shredding, turbulence has it's own visualization field so you can see where it is being applied. Again the problem is that you need a control field or the resize container will go to full size but if it works, great. Or use both colliders and turbulence pumped in for the first few frames and resize on the colliders. Up to you. But you could provide some initial geometry in /obj and resize on that object if you need to. Hope this helps...
  12. 1 point
    As you've found, it can be tricky to get objects to fly through a wall with dynamic fracturing. You can do it, but you need to mess with the collision relationships; in your case the bullet should affect the wall but not vice versa. But even if you do that it can be tricky to make sure the wall stays completely still when the bullet passes through. In this case probably better to take a cue from the practical FX guys and place small "charges" (AKA Magnet Forces) everywhere you want a bullet impact to be and have them go off in succession, ending up with a final big blast for the artillery shell. See the attached for an example. I've drawn a curve with points where each impact should be and copied a metaball to each point, then delete all but one of them as the frames progress. These metaballs then serve as the Magnet Forces that make up the charges. You could also do this by avoiding dynamic fracturing completely and pre-fracturing the wall. Then just selectively Activate and blow out pieces around the various bullet spots. Look at the PRE_FRACTURED_WALL node the bullet_blasts geo. There's a lot going on here for an intro to Houdini, but it shows some of the cool procedural nature of it. For example, you can put the Display flag on the PRE_FRACTURED_WALL node, then select the Curve node, hit Enter, and interactively move the bullet holes around. As for the substeps, you can substep the entire DOPNet, or just the RBD Solver. With dynamic fracturing the FractureSolver is a separate solver from the RBD Solver, so you're better off substepping the DOPNet itself, which makes the transitions between intact and fractured objects smoother. Good luck. bullets_wall.hip