Jump to content

Leaderboard


Popular Content

Showing most liked content since 03/13/2021 in all areas

  1. 4 points
    The sweep SOP can do the shape along with remapping the UV coordinates and Vellum for additional deformation. dry_fruit.hiplc
  2. 4 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
  3. 3 points
    Hand painted looking textures for low-poly models: paint_bake.hipnc
  4. 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
  5. 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
  6. 3 points
    Hey everyone, if you're using MPlay to view and write out multiple flipbooked image sequences, you should check out MPlay Batch. It's a package that adds on an extra menu to MPlay that has options for quickly writing all the in-memory sequences to disk either as an image sequence, a video, or both! If you wind up giving it a try (or have any questions) please let me know what you think. Thanks!
  7. 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
  8. 3 points
    Numero uno. pioneer Thanx Houdini FX Team
  9. 3 points
    Hi Max, first rule: do not boole. Boolean subtractions seem very intuitive at first glance, but if not used advisedly they can do a lot of harm to the mesh's topology. Instead, you could measure the direction of a cylinder's surface towards the profile curves and blend between their closest positions. > bottle.hipnc
  10. 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)
  11. 2 points
    Nice tricks for exact that you can find in file .
  12. 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
  13. 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.
  14. 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!
  15. 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
  16. 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!
  17. 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
  18. 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
  19. 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
  20. 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:
  21. 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
  22. 2 points
    Hi Peon, Just looked at your solutions, the 2nd is exactly what I was looking for. Thank you very much! Kind regards!
  23. 2 points
    Hey Wout, thanks a lot! :-) I was away from 3D for a year and only start coming back now, but concentrating more on real-world-design ATM using Rhino - which thankfully now got SubDs... :-) But I did this a while ago in my old Houdini 16.5 and older Redshift, the second image with Octane 4: "Sine Waves" This was a re-visit of my custom "Threader", improving it some more on the way. Cheers, Tom
  24. 2 points
  25. 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
  26. 2 points
  27. 2 points
    Heyo, took a quick look and I think I've made it work. The main reason this is happening is that your original solution, creating a reference to the box's length and the extradition height to get the capture origin, does not take into account the angle and position change that changing the bend amount introduces and so the bend freaks out. However, for this to work you'll need to proceduralize all the three main parameters of the bend (I say main, they are the parameters that I mainly use at least), the "Capture Origin", the "Capture Direction" and the "Up Vector". The Capture Origin, as the name implies, is there the bend modifier places its origin form which it will try to modify your geometry. To get this procedurally I simply took your "extrudeFront_tray_width_top" polygon and averaged the position of all of the points. This way, even if the bend angle changes, you'll still have this one polygon since it's created procedurally and ends up in that group procedurally thanks to your setup. Next is the Capture Direction. I like to think of this as a "forward" axis, in this case, forward relative to the direction the "extrudeFront_tray_width_top" polygon is facing. For this, I simply used the facet node to generate normals for the points of the "extrudeFront_tray_width_top" polygon and once again average them to get the direction. Finally the Up vector, I don't know how familiar you are with Houdini and math in general, but depending on that this might be the trickiest one to calculate. Essentially what the Up vector does is it helps the Capture director orient itself in relative space, meaning relative to the geometry, not to world space. The reason we need to proceduralize this is that the Capture Direction and the Up Direction can never be the same, if they are then you run the risk of getting a vector flip (my own term, no idea if there is a better name for it), in your setup it manifests itself as the second bend suddenly going from bending inwards to bending outwards when the first bend nears 90 degrees. Now the way you fix this and create a procedural Up vector is to take a cross product of the Capture Direction vector another vector (in this case I just used 0,0,1. However you might want to look into proceduralizing that or else you'll have to change that in the future if you want to rotate the box). A cro ss product basically takes two vectors and finds a third vector that is 90 degrees off from both of the vectors you gave it. See this for more in-depth info on the topic. Hope it helps, and if my explanations were kind of strange, which I bet they were, I hope someone can come along and explain it better. If you have further questions just tag me and I'll hopefully see it and I'll jump back in here and try to answer the question to the best of my ability. (Note, I opened this with Houdini 18.0.460 so there might be some version-specific changes to nodes, sorry about that. If you want you should be able to copy in the nodes I added into your original scene or recreate the changes in your own hip for better practice.) fold_out_01_mnb.hipnc
  28. 2 points
    Or you shift the previous frame to the current position and apply the attribute transfer on it (all in the solver). AttributeTransfer_03_shift.hipnc
  29. 2 points
    if this with this, And I'm happy with This
  30. 2 points
    Hi, you can sweep with different cross sections for example. bottle_sweep.hipnc
  31. 2 points
    The measure SOP has a principal curvature direction you could use for hatching. sketch.hipnc
  32. 2 points
    Hello magicians. I want to share with you the result of studying l-systems. Behold the Moss Incredible aka Sphagnum! Redshift shading. And yes, it is growing. Available on https://gum.co/fZROZ https://gum.co/qmDmg Thanks! akdbra_moss_grow.mp4 akdbra_moss_var.mp4
  33. 2 points
  34. 2 points
  35. 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
  36. 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
  37. 1 point
    Thanks for the replies, everyone. I also received help on Discord which provided the simplest solution. Calculate the collision object using Ray Intersect instead of providing a Volume Sample. For some reason this just fixes it..?
  38. 1 point
    Dive inside the python node and place a null, anything will work just need something to have its flags on Because the python nodes been created from obj level, it looks like it doesn't execute any script unless there's a node inside with its flags set on.
  39. 1 point
    thinking of setting keyframes on the intensity/exposure I suppose
  40. 1 point
    Heyo! I had a look at your hipfile and I think I've come up with a solution for what you wanted to do. I made one version of your v003 and one version of your v004, I didn't see the update till after I had fickled with the first hip so the solution there is probably not what you are going for but might still be useful for something down the line. The answer to your problem can basically be summed up in three word, "the "active" attribute". There are three attributes that, when enabled in the rbdpackedobject node, can easily influence your rbd sim (and I think pop and vellum sim also, though don't me on that before checking). These are: "active", "animated", "deforming". They are all just 0 or 1 attributes that tell the geometry how to behave in the sim and has the express purpose of solving situations like this where you want to stagger/control the activation of your pieces. Hope it can be useful to you! Good luck hand_v004_mnb.hipnc
  41. 1 point
    You can also store the ptnum as (extra)attribute before extrude. Extrude will transfer this attribute to the new points, which can be used to sort the points.
  42. 1 point
    yes, simple pyro, save your vel field to disk and create a separate dopnet with a popsim and add an AdvectByVolume DOP node There is an example in the docs https://www.sidefx.com/docs/houdini/examples/nodes/dop/popadvectbyvolumes/AdvectByVolume.html
  43. 1 point
    Hi folks ! I am working on a sparse pyro upres on my 'sparse' time (lol). I tryed to automate as much as possible the process by normalizing inputs and coding a python script that copy and paste all the params of the lowres simulation to the upres node. So the only thing to work with after matching params from the script is the noise / dissipation of the upres. I added a hip with hda in the link. The hip is annoted to guide you through the process. https://drive.google.com/drive/folders/1H4Y0HNELDJ6lmHsM43eEI_lRgNuCEaxX?usp=sharing the pipeline is fairly simple : 1. add a configure input node, it will merge all inputs from low res sim and source to normalize and rename fields 2. add the sparse pyro upres node 3. In the tab match properties of the upres node drag the lowres pyro and click match properties 4. enjoy The sparse solver itself is a deeply modified sparse pyro where you basicly cancel all nodes relatives to vel advection / projection and import the vel from the lowres in copy mode. Then you can add your sources (without the vel or v sourcing since it has already been calculated in the lowres) and add some noise. Since vel is in copy your noise won't last in the sim so i created a noise channel in the smoke object that is advected by the vel and merge to the vel. You can also simulate your low res without color and add color to your upres source and simulate an upres with color, it only needs a Cd and Alpha channel.
  44. 1 point
    Try opening Wacom Tablet Properties and under Grip Pen / Mapping uncheck "Use Windows Ink". That should fix it. If only there was a check box somewhere you could uncheck "Use Windows"
  45. 1 point
    Made you a file to test the method. I don't know if that's what you're looking for. morphParticles.hip
  46. 1 point
    @vicvvsh - very nice and elegant! Here's a different approach using a simple double wishbone setup using cone twist constraints (primarily). No idea how accurate or robust it is but it seems to be a starting point for some fun: Inspired by this: https://www.youtube.com/watch?v=GW__Gzkk4G0 (4.53 is where this setup is described) suspension9.hipnc
  47. 1 point
    Hello Mattia, use combination of constraints. Pay attention to constraint attributes condir and condof. In attachment simple example. I hope it helps you. Cartest_01.hipnc
  48. 1 point
    here's another one. it's a simple vex solution which works basically by counting the number of intersections along the curve and the fact that an uneven number means it`s inside an object ... hth. petz curve-boolean.hipnc
  49. 1 point
    That is pretty messed up. You have the Copy1 wired up backwards, points on right, what to copy on left. I don't think you can stamp a string using those old-style variable system. Just type your attribute directly in the attribute field and then you can stamp as if the attribute was a variable. I added a wrangle which creates a random capital letter between A-Z. ap_MatrixScreen.hipnc
  50. 1 point
    Here you go. You were doing it wrong in your test scene. Match field is to create an empty field that matches the "resolution" of another field, then you have to add data to it. So this is getting the curl vector, then the magnitude (the length) of the vector, which is what you want to colour by. Then at the stamp stage I'm pre-multiplying last frames magnitude by 0.8 (so 80%) before then taking the max of the current frame and last frame to get the effect you're after. Play with the visualizer range in the flip object to mess with the amount you want. I'd probably add a vopsop after import and add a ramp in there to control the look prior to render. Hope that helps Christian micro_vorticity.hip
×