Jump to content


Popular Content

Showing most liked content since 12/11/2017 in all areas

  1. 4 points
    Early stage WIP of procedural shells, planning to do a tutorial when I'm done.
  2. 4 points
    Few tips and tricks to manipulate gas simulation. 1. Independent resolution grid. E.g. Overriding vel grid size independent to a density grid. 2. Creating additional utilities. E.g. gradient, speed, vorticity and etc which can be used to manipulate forces. 3. Forces via VEX and some example snippets. smokesolver_v1.hipnc P.S. Some of this technique are not Open CL friendly though.
  3. 4 points
    What I do while waiting for renders at work on a saturday... retro_cyan.hip
  4. 3 points
    Your code does basic point lighting with lambert. You need to add cone functionality. Check example $HH/vex/Light/asad_light.vfl for different light parameters. Basic spot light support: // Point wrangle. string lobj = "/obj/hlight1"; vector l = ptransform(lobj, "space:current", {0, 0, 0}) - @P; vector lz = vtransform(lobj, "space:current", {0, 0, 1}); float coneangle = ch(lobj + "/coneangle"); float conedelta = ch(lobj + "/conedelta"); float rolloff = ch(lobj + "/coneroll"); float angle = cos(radians(coneangle/2)); float delta = cos(radians(coneangle/2 + conedelta)); float cone = smooth(min(angle, delta), max(angle, delta), dot(lz, normalize(l)), rolloff); float lambert = clamp(dot(@N, normalize(l)), 0, 1); @Cd = cone * lambert; Use integer casting to output hard mask: @Cd = length(@Cd) > 0; sop_spotlight.hipnc
  5. 3 points
    Hesitant to actually call this finished but here is a test render of a procedural lightning tool I've been working on the past couple of days. Hope you like!
  6. 3 points
    Hey magicians, Wanted to share a spot I worked on for Yambo Studio recently, I did some R&D concepts and Sims Cheers!
  7. 2 points
    minpos is my new favourite lazy way. pop_minpos.hipnc
  8. 2 points
    as promised....I did some more Twisting of your DNA and unraveled it too...you've been sequenced !!! Vu_InterlockMobius_06.hipnc
  9. 2 points
    Hello, I AM DYSLEXIC - a very nice student project I worked on back in 2015 just got published, I did FX for it, all in Houdini, then handed over caches to lighting and rendering guys (rendered in Mental Ray in Maya). I really like visual style and it was really interesting to do some effects for this style of animation. Enjoy Short breakdown: 00:48 - paper (cloth) sim, a proxy collision geo of hero character was animated and used for interactions 03:22 - RBD simulation advected by hand-drawn guide curves and underlying FLIP simulation, some VDB meshes for hill filling, procedurally generated pages between books with fake dynamics (even though they got totally lost in the renders)
  10. 2 points
    A useful way to think of it is that if you have a function(noise) and you put the same input into that function, then you will get the output. So if you manipulate the position to repeat the same input, you will get the same result. In f1480187 example, a point's position (-1,-1,0) gets remapped to (1,1,0)... so it will produces the same noise result as the point that has the original pos (1,1,0). Effectively a mirroring.
  11. 2 points
    Something like this: mirror_noise.hipnc
  12. 2 points
    ver 1.04. This is the JUST WORKS version. Super stable, no fuzzy logic that doesn't work...no flickering...no mangled up connections, even allows to connect every Nth...not just every 2nd block Vu_InterlockMobius_04.hipnc
  13. 2 points
    arrggg...you know me...I don't like limits...so here..ver 03 Vu_InterlockMobius_03.hipnc
  14. 2 points
    I hope this setup can give you ideas. It worked for me. I deleted the file caches between the different steps, so it's going to take about 2 min to cook raspberry.hip
  15. 1 point
    I don't think there is much of a major speed difference. You'll still be better off with iron py and other similar branches that have more compiled components. Python 3+ will get all the latest and greatest stuff so it might be faster in a lot of ways, but nothing comparable to the difference between other languages. You can theoretically use your own python with Houdini, if you wanted to a different library, and then just import the hou module. Generally this is a lot more work to maintain, but bigger studios have a few good reasons to do this depending on their internal library of tools they developed over the years.
  16. 1 point
    Less lazy attempt: pop_minpos_align_pig.hipnc
  17. 1 point
    I meant it's easy to copy "acos (dot(normalize(a), normalize(b)))" from the docs. My last best result in counting was "potato" before I run away. Here is what I typically use to get 0-360 degrees:
  18. 1 point
    ok, here's my attempts...in pyrosolver>shape>disturbance, I cranked the hell up of everything... - Cutoff: 10.1 - Control Influence: 10 - control range: 10.05 but only you would know if this has the desired effects....
  19. 1 point
    A couple of the more prolific artists/designers doing this type of looks nowadays: Gustavo Torres/Kidmograph, James White/Signalnoise. They seem to create their own stuff, not sure where they draw their insp from, probably partially from the stuff already discussed in this thread.
  20. 1 point
    Sometimes the best solutions are the simplest ones.
  21. 1 point
    I came up with a far simpler solution. Basically just offset the curves along an axis from each other so they sim in isolation and then move the particles back in place after they have simulated. Like this... Offset_pop_curve_force.hipnc
  22. 1 point
    1. Add a more readable font for guides and similar. Maybe even control over the color of the font (thickness/bold, outline - on/off, thickness, color) 2. Select Similar - for edit node (edges, primitives, etc), obj network/view, etc 3. "Make circle" (edit node) should get constrained by slide on surface (for curved surfaces like cylinders and spheres). In other words the "circle" from make circle doesn't follow the curvature but rather make a flat planar circle. -also when used on primitives, make circle only affects the outer border of the selection rather than the whole selection. Again visible with curved surfaces. (surfaces as in polygons and not nurbs and bezier surfaces)
  23. 1 point
    I haven't seen a function for this inside HOM but there is in hscript, which you can call from python. http://www.sidefx.com/docs/houdini/commands/viewerstow.html This should work: import toolutils def viewName(viewer): ''' Returns the Scene viewer name in a hscript compatible format ''' name = { 'desktop' : viewer.pane().desktop(), 'pane' : viewer.name(), 'type' :'world', 'viewport': viewer.curViewport().name() } # special case for floating windows - they don't belong to desktops if name['desktop']==None: name['desktop'] = '*' else: name['desktop'] = name['desktop'].name() return '{desktop}.{pane}.{type}'.format(**name) viewer = toolutils.sceneViewer() hscriptViewer = viewName(viewer) cmd = "viewerstow -t open -b open -l open -x open -m open -c open -d open %s" % hscriptViewer hou.hscript(cmd)
  24. 1 point
    Just set the position coordinates to abs() before you feed them into noise. mirror_noise_odforce.hipnc
  25. 1 point
    No I guess it is just me. Where is the any key again?
  26. 1 point
    Chris setup with forEach. StampinVop_cd_fix_forEach.hip
  27. 1 point
    There are a couple of VEX functions you can use to help stick particles to an object, volumesample() and volumegradient(). You will have to convert your cherry geometry into a vdb to make it work. Multiplying the returned values together (and negating the volumegradient) and adding the result back onto the particle position. The code should be put in a POP wrangle and looks like this: @vs = volumesample(1, 0, @P); v@vg = volumegradient(1, 0, @P); @P += @vs * -@vg; The "1" means to look at the POP wrangles second input, which I've set to the cherries vdb. The "0" means it's looking at the first primitive of that input. @P is the current position of the particle This should work with both pops and flip. I've attached a hip file trying to recreate that gif you linked. the above setup can be found in the DRIP_SIM section cherries_colliding.hipnc
  28. 1 point
    What platform, graphics card, and driver version are you using?
  29. 1 point
    Add a GLSL Shader parameter to the material (Edit Rendering Parameters, Material Option > OpenGL) and put the path to glsl .prog file into the field. GLSL shaders are responsible for a lot more than just surface shading, so you need to be careful what GL geometry types you apply the shader to. Any GLSL shader with a geometry shader stage will require a specific GL input type (triangles, lines, points), and be much more restricted as to what they can be applied to (polys, curves, particles). Others have more implicit targets, like a hair shader requiring lines or particle sprites requiring points, but not outright failing if you don't pass it the right geometry.
  30. 1 point
    I did a little python toolset to speed up my VEX writing. It replaces "code shortcuts" into "code snippets" and also updates the parm interface (default values, channel ranges from comments, ramps are generated from custom library). You can build your own libraries of snippets with specific channel ranges and defaults. I am really python newbie, so it is "alpha". The code is not prepared for exceptions, it is not exemplary, but I hope it would help somebody. It helps me already so I will debug it on the fly. The initial idea comes from here, Matt Estela: http://www.tokeru.com/cgwiki/index.php?title=HoudiniUserInterfaceTips#customise_right_click_menus qqReplace.py rampCollect.py updateInterfaceFromComments.py
  31. 1 point
    Here's some introductory docs from the Houdini documentation to get you started. https://www.sidefx.com/docs/houdini/shade/opengl.html https://www.sidefx.com/docs/houdini/shade/glsl.html
  32. 1 point
    ver 2: improved...but the Flakiness in Twisting is due to the Bridge, how far apart the holes are...and their size....that influence the fuzziness of the bridging.. Vu_InterlockMobius_02.hipnc
  33. 1 point
    there's problems with Bridge Twisting, can't be ar**ed fixing it....I blame Houdini... Vu_InterlockMobius.hipnc
  34. 1 point
    can be done...now just gotta work out a neat procedural way for the interconnections...
  35. 1 point
    in a mean time you might want to play with GraphBorderWidth: inside NodeGraphCommon.inc
  36. 1 point
    Hello, here is some of my attempts to do something similar. But I can't get a similar level of detalization in mantra. If somebody can suggest some tips it wound be amazing volume is still a little bit blurry, I guess it could be because of texture resolution vol-0001_volume_v01.hip
  37. 1 point
    I won't claim this will fix everything...coz the polyexpand2d is a bit temperamental... polyfill_workaround3.hipnc
  38. 1 point
    @old school That is cool stuff for the academically inclined, but for those that are not or when you have a model to deliver by the end of the work day, it all becomes info noise in a modeler's eyes and ears. I hope that by know the devs in charge of these modeling tools have taken notice regarding the need of a interactive poly create tool and they've started the work on a shiny new "polyknit" tool. Or extend the current polyfill's capabilities to be usable as such. And then add even more, like for example the ability to draw polys on "screen space" and even creating polys as new separate objects by invoking the tool with nothing selected. I use the "polyknit" equivalent in Softimage for all these things and it's an invaluable tool for quick object sketching to act as a starting point for more detailed work. @Noobini How do you mean it's fundamentally wrong, as in buggy or badly written or the wrong tool for this case? If you specify the group of edges to be applied to (select the edges before calling teh polyfill) it works flawlessly. This probably goes to show that even this node doesn't stand the test of proceduralism, so to speak, even though that was probably its intended usage.
  39. 1 point
    Thx Iskander. Really nice job. I've got 1.4 FPS on my laptop with your original scene (without trail node calculation) and decide to do optimization of kernel code with some tricks and reached to 3.4 FPS (2.5 times faster). What I did is: - moved calculation of softening_squared outside of kernel so it is precomputed once and passed to kernel - removed double index and multiplication of second index for proper position in float3 array by using vload3 and vstore3 to fetch and store vector data from GPU memory to register and vice versa - used optimized vector routines in calculus instead calculating values per each vector component - provided extra arrays to store newpos and newvel vector values and - used them in writeBack kernel to store values back to attributes instead of using extra pointwrangle node Here is modified version nbody_opencl_modified.hipnc Cheers and thank again
  40. 1 point
    Dear Sir, I believe the Polyfill SOP is fundamentally wrong. By definition, it should fill in HOLES. So here's my extremely simple illustration. As you can see, yes, there are 2 borders, one inside and one outside...but there is only ONE hole. The problem is Polyfill is filling in both borders instead of just as it says in the helpcard..."Fills holes with polygonal patches." So you see in my illustration, the problem can be seen clearly, yes I exaggerated the effect with the Surface Offset...but even if you use Quad settings instead of Triangle...you may see flat surfaces...but don't be fooled into thinking it's done it right, it's filling in both front/back on top of each other. Attached is my file for closer examination. And a jolly good day to you sir. (ps: I can see you taking my grid with a hole and extrude/morph its topology into a tube and argue that...well it does have 2 holes...but I'm not a Rhodes Scholar...more like Roads Kill Scholar...anyway...too much postulating already...) polyfill.hipnc
  41. 1 point
    A real tough condition for procedural tools to fill those holes. I used a curve SOP then mirrored a couple times to fill in the holes. And those four holes will create a polygon that is concave. Not a very good primitive to render with many engines, or to pass on to a game engine as triangulating that face may cause overlaps. Polyfill sees the input as degenerate which means there are one or more cases where things are ambiguous. Consider that there are six open conditions that it considers to fill. The four holes, the perimeter of the frame and the perimeter of the exuded oval. Instead I reworked your file to be more procedural. Where the original grid and circle are properly configured, skinned and then three methods to create the extrusion: your existing polyextrude SOPs (fussy approach), using a single poly extrude and it's ramp lookup for the extrusion, sweep SOP to sweep a profile curve to create the profile. You can change the window outline, the padding of the circle to the perimeter and anything else you want to drive procedurally. What's also nice is that the topology is rock solid and you can create an infinite number of variations. Begging to be turned in to an HDA. manifold_geo_window_frame.hip
  42. 1 point
    is it just me or has SESI put some of the snippets here into their H16.5 ?: C:\Program Files\Side Effects Software\Houdini 16.5.268\houdini\VEXpressions.txt (yes...my head is swelling at an alarming rate...)
  43. 1 point
    Maybe 3 scene files(in comments) from this video will be useful too(sadly russian,very good quick start). p.s It will also be useful to look inside Attribute Blur(principle of organization of variables with various input data types) and HeightFiledErode(principle of operation with volumes via openCL)nodes.And inside files in /opt/hfs16.0/houdini/ocl/
  44. 1 point
    You need to get an instance of hou.Geometry. Sometimes there is no easy way to track what set of calls you need to get hou.Something. You may try to construct it by calling hou.Something(). It may throw an "AttributeError: No constructor defined", which is, I think, will happen with most of hou classes. Even if you can construct hou.Geometry, you obviously need a specific geometry, not an empty one. Fortunately, any SopNode seems to have a Geometry. Here is Python Shell example: >>> node = hou.node('/obj/geo1/platonic1') >>> geo = node.geometry() >>> bb = geo.boundingBox() >>> bb <hou.BoundingBox [-0.92793, 0.92793, -0.975684, 0.975684, -0.789344, 0.789344]> >>> mv = bb.minvec() >>> mv <hou.Vector3 [-0.92793, -0.975684, -0.789344]> >>> tuple(mv) (-0.9279304146766663, -0.9756839275360107, -0.7893444299697876)
  45. 1 point
    Hi. After some research I developed the concept of the surface shader to make shading artist work more efficient. A while ago I have implemented it in VEX and now I want to share it with you. GitHub Features: PhySurface VOP Energy conserving surface model PBR and RayTrace render engines support GTR BSDF with anisotropy (also avaible as a separate VOP node) Conductor Fresnel Volume absorption Raytraced subsurface scattering Artist-friendly multiple scattering (also avaible as a separate VOP node) Ray-marched single scattering Translucency Dispersion Thin sheet dielectric Transparent shadows Extra image planes support Per-component image planes Per-light image planes Variance anti-aliasing support Layered material Nesting material PhyVolume VOP Color scattering and absorption Per-light image planes PhyShader v1.2.0 - download: This is usability release. BSDF has changed to GTR New artist-friendly SSS Added layer support Added metallic desaturation Improved dispersion Materials: Added PhySurface Layered material Added PhySurface Nested material Improved PhySurface material Viewport support UI: New Inside IOR presets menu Changed dispersion presets menu Numerous bugfixes
  46. 1 point
    Gifstorm! First I've used a visualizer sop to show @v coming out of the trail sop: That makes sense so far. To make the next step easier to understand, I've shrunk the face that sits along +Z, and coloured the +Y face green, +X red, +Z blue. So, that done, here's that cube copied onto the points, with the v arrows overlaid too: The copied shapes are following the velocity arrows, but they're a bit poppy and unstable. So why are they following, and why are they unstable? The copy sop looks for various attributes to control the copied shapes, @v is one of them. If found, it will align the +Z of the shape down the @v vector. Unfortunately what it does if it has only @v is a little undefined; the shapes can spin on the @v axis when they get near certain critical angles, which is what causes the popping and spinning. To help the copy sop know where it should aim the +Y axis, you can add another attribute, @up. I've added a point wrangle before the trail, with the code @up = {0,1,0}; ie, along the worldspace Y axis: you can see all the green faces now try and stay facing up as much as they can (note the view axis in the lower left corner), but there's still some popping when the velocity scales to 0, then heads in the other direction. Not much you can do about that really, apart from try some other values for @up, see if they hide the problem a little better. What if we set @up to always point away from the origin? Because the circle is modelled at the origin, we can be lazy and set @up from @P (ie, draw a line from {0,0,0} to @P for each point, that's a vector that points away from the origin): Yep, all the green faces point away from the center, but there's still popping when @v scales down to 0 when the points change direction. Oh well. Maybe we can venture into silly territory? How about we measure the speed of v, and use it to blend to the @up direction when @v gets close to 0? Better! Still a bit poppy, but an improvement. Here's the scene with that last setup: vel_align_example.hipnc To answer the other key words in your topic title, I mentioned earlier that the copy sop looks for attributes, obviously @v and @up as we've used here, but if it finds others, they'll take priority. Eg, @N overrides @v. @N is still just a single vector like @v, so it too doesn't totally describe how to orient the shapes. You could bypass the trail and the wrangle so that there's no @v or @up, set @N to {0,1,0}, and all the shapes will point their blue face towards the top. Without any other guidance, it will point the red side of the shapes down +X. If you give it @N and @up, then it knows where point the green side, and you get a well defined orientation. While using 2 attributes to define rotation is perfectly valid, there are other options. The one that trumps all others is @orient. It's a single attribute, which is nice, and its party trick is that it defines orientation without ambiguity, using a 4 value vector. The downside is quaternions aren't easy to understand, but you don't really need to understand the maths behind it per-se, just understand what it represents. The simplest way is to think of it as @N and @up, but glommed into a single attribute. Another way is to think of it as a 3x3 matrix (which can be used to store rotation and scale), but isolated to just the rotation bits, so it only needs 4 values rather than 9 values. In houdini, you rarely, if ever, pluck quaternion values out of thin air. You normally generate what you need via other means, then at the last minute convert to quaternion. Lots of different ways to do this, coming up with ever funkier smug ways to generate them in 1 or 2 lines of vex is something I'm still learning from funkier smug-ier co-workers. Eg, we could take our fiddled @v, and convert it to a quaternion: @orient = dihedral({0,0,1} ,@v); What that's doing is taking the +Z axis of our shape-to-be-copied, and working out the quaternion to make it align to @v. You could then insert an attrib delete before the copy, remove @N, @v, @up, and now just with the single @orient, all the shapes rotate as you'd expect. vel_align_example_orient.hipnc
  47. 1 point
    Python SOP executes the code every time the node cooks as it is usually used to change the geometry since you don't use it to change geometry you don't need to use Python SOP at all just create digital asset, store your code in it's python module and call from the interface here is the file with included HDA, which contains mentioned changes (you can continue work on your code in HDA's python module) occlusionPassesDev.0.1.4_mod.hipnc
  48. 1 point
    I'll just leave this one here. Very easy and controllable way to add details to the simulation, that I wanted to try for such a long time. Cheers! DOP_particleVorticles_v08.hiplc
  49. 1 point
    Do FX like the guys at Weta, Pixar, ILM, Framestore! http://brianritz.com/houdini_fx.html
  50. 1 point
    http://www.scratchapixel.com/ Claims to be "the first complete interactive resource on the web for anyone (beginner or expert) who seeks to learn 2D and 3D computer graphics techniques from the ground up."