Jump to content

Leaderboard


Popular Content

Showing most liked content since 03/23/2021 in Posts

  1. 8 points
    I had a go. I'm positive there's an easy way to do this in mops, but I'm a masochist and enjoyed the challenge of doing this from scratch. Definitely look into mops if you want to do more of these kind of things! The vex looks a bit scary, but its mainly a few ramps controlling when and how the chunks get moved: get a horizontal ramp from the bounding box run it through a few channel ramps, each ramp controls a different part of the effect; eg a ramp that tells the noise to start at 0, go to 1, then back to 0, while another ramp determines when the pieces morph from word A to word B, while others control scale add time to the ramped values, clamp it, so that it slides through the words modify the transform of each chunk. make chunks from word A start with a scale of 1, then scale to 0, while word B does the opposite word A chunks start with no rotation, then gradually start to rotate while they scale down, word B does the opposite finally blend (lerp) the positions from word A to word B, adding some animated noise in the middle bit as they move. The cross-fading of scales hides the transition between word A and word B. voronoi_morph_v03.hip
  2. 6 points
    How to create a procedural mushroom model in SideFX Houdini. Video: Original thread: Latest file version: https://gumroad.com/konstantin_magnus
  3. 4 points
    This would be a MOPs way to do it... less VEX but a few more nodes involved to get the scale fake working as intended. If you could guarantee an equal number of chunks on both sides of the equation, it'd be easier to blend transforms from A to B via MOPs Apply Attributes, but it's hard to guarantee chunk counts with voronoi. voronoi_morph.hip
  4. 4 points
    It's been a long and illustrious carreer. I think this website has been going for ~23 years now. Time flies when you're having fun
  5. 4 points
    I'm not leaving anytime soon. It was 2002 when I found this place, I was a lurker for a few years before making and account and saying a word. I think it was the Apprentice edition combined with 3DBuzz free training + 3D World magazine that got me here. Such an exciting feeling i had knowing absolutely nothing. Nowadays, i now know what i don't know...... which is still a lot! But I use Houdini everyday for work while many of my colleagues are still forced to use Maya, and I think this place is partly responsible for that in creating a truly creative community that embraces the sharing of knowledge, one that has never devolved into petty drama (which often happens with old school forums etc). Thanks Marc for making this place, i dont think i would have a career using Houdini if i didnt have help from the amazing people here. SESI have their official forums (as they should), but this is THE Houdini community for me and many others. Here's to another 20 years.
  6. 4 points
    The sweep SOP can do the shape along with remapping the UV coordinates and Vellum for additional deformation. dry_fruit.hiplc
  7. 3 points
    Hey guys, I started making a very simple pathtracer with vex in sopland. I'll add basic reflection and refraction, and keep it very simple as it is made as an "educational tool" to help students understand how pathtracing works under the hood. Once I'll have finish I'll share the file here if some of you are interested. I added an "animation" in which we can see the different paths a ray takes : the primary path (in red/blue in the video), the next event estimation path (in black/yellow), and the diffuse bounces (in magenta). I'll also add the next event estimation for the diffuse bounces, and of course when it will be implemented, reflection and refraction paths. Here's a little video of the animation, and a very non-converged render https://streamable.com/37kxua (I think I have a bug in the global illumination I'll fix it tomorrow). Cheers,
  8. 3 points
    @Max_Steven combine, maybe you gonna find some tricks FlowerDETaIL.hiplc
  9. 3 points
    Hand painted looking textures for low-poly models: paint_bake.hipnc
  10. 3 points
    Heyo, had a look and came up with the setup below. Still some improvements that could be made, like having the shrinking of each constraint happen over the course of a few frames instead of instantly to get a smoother transition etc. One of the key nodes when working with vellum and wanting to really art direct your cloth like this is the "vellum constraint property" node. As long as you have that and either an initial group or use the vexpression tab to fetch attributes or groups from sops then you can do A LOT of stuff with Vellum. The setup below mainly works by creating an animated group in sops to control a rest length multiplier attribute on the vellum constraints. This is done by using a solver sop and merging the current frames group with the previous frames group and then adding to it, causing the group to grow over time. Then setting a rest length multiplier attribute, "rest_mult", based on the animated group. If you are in the group, have a lower rest length multiplier, if not, just be normal and have a value of 1. Then lastly using the vexpression in the "vellum constraint property" node to get this animated attribute from SOPS and bring it into DOPS to have it multiply with our rest length scale. Hope that can be of help! animated_restlength_mnb.hiplc
  11. 3 points
    The collision issue in this case is because you as passing in packed objects to a static object DOP which can't happen. You will need to put a convert sop down before your collision source sop to convert your fracture to polys. Once you do that, you will end up using an rbd fractured object dop instead of the static object dop. You can try using packed objects as your collision by bringing your packed objects into a rbd packed object dop but in my experience, dealing with two way interaction between packed objects and flip can lead to headaches. Flip_Collision_RB.hip
  12. 3 points
    You can "compare" the normals with an arbitrary angle with dot product. the dot product gives you a number between -1 and 1: from "opposite angles" (=-1) to "parallel angles" (=1) something like this: @Cd=0; if(dot(normalize(chv("angle")),normalize(v@N))>chf("treshold"))@Cd=1; dot.hiplc
  13. 2 points
    Use a GuideProcess node with the operation mode SetLength. Activate the Randomize check box. What is nice a bout this node is that it works on any lines in Houdini, not just hair.
  14. 2 points
    Hi! I just released Simple Tree Tools 2.0. This is a huge update! Please enjoy https://gum.co/SimpleTreeTools
  15. 2 points
    Hi all, I recently did a discussion about this for The Rookies | Rebelway FX challenge. I used a Python SOP to extract some useful data from the alembic cameras provided with the scene. alembicCamScript.py #add this code to a python sop to extract transform data from an amembic cam #extract the world transform of the alembic xform node & mult the 4x4 matrix by a origin vector #note --> the .node("path") is an absolute ref to the target alembic node camPos = hou.Vector3(0,0,0) * hou.node('/obj/alembicArchive/alembicXform').worldTransform() #creating a look nml by offseting the vec (-1 along the z-axis) camLookPos = hou.Vector3(0,0,-1) * hou.node('/obj/alembicArchive/alembicXform').worldTransform() camLookDir = (camLookPos - camPos).normalized() #binding data to geo #.pwd() is a method for getting the active directory geo = hou.pwd() #setting detail attribs onto the geo #creating two detail attribs (camPos & lookDir) geo.addAttrib(hou.attribType.Global, "camPos", camPos) geo.addAttrib(hou.attribType.Global, "lookDir", lookDir) #alternivivley uncommment this code to add a point attrib #pnt = geo.createPoint() #pnt.setPosition(camPos) #pnt.setAttributeVAlue('N', lookDir)
  16. 2 points
    Jesus Christ, we are sad people. 17 years.
  17. 2 points
    actually, i was wondering about doing the same thing not too long ago, when I needed to do a camera timewarp. see the hip file bellow. in short, you need to extract a camera transform into an oriented point (with N, up, and all that jazz), and then use rivet_SOP to drive other objects around with this point transform. works quite well for me. cheers. camera_timewarp.hiplc
  18. 2 points
    Hi Olly, do you mean the "Asset Bar"? I copypasted the image from this site: https://learncreategame.com/techart/houdini-digital-asset-versioning/
  19. 2 points
    I don't know how to utilize such functionality via copy-paste... But as an option, you can build a Python script for Houdini which (with selected Mantra Node) will run Nuke and create a reader with exr: import subprocess import hou NUKE = "C:/Nuke12.1v2/Nuke12.1.exe" mantra = hou.selectedNodes()[0] exr_path = mantra.parm('vm_picture').eval() command = 'C:/temp/nuke_create.py' subprocess.Popen([NUKE, '--nukex', command, exr_path]) and the content of nuke_create.py would be: import sys import nuke exr_path = sys.argv[1] nuke.nodes.Read(name="My_EXR", file=exr_path)
  20. 2 points
    Nice tricks for exact that you can find in file .
  21. 2 points
    Hi Peon. Wow That is awesome! thank you for helping me a lot! I learned a lot from your nodes. Actually, this thread was my first post but I'm really happy to have all of your kind and cooperative comments. Thank you very very much Peon you are the best! Haya
  22. 2 points
    you can change the hue like this. vector hsv = rgbtohsv(@Cd); hsv.x += chf("hue_offset"); @Cd = hsvtorgb(hsv); from the help: The hue will be in the range 0 to 1.
  23. 2 points
    Hello Odforce! I recently re-visited Houdini For the New Artist which is a perfect course for Houdini Beginners. You can check it out for free on Youtube or Vimeo, and if you're interested in downloading extra scene files + resources, then be sure to visit www.cgforge.com. Cheers!
  24. 2 points
    Yeaaaaah! super fixed I finally put the rest position node and the bind export on the shader with Type in Vetors calling "rest". And it worked! Really appreciate everything, now I also get to understand everything much better. Thank you very very much for your help Martin Julia
  25. 2 points
    Hey Julia, The reason why your textures/noises are swimming is not because of the UV's but because of your "restpos" node. That node is ment to calculate restpost by taking in a static P attribute. By default it is currently just fetching the "live" P that moves every frame, hence the swimming. This can easily be fixed if you make a "rest"/"rest position" node and place it right below the "uvtexture" or "rbdinteriordetail" node and then replace the "restpos" node in your shader with a "bind" node and then just write "rest" so the bind node fetches the rest attribute created by the "rest"/"rest position" node. Alternatively, you could probably also just replace the "restpos" node in your shader with a bind and just fetch the "uv" attribute that we have setup already, but this might limit the noise somewhat. Hope that helps!
  26. 2 points
    You know what, it does. In this animation the same velocity volume is supplied to both the flipsolver and the rbdsolver. Everything moves in the same direction, but it's not really flip moving rbd. Flip does seem to collide with the rbd, however. I would like to add viscosity to the animation, but whenever I enable it, the entire flip system locks up..? Does anyone have a fix for that? ap_synchronized_vel_rbd_flip_032921.hiplc
  27. 2 points
    Heyo, I don't think you'll need to transfer the UV's to the simmed geometry at every frame. Try moving the "uvtexture2" node to be right below your "rbdinteriordetail1" node and remove the attribute copy setup. I also noticed that your "uvtexture2" node is set to "Perspective from Camera" which is going to generate UV's by projecting UV space from the camera's view onto the geometry. This does not generate very nice UV's for your inside faces or anything besides the stuff directly facing the camera. I made a quick version where I simply unwrapped the geometry right before the boolean fracture. Since you are unwrapping the cutter planes used in the boolean fracture the UV attributes given to the cutter planes are transferred over to the inside faces. This way both the inside and outside faces have an unwrap by the time you reach the "rbdinteriordetail" node. I can't vouch for it being the best and most professional unwrap you've ever seen but it seems to be at least usable. If you want an even better layout you could even add a "uvlayout" node after the boolean fracture or after the interior detail nodes to further improve the uv layout. Hope it helps! frac4_foru_mnb.hipnc
  28. 2 points
    Hey Haya, I've made a quick hipfile below demonstrating a few concepts that hopefully will help answer some of your questions. I was alittle unsure about what you were after in terms of wanting to copy the normals from your original geometry. Are you trying to have the geometry align to the original geometries surface? Almost like small cars driving on a piece of geometry? Or are you referring to something else? I've marked the nodes of interest in yellow with a spikey shape. Hopefully, it can be helpful! Also, in the future, don't be afraid of uploading your actual hipfile itself as an attachment. More often than not it is actually easier to just download the hipfile itself and have a look rather than having a picture of the node network and having to imagine how it works. instancing_along_path.hiplc
  29. 2 points
    the static object is internally converting v attribute from your incoming geometry to collisionvel even if you specify a proxy volume to sample collision from. In order for you to scale down your collision velocity you can simply just multiply down your v attribute on your geometry before it is sourced in like so:
  30. 2 points
    @FollyxTry activating preserve group on the popgroup center. This will allow particles that leave the group area to remain in the group. Here is an addition to Ultraman's post. I connected a couple more streams. ap_pop_streams_PQ1.hiplc
  31. 2 points
    Hi Peon, Just looked at your solutions, the 2nd is exactly what I was looking for. Thank you very much! Kind regards!
  32. 2 points
    Heyo, I had a look at your hipfile and I think I've made it work like you wanted, though I have mostly created a different setup than the one you were using just based on my own experience creating similar things. Some of the takeaway might be that: - The ray node is not really a good idea for actual geometry since it will not make any effort to maintain the geometry's shape. It will just smush the geometry against the collision geometry and create a mess. Instead, try to ray something like a simple spline to the collision geometry and see if you can create the geometry sometime after the ray operation. - Also on the note of the ray SOP, I saw you had it set to use "Projection Rays" and "Normals", this works but do keep in mind that this means that it will try to shoot the points of the geometry along their normals till they hit the collision geometry. For this to work best, be sure to carefully craft your point normals before the ray SOP. If the normals don't hit anything the points will just stay where they were before the ray sop and make your spline look very strange. - Try to keep the setup as simple as possible for as long as possible. Basically, if you can work with splines all the way through your node tree until the very last node converts it into an actual mesh then strive to do so since your setup will be way more responsive for not having to deal with thousands and thousands of points each frame. - For animating/revealing a spline like this the "carve" node is your best friend, it's certainly mine! I've created this in Houdini 18.0.460, so there might be some errors when you open it. It should be fine though, nothing should be lost. However, for the best compatibility, I'd recommend you look at my setup, if you want to use it, and try to recreate it in your own scene. Good luck! ray and creep_forum_mnb.hipnc
  33. 2 points
    Good art work! You can also make curves follow the mesh topology by choosing directions towards neighbour polygons. topo_flow.hipnc topo_flow_only_curvature.hipnc
  34. 2 points
    Hi, I just tried with your hipfile and everything seems to be regular, so you did nothing wrong. The issue is inside the oceanfoam node. In particular how is calculating the density of the foam. In a wrangle (calc_camera_density) is calculated an attribute called @density. If this attribute is zero, also the foam generated in the following nodes will be zero. So why the density is zero? Without bothering you will all the mathematical operations... everything is because when you have your camera really low in ocean there are some "degenerated" polygons generated internally that have an area of 0. To fix this, just put a clean node inside the ocean foam tool, after "clip at near". See the hip file I have attached. Strangely this doesn't happens in H17. ocean_foam_fix.hipnc
  35. 2 points
    it's pretty straightforward out of the box just use v@N, v@up or p@orient on your instancing points in such a way that resulting reference frame has Y pointing in up-down direction of your ocean (so in normal direction of the ball) and X in the direction you want wind to blow in in your file, since v@N is pointing outwards and v@N defines Z axis, your ocean deforms in a tangential direction and therefore you are seeing weird deformation here is the modified file ts_ocean_on_ball.hip
  36. 1 point
    Fun points Grid vector2 pos = rand (@elemnum)-{.5,.5}; pos *= 10; int pt = addpoint(0,pos); vector scale = fit01(rand(@elemnum+0.1),{0.2,0.5,1},{1,1,1}); float pscale = length(set(scale.x,scale.y)); setpointattrib(0,"scale",pt,scale); setpointattrib(0,"pscale",pt,pscale); vector nor= {0,0,1}; vector up = fit01(rand(@elemnum*0.2),{-1,-1,0},{1,1,0}); up= normalize(up); setpointattrib(0,"up",0,up); solver removevalue(near_pts,@ptnum); vector avg; vector scale; vector pos; vector dir; vector up; int n = len(near_pts); foreach(int pt; near_pts){ scale = point(0,"scale",pt); pos = point (0,"P",pt); dir = @P-pos; up = point(0,"up",pt); if(abs(dot(up,@up))>0.001){ @up += length(@up-up)*(up-@up)/n; } if(abs(dot(dir,v@side))<scale.x+@scale.x && abs(dot(dir,@up))<scale.y+@scale.y){ avg += 1.2*(@P-pos)/pow(length(@P-pos),4); } else if(n<chi("compactnes")){ avg += pow(length(dir),2)*(pos-@P)/n; } } @P += 0.008*normalize(avg); outside int pts[]; matrix xform = instance(@P,@N,@scale,0,@up); foreach (vector pos;{{-1,-1},{-1,1},{1,1},{1,-1}}){ pos *= xform; append ( pts,addpoint(0,pos)); } int prim = addprim(0,"poly",pts); setprimattrib(0,"Cd",prim,vector(rand(0.1*@ptnum))); removepoint(0,@ptnum);
  37. 1 point
    Haha Merci! There are far better houdini teacher here I'm afraid, i have been a student for 23 years By the way, a more simple approach will be to use connectadjacentpieces, adjacent piece from point with piece attribute. So if you attribute a name attribute for your separate piece, it will do something similar and more simple to understand. But there is no guarantee the connection is unique per point...
  38. 1 point
    Omg Master You killed it @.@ It's like a dream to see such simple and clean nodes can produce such amazing result. I can sleep with ease now Thank you so so so so much for your reply I can push the like button 1 million times Have a good day master
  39. 1 point
    Indeed it does. So after having a look I can't see any of your constraints freaking out like in your screenshot, however, that might be because nothing actually happens in the sim. The dam just sits there. So once again I don't have anything except speculations, but one thing you could try is to remove the expression of the "overwrite with sop" parameter on your "glue_Destroyable_Z_RockCribs" "constraint network" node and set its value to 0. By default this thing runs a python expression, checking the input of your constraints from SOPS and checks if they have been altered, if they have then it will reimport your constraints in the sim with the ones from SOPS. Which is probably not what you want in this case. If you set its value to 0 then it will import the constraints once at the start of your sim and never reimport them, letting them die off during the sim as you please.
  40. 1 point
    Copying the seed to the input points before simulating creates a more interesting stacked result If you visualize the Thickness attribute, you can see the spherical grains being simulated are packed next to each other correctly - it is the seed geometry you are copying to those points that is creating a visual offset. Since grains are spherical, if you want the seed geometry itself to collide and pack together naturally, you'll probably want to make that geometry vellum objects for simulation or possibly look at using Bullet instead.
  41. 1 point
    Hey folks - long time lurker joining the party with a tutorial showing a workflow for integrating the FLIP and pyro solvers, allowing for bidirectional interactions. I cover a few other tips and tricks along the way, so I hope you find it useful! Hip file attached (and linked through from the video). flippyro_diffusefx.hiplc
  42. 1 point
    @bentraje Magnus trick Roof File Scrdrr.hiplc
  43. 1 point
    Can't believe no one has fixed that even in latest 18.5 build. Thanks for the tip
  44. 1 point
    Hello, great work! Seem it is the FLAM fever again as so many people recently implementing it! I just finished an implementation of The Fractal Flame Algorithm too! Not sure how you did yours but I did mine entirely in CVEX. If anyone is curious you can check the results and download the tool here: FLAM3 for SideFX Houdini Its free and the HDA is unlocked so you can extend it if you like. ( the CVEX code is pre compiled tho because it was so much code that was the only way to keep it manageable ) The 3D version of the variations ar what they are, some work better than other and some are really hard to port into 3D so the 3D option is really there just for fun but consider it a 2D tool and you should use it that way. Cheers, Alessandro
  45. 1 point
    A more elaborate example for cutting roads through height fields: Identifies flat areas for settling locations Connects them to a road network Bends and resamples paths into avoiding slopes Smoothes out height variations and blends them into the terrain. heightfield_roads.hiplc
  46. 1 point
    Fractal City on the Subject. Endles FUn ..Just to fin adjust 3d verison/mesh and 2d.
  47. 1 point
    Hi, This is going to be my next training series. Procedural armour generation in Houdini. There's still a lot of work to be done. I need to detail the torso, the neck and finally build a head gear. But it's coming along fine, so I figured it looks decent enough to share.
  48. 1 point
    WOWOWOWOWOW It's again been a hot minute since I posted anything here I recently gave a talk at the LA Houdini User Group on writing your own vex based polywire SOP, and figured it would be worth sharing here! I also recently redid my website so go check that out here as well: jakerice.design Love you fools <3 Jake
  49. 1 point
    Intersection Analysis Sop can get good results when used with Intersection Stitch Sop. DissolveInside_sy.hipnc
  50. 1 point
    Had some strange shapes, I guess Affinity "booleans" are not well suported ! Here is an updated svg, Genji style ! cut.svg
×