Jump to content

Leaderboard


Popular Content

Showing most liked content since 06/07/2020 in all areas

  1. 5 points
    Hello there I was looking for a solution on how to simulate two smoke objects with different density fields and still have them interact. I couldn't find a solution from a quick search so I thought I'd post here now it's resolved. To achieve this result you need to dive inside each smoke object and disconnect the velocity field. Copy the velocity field creation dop from within an object and attach it with an apply data beneath the merge where you bring the objects together. Set the data sharing parameter on this node to "Share Data In One Timestep" and you should be good to go. You could also share more fields between smoke objects if you don't require individual data for both I've attached a hip file All the best, Lucy multiObjectInteraction.hipnc
  2. 5 points
    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
  3. 4 points
    like this? V_test_02.hiplc
  4. 4 points
    Yes I got it (just Happy )
  5. 3 points
    by no means sophisticated but it shows the gist of setting up bendscale attrib uniformscale is a bit crude (just linear)...so you might want to jazz it up with other methods....chramp or something. vu_bendscale.hiplc
  6. 3 points
    I would rather copy spheres onto a resampled curve with varying point scale. Then apply the same number of grids onto some parts of the sphere surfaces via UVs. Alternatively you just stick with the most recent Entagma tutorial:
  7. 3 points
    Hi, You can do it like this: function int [ ] getPointNeighbours ( int geo; int ptindex; int depth; int accumulate ) { int pts [ ] = array ( ptindex ); int lastpts [ ] = pts; for ( int i = 0; i < depth; ++i ) { int newpts [ ] = { }; foreach ( int pt; lastpts ) { int connected [ ] = neighbours ( geo, pt ); foreach ( int c; connected ) { if ( find ( pts, c ) < 0 ) { append ( pts, c ); append ( newpts, c ); } } } lastpts = newpts; } if ( accumulate ) return pts; else return lastpts; } int pts [ ] = getPointNeighbours ( 0, 42, chi("depth"), chi("accumulate") ); foreach ( int pt; pts ) setpointgroup ( 0, "pts", pt, 1 );
  8. 3 points
    i think, if you want to do something custom (not using pre-made textures) the good way to accomplish this is to build as many shapes and details as possible on SOP level (faster tweaking and more straightforward). then use computed geometry maps to drive finer details in the material network. This general approach typically works great. If you need lower res geometry for rendering you can always bake everything into textures (but Houdini and Mantra typically deals fine with heavy geometry). Some time back I did this thing as a practice. The tank is textured with Substance painter but the ground and other stuff are modelled and textured procedurally. I know this is relatively simple looking ground texture, and things get more complicated most of the times, but the approach would be very similar. Only more layers. If you can't push it far enough procedurally you can always pepper it a bit with scanned details.
  9. 3 points
    here is a bit simplified setup Lamp_Example_fix.hiplc it should be possible to fully instance your lamps with lights at the end points using instance node, but I don't know the requirements of Arnold for light instancing so for now just rivetting each individually
  10. 3 points
    You solve intersections for particles with different pscales with POP Grains. That is the way to do it, unless you want to use Vellum grains, which are certainly viable but might be a little bit slower. POP Interact can only apply forces, which are not going to get you clean collisions. pop_advect_grains_toadstorm.hiplc
  11. 3 points
    hey! I was the creative director and concept designer for this. Confirming we used Houdini, lots of sop solvers, some growth stuff. Its just transforming the points from a central local minimum on the geometry, using pcopen to kinda make it fold inside itself. Then emit some fluids to advect points out of. Here's some more stills showing the geometry
  12. 3 points
    Now I get it (just Happy)
  13. 3 points
    Hi Mani, a common way to increase surface details on terrains is to use displacement maps on regular quad meshes. Texture haven and HDRI haven are good places for getting free texture sets without registration: https://texturehaven.com/ https://hdrihaven.com/ terrain_tex.hipnc
  14. 3 points
    Here is an example if you're interested. for the lowres sim, I had to change the "color" Enable Solver DOP, it required Alpha, and I didn't want that. for the upres, I just added "Cd" in the gasAdvect. As a bonus, I added a scalar field name "cdl", it's used to store/set the length of Cd on every frame, it keeps the colors visible for much longer. left: div size=0.2, right: div size=0.033 (6x upres) advect_Cd_bunker_001.hiplc
  15. 2 points
    Just sharing my 2020 Reel. Im available. https://vimeo.com/429294957 Thanks! Daniel Moreno http://www.danmoreno.com https://vimeo.com/danmoreno https://www.linkedin.com/in/danmoreno https://www.imdb.com/name/nm1625127/
  16. 2 points
    Ok...several things: First of all, get out of your head the idea that one renderer is all you need to focus on. In today's production world, especially as a newcomer you better be familiar with several render engines. Secondly, if your goal is to work for a high end VFX studio, then GPU renderers aren't really a thing. For feature films most of the larger studios use Arnold or Renderman....so learn those! With ever-changing and ever-evolving technology, when it comes to render engines particularly, you're better off with a subscription service. I would go with the $20/month Octane subscription over purchasing Redshift. In addition, Octane looks arguably better than Redshift with less effort (but ultimately they're both limited as explained in previous posts). I think GPU render speed is overly hyped for the most part. People will compare Redshift on a 4 RTX 2080ti machine vs. Arnold running on a 6-core Intel and declare that Redshift is the winner, not taking into account the fact that they're comparing $6k worth of GPU's (and one hell of an electric bill) vs. a $400 CPU. If we level the cost playing field, and compare 3Delight running on a 64-core Threadripper vs. Redshift running on two 2080ti's, then 3Delight will be faster...particularly on scenes with volumes and huge amounts of polys. On a recent test that I did between Redshift running on two 1080ti's vs. 3Delight running on a 9900k 8-core, the difference in render times was only 1 minute. If I swapped CPU's to a 16-core Ryzen then 3Delight would have come out on top and with a better looking render. And finally...don't get hung up on technology too much. Ultimately if you're good at what you do, you'll find work regardless of what render engine you use.
  17. 2 points
  18. 2 points
    Hello friend! I have a hip file available [for free of course] here: hopefully this can help you get started
  19. 2 points
    it's not exactly just like that, cause while point's hold the values and move themselves, voxels are static and values move from one to another so that's why you can't just import position from another input and hope that you get the right one but if you have evolving rest filed in your first input just bind that and use to sample the noise or if it's in the 3rd input you can use Volume Sample Vector VOP to sample 'rest' and use for your noise, still assuming your rest field is evolving and aligned with the sim or volumes you are applying noise to
  20. 2 points
    Even better! digging into the setup, love the "buddhas temple" name xD Did a quick test with vellum, its not the real movement but wanted to saw this beauty in motion, I might tweak the petal, drop into substance painter for some texturing and explore that chramp scale.
  21. 2 points
    Hey guys, I started making procedural trees, I'm happy with where I am at the moment, good start
  22. 2 points
    good point Andrea. too many reasons to list here, but here are a couple - no extra field is created in DOPs, it saves memory. no extra nodes to create the mask field. - more flexibility: you can noise up the mask field directly in VOPs for example. personally I avoid VOPs altogether, it gets messy real fast. VEX is much cleaner. of course, use whatever work for you and get the job done.
  23. 2 points
    I think if you use the point deform capture from the QL lib, you could avoid using an expansive loop and run faster It used an attribute to partition your geo so the capture weights and pts are generated accordingly. After just use a regular point deform but in deform only. ________________________________________________________________ Vincent Thomas (VFX and Art since 1998) Senior Env artist & Lighting & MattePainter & Creative Concepts http://fr.linkedin.com/in/vincentthomas
  24. 2 points
    well, this is not VEX, it's a group syntax have a look at "Group syntax" in the help this seems to work @Cd.r=1,@Cd.g=0,@Cd.b=.2 and you don't need "==" because it's not VEX and this is VEX (in a wrangle) if(@Cd=={1,0,0.2})@group_mygroup=1;
  25. 2 points
    A quick Houdini smoke simulation done in a day. This was done by using the gas target force microsolver. Hip file attached - feel free to take a look! Cheers, Mark run_smoke_v002.hipnc
  26. 2 points
    Just having Fun and sh
  27. 2 points
  28. 2 points
    Here you have examples (if you already don't use this for you study ). https://dataarena.net/dive-in/tutorials/houdini/introduction https://www.youtube.com/watch?v=SwQ6gdNU7h4 vizi.rar
  29. 2 points
    Hello everyone. I have uploaded a fully procedural (indie lc) setup for the terminal. I have put a few sticky notes, plus you can read the text from a .txt file. Thank you again fencer! terminal_setup.rar
  30. 2 points
    Thanks for sharing this, looks great! Super fast details
  31. 2 points
    I heard oil paintings are a thing right now. Here is a initial setup (still lacking all micro details and sweep strokes): Original procedure developed by Will Macneill: http://www.willmacneil.com/portfolio/oil-painting-the-houdini-way painting_2.hipnc
  32. 2 points
    I see. Here is a quick concept of a material shader which rotates a user-defined number of tiles across a UV map. It includes noise to cover up the seams a little. uv_tiles_noise.hipnc
  33. 2 points
    Here is my tutorial, done super fast so don't be too harsh I hope this is helpful Sparse Pyro Upres, the easy way - part1
  34. 2 points
    Great stuff, Nicolas. This is starting to look Giger-like already! You don't necessarily need to create UVs in SOPs, though. To project textures on those VDB meshes it's arguably more efficient to do in a shader: 1) Transform position to world space. 2) Curve IDs shown as random colors. 3) U value from curves in HSV colors. 4) Direction to nearest curve position. 5) Tangents from curves set to absolute. 6) Direction to curve oriented along tangents. 7) V coordinate enclosing each wire. 8) UV coordinates in red and green. 9) UV mapping an image texture. 10) Texture based displacement along curves or at least what happens when mandrills do the job ; ) The material snippet: string geo = 'op:/obj/curves/OUT'; P = ptransform('space:current', 'space:world', P); int prim = -1; vector uvw = vector(0.0); float dist = xyzdist(geo, P, prim, uvw); vector pos = primuv(geo, 'P', prim, uvw); float u = primuv(geo, 'u', prim, uvw); vector tangent = primuv(geo, 'tangentu', prim, uvw); matrix3 rot = dihedral(tangent, {0,1,0}); vector dir = normalize(P - pos); vector dir_mod = dir * rot; float v = fit( atan2(dir_mod.z, dir_mod.x), -M_PI, M_PI, 0.0, 1.0 ); P = set(u, v, 0.0); curly_curves_shader.hipnc
  35. 2 points
    Write-up on a Megascans integration which I helped with
  36. 2 points
    I'm attaching a hip file to help explain. There's two things you can do: one is manually extract the transform using VEX as I described earlier... there's a catch in that the Copy SOP also recognizes the "pivot" attribute exported from the RBD simulation, so your boxes won't be in the right place unless you zero that out. The other method is to use the Transform Pieces SOP to copy the transforms over, as long as the boxes have the same "name" attribute as the original simulated primitives. transform_rbds.hiplc
  37. 1 point
    in both cases you need to specify target path, otherwise Vellum will not know which geometry to try to match animation to the easiest way to do it is to source your vellum geo using Vellum Source DOP (which has Target Path parameter) instead of specifying it directly on the Vellum Object dops_pin_example_fix.hipnc
  38. 1 point
    Have you already tried clearing the RAM in the Houdini session itself by using the Cache Manager (Windows-> Cache Manager or Alt+Shift+M)? Usually restarting Houdini is enough to free up the RAM it is using (assuming your OS is doing garbage collection correctly), but it may not be necessary if Cache Manager can flush it. Writing your particles to disk is also a good way to help reduce the amount of data Houdini is having to keep in active memory if you're able to do that without much disruption to your process.
  39. 1 point
    Have you tried bringing up the cache manager and clearing all cache? Worth a try..
  40. 1 point
    As Tomas was pointing out above, you can use s@collisiongroup to set a point group name for each collision object (I used "tubeA" and "tubeB"). Then on each string set s@collisionignore to ignore the appropriate group. So string A s@collisionignore = "tubeB" and string B s@collisionignore = "tubeA". Here we're ignoring the entire object, but obviously since it's a point group, you can also select a subset of points on a collision object to ignore. selective_collision_release_mbG.hiplc
  41. 1 point
    Thank you, this is more close what I want. I tried totally the same logic, but I used FLIP for making volume velocity, you use Smoke solver which is working more natural. I also tried your volumes in my RBD setup, it's also interesting, a bit buggy and slow, but what I like is that particles keep initial shape more better than with POP grain, can be interesting in some setups I am attaching two files for those who are interested movingNonintersecting.hiplc pop_advect_grains_toadstorm_2.hiplc
  42. 1 point
    because it computes the derivatives and the full per point transform from them (or explicitly using xform) to transform the transformable attributes if not providing xform your function however needs to be continuous based on pos variable for derivatives to be properly computed
  43. 1 point
    I just imagine a long-time Houdini expert opening a hip file created by a bunch of "everything-must-be-simple" designers showing a "it's gotta work like my program" attitude.. He probably dies instantly
  44. 1 point
  45. 1 point
  46. 1 point
    "Her Aura" And so she stood Breathing Feeling the space around her Letting her aura expand Touching the trees, the flowers, the bees Inhaling the fragrances Healing deeply Houdini, Redshift... Cheers, Tom
  47. 1 point
    If you switch the condof to 1 and constrain both rotation and position you're limiting movement to anywhere in the plane whose normal is y (which is why in the .gif below you can see the box only moves along x and z) and you're limiting rotation to any rotation axis that can sit on that plane.. hard_hinge_daryl2.hip
  48. 1 point
  49. 1 point
    Hello All, Been lurking for a bit since I started dabbling in Houdini, and must say am in awe of the level of genius on exhibit here! Houdini is still kicking my ass in so many ways, but I'm a glutton for punishment I guess, and looking for excuses to spend less time in Max. This is a simple setup that seems to work OK, but I'm curious if there are other/better ways of getting these 2 solvers to interact. Currently I'm using PopAdvectByVolumes on the Grains to transfer Vel from the FLIP sim, and building a collision SDF in a SOP solver attached to the Grains sim which then gets pulled into a SourceVolume on the FLIP sim. I'm sure this is nowhere near physically accurate, but it does look pretty neat, and can be improved by adding custom attributes on the grain points for wetness etc. Thoughts? --Dave DJS_ODForce_FLIP_Grains_Interact_SampleSetup.hip
  50. 1 point
    How about ... centroid("../geo_" + chs("linkedname") + "/OUT_" + chs("linkedname"), D_X)
×