Jump to content


Popular Content

Showing most liked content on 05/05/2020 in Posts

  1. 1 point
    Hi folks, I am actually coding some basic operators like divergence, gradient in vex and python to demistify them and wanted to share the file with you. Feel free to update or correct the file since i might not be sure of some operators. it contains : - Divergence (voxel and points) - Gradient (voxel and points) - Curl (voxel) : the curl seems to not have the same order as vdb curl so still in wip - Laplacian (voxel) : The computed laplacian is somehow less precise than vdb laplacian - Covariance matrix and eigen vectors (points) : It works but the scale is normalize - Laplacian matrix of a mesh (python) - Bernstein polynomials basic_operators_001.hiplc
  2. 1 point
    Hi guys, I'm glad to share the breakdown of my last project with you! This was my submission for a challenge hosted by Houdinimatic Community. Hope you enjoy!
  3. 1 point
    yeah both grains/hair were using the same vellumsolver. An even easier test to try before you buy is: line/hair...copy transform a bunch of them, drop grains on them...goes right thru Then you'd try to be smart about it and put grains on the hair ! Then grains would collide against grains. but I don't think this cheat is good enough for anything except a few giggles.
  4. 1 point
    could be wrong but from memory, VellumGrains need a real geo (surface or volume) to collide with. Hair is nothing but a line so it won't collide, Grains is particular about this I think, can't for the life of me find the thread anymore. Search function on here is a bit finicky.
  5. 1 point
    Copy image to clipboard from Render View and Mplay.
  6. 1 point
    Hi; You can break constraints in several ways. Please take a look at some tutorials like this: or this:
  7. 1 point
    I think the workaround is to file a bug report and wait for the fix... Which I'm doing right now.
  8. 1 point
    Hi, You can use the vexprofile command if you want more granular VEX performance profiling: https://www.sidefx.com/docs/houdini/commands/vexprofile.html
  9. 1 point
    For splitting materials across an object in Houdini, the best way I've found is to create groups (Group Create node), and assign the primitives (polys) to each group. Then in a Material node, assign a material to each of your groups. In the image below, I just add a Color node to make it easier to see all of the material groups I created. This can also be used as a base for materialIDs in Substance, just make sure you're applying the colors in vertex not point mode.
  10. 1 point
    what about scaling down the emitter over time...AND also clip it (animate it) so that the emitter will eventually disappear altogether ?
  11. 1 point
    There is a "remap range" function right in the SOP import. I think the equalize node can normalize colors in COPs, too.
  12. 1 point
    I think you're on the right track, perhaps create a new attribute from the height and cops will pick it up. You can leverage the promotion technique to get the minimum and maximum height values and store them as detail attributes. Then the fit might work. f@height_NORMALIZED = fit(@height,detail(0,"lowest"),detail(0,"highest"),0,1); v@Cd =f@height_NORMALIZED;
  13. 1 point
    dunno if this is applicable to your scenario (or carve situation): https://zybrand.xyz/vellumcontinuous-emit-with-dynamic-constraints#more-324 I fooled around a bit to use hair instead of grains...mods were pretty minimal, you too can do it.
  14. 1 point
    Without looking at your file: - deactivate Reseeding in your FLIP solver > Particle Motion > Reseeding. Are the Splashes still way too extreme? - You might be over smoothing your sim, this is why it feels too slow. FLIP Solver > Volume Motion > Velocity Smoothing. When using the Splashy Kernel, the default is 0.1, which I think is way too much, try something like 0.01 or 0.005...or maybe change to FLIP/APIC by changing the Kernel to Swirly.
  15. 1 point
    Dark mode for the documentation.
  16. 1 point
    Haven't seen 18 yet so don't know if the code editor was improved, but if not, this still is my ABSOLUTE NR. 1 wish. if(code_editor_improved != true) { Code editing in Houdini Wrangles is - well - crap. It's a total shame we don't even see command parameter lists when typing since even in value fields typing expressions does it and has autocomplete for paths etc. Even only bringing that ability to the VEX editor would be very helpful. Of course it would also make a lot of sense to have other settings and helpers in there, like auto-closing brackets, more clever cursor positioning, offering existing variables and attributes when typing etc. - the Houdini devs should know ALL about that, they probably spend their life in real code editors... The use of external editors could be improved a lot if a.) we wouldn't have to press ALT+E twice for the external editor and wouldn't have to get to the floating editor first each time and b.) if that connection would be "live" like for instance the Pinegrow Web Editor does it with a little plugin for Code and Atom, where you can type in either the internal or external editor and they update each other in realtime. The current system is too clumsy and the 3rd party implementations also aren't really there (no negativity towards the authors intended at all!). Make it native! Make it goooooooood! } else { All is well. Nothing to see here. :-) } Cheers, Tom
  17. 1 point
    I found that some kind of ID for each head would help, for a sim like this a birthid at the primitive level worked for me. Example HIP
  18. 1 point
    Yes, you want the Vellum Rest Blend DOP, which you can point at an external SOP that animates your rest geometry. It will update the rest state of a specific set of constraints based on the input Rest geometry. With 17.5 there is a help example for Vellum Rest Blend SOP that shows some uses of it. Attached is an example of lengthening hair curves over time. Note the rest topology has to match the original geometry, i.e. you can't add points, but you can transform them in various ways. grow_hair.hip
  19. 1 point
    Because I was curious i expanded the idea of @konstantin magnus a bit and ended up with this setup. divide_grid3.hipnc
  20. 1 point
    I guess Ryan beat me to the solution. In my setup the points actually start moving based upon the VEX code even if the force is zero. Our setups are very similar, however. if(v@Cd.b !=0 ){ force[1] += 0.1; } ap_point_color_force_v1.hipnc
  21. 1 point
    The point function needs to be in a POP Wrangle to grab the color attribute from SOPs. Also you shouldn't use f@force. "force" is a reserved Houdini variable in DOPs and its a vector. Call it something else. I have attached an edited file. point_color_force_v2.hip