Jump to content


Popular Content

Showing most liked content on 03/27/2020 in all areas

  1. 3 points
    here you are: - if you're not into crop circles...then simply disable plasticity in vellumhair - dive inside vellum solver, I've added the popaxisforce which gives you torus shape, I haven't played with it too much, it's there for you to experiment with just enable it, prolly wise to disable the popfan. (chuck my HDA into C:\Program Files\Side Effects Software\Houdini 18.0.xxx\houdini\otls) vu_HeloWind.hiplc
  2. 1 point
    Hi, in this tutorial you will learn procedural animation with powerful procedural tools in Houdini. Excellent for Beginner Houdini users, users migrating from other 3D content creation packages (e.g., Blender, 3DMax), anyone interested in Houdini and use it in procedural animation. Download for free: https://artstn.co/m/oJoN WHAT'S INSIDE? 5 Video Chapters (117 min. of tutorial) Houdini Project File INTRODUCTION Chapter 1 Dividing Geometry Into Blocks - 22 min. Chapter 2 Gradual Emergence of Pieces - 15 min. Chapter 3 Procedural Animation of The Crane - 32 min. Chapter 4 Modeling The Crane - 24 min. Chapter 5 Metal Scaffolding - 24 min. TOOLS Houdini 17.5 / 18 MINIMUM REQUIREMENTS Houdini Beginner Download for free: https://artstn.co/m/oJoN
  3. 1 point
    could not resist a simple softbody drop.
  4. 1 point
    You're correct Nobbini, I should have included my .hip file and I apologize for that! Next time I will think a little bit more when I post something. I appreciate you taking the time to reply back and help me out with this situation.
  5. 1 point
    Here is a slight addition. A downward smoke simulation to emulate ground dust kick up. ap_helicopter_dust_test_10.hipnc
  6. 1 point
    Okay so finally I just forgot to check one option in the local scheduler of the top. I used a rop geo with 12 cores enabled and now it's working at a tremendous speed ! I need to use tops more often ! You were right Atom ! Cheers,
  7. 1 point
    excuse me while i channel Stephen Hawking for a sec: The Singularity at the bottom will make your proposal an impossibility. Therefore, you must create your own event horizon by clipping the singularity to facilitate the opening of a wormhole Allow me to demonstrate, please scrub timeline and you'll see my theory in action The remaining task now is to simply merge with a grid. Which for an intellectual giant like me considers a task for the plebs. Good day, Cheerio. vu_SphereUnfolds.hipnc
  8. 1 point
    Your source for the points to copy are from an RBD simulation, so they have a v@pivot point attribute, which the Copy to Points SOP recognizes and will apply to the resulting geometry. If you just delete v@pivot, you'll get your copies centered on the input points.
  9. 1 point
    Check out the Daily HIP website. You might be able to use the toroid velocity field. https://dailyhip.wordpress.com/2017/01/17/toroidal-velocity-volume/
  10. 1 point
    just my 2 cents on prep stage...sure I don't know what else you got planned but for me: - have a page - copytransform across -copytransform up done, you can have any count in any direction, spacing...blah blah...in 2 nodes. - or could even just copy to points of one grid (the grid gives you all the dims of a book shelf you need, why bother with measure, it's all in the dims of the grid)
  11. 1 point
    Vellum will simply take geo at the start frame and runs with it, there are no velocities at the first frame so it just falls down you can use Vellum Pin Constraint for example Stopped and Match To Animation, which will try to match the animation of your incoming RBD sim then inside of the Vellum Solver you can unpin any point at any time you want, in the example file I'm unpinning all after frame 10, but you can art direct it per page or even per point, or based on attributes if you for example have attribute that specifies time since the page was moved, etc... book_question_forum_fix.hipnc
  12. 1 point
    Hey, what tutorials have you seen? could you give more info on this please?
  13. 1 point
    Modifying geometry inside wrangle/VOP node has nothing with internal node's local variables which refer input geometry . So, @numpt is the number of points of connected geometry to first input and it is used to form an internally hidden a FOR loop with iterator @ptnum. So think of your code in point wrangle node as code inside FOR loop which is hidden. Adding or removing points will not impact values of @ptnum or @numpt inside that loop (whole your wrangle code). Function for adding point returns an index of new added point and that has nothing to do with @ptnum or @numpt values. However such index can be forwarded to almost all functions which require point number. Adding point occur immediately (not in visual manner but in internal data structure it exists as regular point) but removing point not. Function remove point only mark points for deletion which occur internally after whole loop is finished. That apply to all wrangle node types with one exception. DetailWrangle node doesnt form internal loop of any kind so iterator value like @ptnum or @prnum doesn't exist. Values of @numpt or @numpr are still valid because they are referencing input geometry. Those hidden FOR loops can be easy "visible" by comparing a code inside PointWrangle node: setpointattrib(0,"myattr",@ptnum,1,"set"); with a code which has identical behavior but written in DetailWrangle node: for(i@ptnum=0; @ptnum<@numpt; @ptnum++){ setpointattrib(0,"myattr",@ptnum,1,"set"); } This is valid code. @ptnum doesn't exist in DetailWrangle as reserved variable so you can use it like you would use any other variable. I chose it just for illustrative purpose because those two lines for comparison are identical that way. Any context insensitive code written in PointWrangle node can be copy/pasted in such loop in DetailWrangle node and it should work fine. For example, context sensitive code is: i@myattrib=5; and that will not work because that line of code if executed in point context will create/assign point attribute "myattrib". If it is executed in primitive context it will create/assign primitive attribute "myattrib" etc. But if that is written as context insensitive function call setpointattrib(0,"myattrib",ptnumber, 5,"set"); that will work doesn't matter in which context is executed as long as you can provide handle (the very first argument in most context insensitive functions) and index (not required in all functions). Now, consider your original code inside PointWrangle @group_basePoints = 1; vector npos = point(1, "P", @ptnum); int newpt = addpoint(0, npos); setpointgroup(0, "basePoints", @ptnum+@numpt, 1); if you change it to be context insensitive it would looks like this: setpointgroup(0, "basePoints", @ptnum, 1); vector npos = point(1, "P", @ptnum); int newpt = addpoint(0, npos); setpointgroup(0, "basePoints", @ptnum+@numpt, 1); Copying such code in DetailWrangle loop from previous example and voilaaa .... it works. Now you are probably more confused Same code works one way and not the other way. To keep track what actually happened modify code like this setpointgroup(0, "basePoints", @ptnum, 1); vector npos = point(1, "P", @ptnum); int newpt = addpoint(0, npos); setpointattribute(0,"np", @ptnum, newpt, "set"); // this is new line setpointgroup(0, "basePoints", @ptnum+@numpt, 1); Now, watch spreadsheets on both DetailWrangle and Pointwrangle nodes with this same code. You can see results of addpoint() function in that np attribute on each point. In the case of DetailWrangle, all execution is done on single thread and result of addpoint() is incremented each time, as expected, and that's why that last line of code works. In the case of PointWrangle node, different values are consequence of multi threaded execution. You should always have on mind, that execution of PointWrangle will start on multi threads in parallel. So from the aspect of single point on some execution thread, result of single calling addpoint() will always return @numpt. If you modify your code in such way that, single point calls more than one addpoint(), their results will be @numpt+1, @numpt+2 and so on. In the moment of execution, result of addpoint() function is not synchronized among other threads, thats why each execution thread get @numpt value as the result of first such call, @numpt+1 for second call etc . First synchronizing barrier for them is at the end of thread execution and that is end of your code. That part is hidden from user. So, as long as you use returned value in the rest of code, you are sure you are addressing just added point(s), doesn't matter if those values are same among different threads. So line: setpointgroup(0, "basePoints", @ptnum+@numpt, 1); will fail in each particular thread because, each thread added only one point and each thread gets @numpt as the result of addpoint() and your code is trying to address point with larger index. You can change that line only in PointWrangle node just to see result: setpointgroup(0, "basePoints", @numpt, 1); and it will work. BUT, whole this is written only for behavior testing purpose so you can see differences in execution logic. In your real code you would NEVER use such "tricks". Especially because such things depend on internal design which could vary with every new version of Houdini. So as long as you stick to rule to use returned point index of addpoint() function, you are sure it will work regardless of "what is behind". So proper line would be: setpointgroup(0, "basePoints", newpt, 1); as Skybar already pointed. cheers
  14. 1 point
    you could use the Polypath node. Might have to use a join node first after merging.
  15. 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...