Welcome to od|forum

Register now to gain access to all of our features. Once registered and logged in, you will be able to contribute to this site by submitting your own content or replying to existing content. You'll be able to customize your profile, receive reputation points as a reward for submitting content, while also communicating with other members via your own private inbox, plus much more! This message will be removed once you have signed in.

Leaderboard


Popular Content

Showing most liked content since 04/23/2017 in all areas

  1. I want to share a little tool I made for grooming feathers. Its a set of 6 nodes, one base node and 5 modifiers. Super easy to use. Just connect them and.. there you go - you got yourself a pretty little feather. You can layer modifiers as many as you want. Any feedback is super appreciated. https://www.dropbox.com/sh/8v05sgdlo5erh0b/AADSfadqkxgPOBVeaGr2O49Oa?dl=0
    16 likes
  2. Hi friends! I just released an article on Medium walking through how I built a "Compute Dual" wrangle in VEX. As a quick summary, I basically wanted to know how the "Compute Dual" feature of the divide sop worked, so i slapped together a neat lil wrangle, to do just that! CLICK ME TO GO TO THE ARTICLE!!!!!!!! Here's a cute little gif showing off the construction of a dual graph. If you like it, please check out the article, it's free and it'd mean the whole world to me! =) Love you fools, Jake http://jakericedesigns.com/
    9 likes
  3. I wanted to see if I could play a video in Houdini using some python. With this as the result. Don't think it's the first time this is done but it is still nice to see. The result
    8 likes
  4. Hello everyone, This is a simple introduction to using Vex.
    6 likes
  5. I was experimenting with ways to add the spring asset I made post sim. It was a little tricky to extract the spring constraints and replace them, but I cracked it eventually. I also did a very un-houdini-like test where I just copied the spring asset a bunch of times and attached it to an old bit of geo I had lying around. Sorry about the colors on this one. I don't really give it much thought before I hit the render button and go to bed. I posted the hips here. As always, most have ROPs that will need to be re-rendered to see anything. I also locked the geo into the scenes, so they are heavier than usual.
    6 likes
  6. Hi, I just released a new tutorial about lighting and rendering with Mantra in Houdini. Over 5+ hours of content. Topics include Cameras, Lights, Lighting Setups, Materials and Shaders, Render Settings, and Scene Management. If you don't know where to start with Mantra, or with lighting and rendering, in general, this is a pretty good, comprehensive explanation: http://helloluxx.com/product/houdini-training-learn-jumpstart-vol-8-intro-to-lighting-rendering/ -Adam
    6 likes
  7. I love springs, but never attempted to make them in Houdini. I spent a few days making a SOP asset to do it. There's 4 types. 2 with hooks on the ends, 1 terminating in central lines, and another that has no end. There's also ramps for adjusting the radius and the distribution of the coils. All you need to do is feed it two points and it should just work........ The interface is not that great, some parameters dont do anything for certain spring types. Its not the fastest, its mostly made in VEX, and there are no uv's. All the stretching and scaling is also done in VEX that gets slow once there's tons of points. I put the hip here - http://richardlord.tumblr.com/post/159989136826/i-made-a-quick-spring-asset-because-i-love-springs
    5 likes
  8. Hi folks..another project: I did that JellyFisfh using only particle..I hope like
    5 likes
  9. Here is simple version based on Python implementation. // Primitive wrangle. // http://preshing.com/20110831/penrose-tiling-explained/ int pts[] = primpoints(0, @primnum); vector a = point(0, "P", pts[0]); vector b = point(0, "P", pts[1]); vector c = point(0, "P", pts[2]); float g = (1 + sqrt(5)) / 2; vector p = a + (b - a) / g; vector q = b + (a - b) / g; vector r = b + (c - b) / g; #define RED true #define BLUE false #define SAME @group_reversed #define REVERSED !@group_reversed void triangle(vector a, b, c; int red_or_blue, same_or_reversed) { int prim = addprim(0, "poly"); addvertex(0, prim, addpoint(0, a)); addvertex(0, prim, addpoint(0, b)); addvertex(0, prim, addpoint(0, c)); setprimgroup(0, "red", prim, red_or_blue); setprimgroup(0, "reversed", prim, same_or_reversed); } if (@group_red) { triangle(c, p, b, RED, SAME); triangle(p, c, a, BLUE, SAME); } else { triangle(r, q, a, RED, REVERSED); triangle(q, r, b, BLUE, REVERSED); triangle(r, c, a, BLUE, SAME); } // Lengths of virtual edges to group for dissolve later. setdetailattrib(0, "virtual_edge_long", distance(a, c)); setdetailattrib(0, "virtual_edge_short", distance(p, b)); removeprim(0, @primnum, true); penrose.hipnc
    4 likes
  10. Studying VEX i create penrose tile setup, maybe it will be interesting for someone who is beggining scripting in vex. HIP https://www.dropbox.com/s/m6ysgiljl7m0k40/penrose_tile.hip?dl=0
    4 likes
  11. It's possible to drag cameras and lights onto the viewport and it will cause the viewer to look through them. It's also possible to write a shelf tool type thing and assign a hotkey to it to cause the active viewer to look through a selected camera/light.
    4 likes
  12. Tried to recreate manvsmachine and mill line growth effect. If interest hip is in vimeo description. https://vimeo.com/216659184 https://vimeo.com/216657273
    4 likes
  13. You have an awesome start man, no worries. I can see that you did try and do a lot of experimenting. I'll try and clear up some things for you (to the extent of my knowledge). Be ready for quite a bit of reading. How do I get the gradient working in the vop First off, to better understand how to manipulate volumes, you must first have a clearer idea what a volume really is in Houdini, especially what kind of data it holds. Because these data are the stuff that we going to be manipulating. Let's start from scratch.. a simple Box polygon: Box Let's convert it to a Volume primitive using an IsoOffset SOP (or a VDB from Polygons): Fog Volume Notice the default settings, it is of Output Type: Fog Volume. So from a Box which consisted of points and polygon primitives, we now have these: What happened to the data? Where are the Box's points and polygons info? Those are now gone, you now have to deal with voxels instead. Volume Representation I'm guessing you know much of this already, but just bear with me for a bit Now, I think this is where the interesting part comes in.. How are these voxels accessed in Houdini? You can think of it as manipulating images in Photoshop.. or more precisely, manipulating pixels, but in 3d. The simple description is that voxels are just 3d pixels. So let's keep things simple.. if for instance, we just take a "slice" from the 3d voxel grid like so: Volume Slice We will be left with just this simple 2D flat grid. We could now safely assume that this grid also has coordinate data, like a standard digital image, it has pixel x and y coordinates. X & Y Coordinates Going further to simplify things, let us isolate just the x coordinate for now: X Coordinates Only Notice that these are just rows of repeating sequence of numbers going from 0 to the max resolution of an axis --- in this case up to 9: Max Resolution in X is 9 To recap a bit, we now have a bunch of data to work with: * X Axis Coordinates = {0,1,2,3,4,5,6,7,9} * X Axis Resolution = 9 At this point, you might ask what can we do with these numbers? We can now use it for our Ramp Parameter. But an intermediate step is needed first. Something that is usually called normalization. We need to normalize it.. which basically means convert it to a range between 0 and 1. Mathematics and Computers just love em zeroes and ones! To go about doing that, the simplest way is to do division math. We divide each value in an X Coordinate by the X Resolution like so: The result thereof: Now we have usable values for the Ramp! We can now proceed to feed it to the Ramp and remap the values to build our custom falloff. Here is the manually adjust ramp to represent the falloff for the X Axis: And the resulting values of the remapping: Finally, almost done, we now have the falloff computation and what we need to do is to just pipe these values out as the Density. In VEX, you can see this happening as the last line of the code: In VOPs, you simply wire it out to the Density output: * Remember, since we're manipulating volumes.. we need to use the Volume VOPs variant in SOPs. The resulting volume now looks like this: As you may have noticed, this is just the X-Axis. The last and easiest thing to do is to simply repeat/duplicate the process for the remaining Y and Z axes then multiply them together to form the 3d falloff volume. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Now loaded with the information above, here is how you would apply it in VOPs: First, this shows the equivalent built-it variables that I used in VEX for Volumes: Left: Wrangle | Right: Volume Vop Next, following the 1st block of vex code, we do the conversion from "Integer" to "Float" so that we could divide the values with much more precision. Also, I subtract 1 from the resx, resy, and resz variables because the resolution value returns an amount that did not count from 0. Image showing just the x-axis setup. Apply the same nodes for the Y and Z axis. The 2nd block of code now deals with using the computed value (which is now in the range of 0-1) for the ramp. TIP: Use the same name for the Ramp Parameter for each of the axes to have just a single Ramp Parameter control up the UI. So even if we dropped 3 Ramp Parameter VOPs, with using just a single name "myRamp", there would only be one control to rule them all. Finally, on the last line. We just do a simple multiplication for all 3 values and write it out to density. And of course, here's the updated file: H16.0.557 Indie - box_falloff_vop.zip How do I visualize my gradient to check its working? You must be confusing the term/variable that I used in the Volume Wrangle whose names are "gradx", "grady", and "gradz" as the equivalent of the Volume Gradient VOP, which is actually not. These names are arbitrary, I could have named the variables anything.. like potato: ..And this will still work. So, for rebuilding the box volume falloff, you don't need the Volume Gradient VOP (I'll try and may do a separate explanation of this on a different post >_<) Maybe to rephrase your question: "How do I visualize my volume to check it's working?" And to answer that: For quick and simple visualization, I usually just use the Volume Slice SOP. Play around with it to see what it does. How do I get that inside the DOP to drive the force? I hope this graph would help you visualize the flow: On my example hip file above this post, if you check the Pop Wrangle node inside the particle sim DOP, you'll notice the Inputs tab. That is how the wrangle is reading the falloff volume we created from outside the DOP network. In the VEX code, by using the volumesample() function, we can then transfer the density volume data to our particles using any custom attribute. In this case, I simply created and named it "amt" for amount. (again it can be anything, like banana) Using our newly created variable "amt", it can then be used in inside vexpressions to do our calculations. Like multiplying it against the Force parameter to control the intensity. Note that this is just one method of getting data from outside Dops. You'll discover other ways as you venture out here in the forums I hope you did not fall asleep from this long post, and that my explanation at least made some sense haha Cheers!
    4 likes
  14. Dot node can survive Y scissoring. The dot is persistent, if you click on the dot again with Alt. EDIT: btw you can also color the dot.
    3 likes
  15. 3 likes
  16. Advanced sourcing for Houdini. it’s not only 10-100x faster but also gives more control over sourcing especially when many sources involved in sim. Houdini16 Hipfile with examples included https://github.com/abryutinalexey/vdb_to_field
    3 likes
  17. 3 likes
  18. Hi all, I've just finished a little personal project that was featured in our studio (Tendril) during the welcome party for the last FITC/Toronto. All Houdini and Mantra. Cheers
    3 likes
  19. Thank you! Here are some new projects I haven't shared in here yet.
    3 likes
  20. I have a hip file I use a bunch which contains some of the common tricks I always need, but constantly forget how to do. I thought i'd share it. Mostly its VEX/VOPS stuff to manipulate point transforms, a lot of it revolves around creating and using the orient attribute. I'll update it as I go I imagine. When I discover something new, I plan to throw it in here to prevent it eroding from my brain. Must give a shout out to mestela - http://www.tokeru.com/cgwiki/index.php?title=HoudiniVex , f1480187 and anim, who have helped me understand these things a bunch (even if they don't realize it). Thanks chaps! http://richardlord.tumblr.com/post/159277887181/ive-started-collecting-a-bunch-of-tricks-i-use-a
    3 likes
  21. I made some renders using the constraints on impacts setup I made. The sims are pretty crappy, but the basics of the system seems to work solidly enough. It would just be a matter of tweaking all the settings to get a smoother result. Each pair of RBDs gets no more than 1 constraint. I think it might work better if I allowed a few more, as the RBDs can spin around on this constraint, which looks a bit unstable. I posted the hip files for this over here: http://richardlord.tumblr.com/post/159194692191/crappy-sims-of-a-system-that-builds-constraints-at
    3 likes
  22. There is no mystery as to how Houdini works. Anything that gets done in Houdini can be expressed by a node. Whether that node is a coded c++ operator, an operator written in VEX (or using VOP nodes representing vex functions), Python operators or Houdini Digital Assets (HDA's), each node does it's own bit and then caches it's result. There is no lower level than nodes. The nodes in Houdini are the lowest level atomic routine/function/programme. A SOP node for example takes incoming geometry and processes it all in of itself, then caches it's result which is seen in the viewport, MMB on the node as it's stats and in the Details View to see the specific attribute values. If this is a modifier SOP, it will have a dependency on it's input node. If there is an upstream change, the current node will be forced to evaluate. If there is a parameter reference to another node and the other node is marked "dirty" and affects this node, this node will have been forced to evaluate. To generalize the cooking structure of a SOP network, for every cook (frame change, parm change, etc), the network starts at the Display/Render node and then walks up the chain looking for nodes with changes and evaluates dependencies for each node also querying those nodes for changes until it hits the top nodes. The nodes marked dirty causing the network to evaluate the dirty nodes top down evaluating the dependencies that were found. You can set a few options in the Performance Monitor to work in the older H11 way and see this evaluation tree order if you wish. Change that. It is "mandatory" that you do this if you want a deeper understanding of Houdini. You definitely need to use the Performance Monitor if you want to see how the networks have evaluated as it is based on creation order along with the set-up dependencies. Yes deleting and undeleting an object can and will change this evaluation order and can sometimes get you out of a spot with crashing. If you haven't used the Performance Monitor pane, then there you go. Use it. Just remember to turn it off as it does have an overhead performance wise. Another key is to use the MiddleMouseButton (MMB) on any and all nodes to see what they have cached from the last cook evaluation. Memory usage, attributes currently stored, etc. the MMB wheel on my mouse is as worn in as the LMB as I use it so much. You can see if the node is marked as time dependent or not which will affect how it evaluates and how it will affect it's dependent nodes. You can RMB on the node and open up the Dependency view for that operator which will list all references and dependencies. You can hit the "d" key in the network and in the parameter display options, in the Dependency tab, enable the various dependency aids (links and halos) in the network to see the dependencies in the network. Houdini is a file system, in memory, and on disk in the .hip "cpio" archive file. If you want, you can use a shell, and given any .hip file, run the hexpand shell command on the file. This will expand the Houdini file in to a directory structure that you can read and edit if you so wish. Then wrap it back up with hcollapse. If you really want to see how Houdini works low level, then this how it all ends up, and how it all starts. It's just hscript Houdini commands that construct the nodes including the folder nodes themselves. Each node is captured as three distinct files: the file that that adds the node and wires it up to other nodes, the parameter file that sets the nodes parameters, and another file that captures additional info on the node. If you locked a SOP, then that binary information will be captured as a fourth file for that node. It is for this reason that .hip files are very small, that is unless you start locking SOPs and that is not wise. Better to cache to disk than lock but nothing stopping you. When you open up a .hip file, all the nodes are added, wired, parameters modified and nodes cooked/evaluated. There are different types of node networks and nodes of a specific type can only be worked on in specific directory node types. This forces you to bop all over the place, especially if you still willingly choose to use the Build desktop which I do not prefer. You have to have a tree view up somewhere in the interface to see how the network lays out as you work. It's also very handy for navigating your scene quickly. The Technical Desktop is a good place to start when working on anyone's file as there is a tree view and a few other panes such as the Details View, Render Scheduler and more. If you want to use the technical desktop and follow a vid done with the Build desktop, simply switch up the Network with the Parameter pane and now the right hand side is the same as Build, but now you can follow the tree view and see where and when other nodes are dropped down. A new Houdini file is an unread book, full of interesting ideas. Using a desktop that exposes a tree view pane, you can quickly see what the user has been up to in a couple seconds. Again use the Technical Desktop as a start if you are still using Build (if you know me you will know I will force you to have a tree view up). You can quickly traverse the scene and inspect the networks. If that isn't enough, you can pop open the Performance Monitor and see what nodes are doing the most work. You really don't need any videos, ultimately just the .hip file. Helps if the scene is commented and nodes named based on intent. Let's stick to SOPs. In Houdini, attributes are an intrinsic part of the geometry that is cached by each SOP. Not some separate entity that needs to be managed. That is what makes SOPs so elegant. That wire between two SOPs is the geometry being piped from one SOP to the next, attributes and all. Not a link per attribute (which in other software can be a geometry attribute, parameter attribute, etc). This makes throwing huge amounts of geometry with lots of attributes a breeze in Houdini. All SOPs will try their best to deal with the attributes accordingly (some better than others and for those others, please submit RFE's or Bugs to Side Effects to see if there is something that can be done). You can create additional geometry attributes by using specific SOPs: - Point SOP creates "standard" point attributes - Vertex SOP creates "standard" vertex attributes - Primitive SOP creates "standard" Primitive attributes - Use the Attribute Create SOP to create ad-hoc attributes with varying classes (float, vector, etc) of type point, vertex, primitive or Detail. - Use VEX/VOPs to create standard and ad-hoc point attributes. - Use Python SOPs to create any standard or ad-hoc geometry attributes. One clarification that must be made is the distinction between a "point" and a "vertex" attribute in Houdini. There are other softwares that use the term vertex to mean either point attributes or prim/vertex attributes. Games have latched on to this making the confusion even deeper but alas, it isn't. In Houdini, you need to make the distinction between a point and a vertex attribute very early on. A point attribute is the lowest level attribute any data type can have. For example, vector4 P position (plus weight for NURBs) is a point attribute that locates a point in space. If you want, that is all you need: points. No primitives what so ever. Then instance stuff to them at render time. You can assign any attribute you want to that point. To construct a Primitive, you need to have a point for the primitive's vertices to reference as a location and weight. In the case of a polygon, the polygon's vertices is indexing points. You can see this in the Details View when inspecting vertex attributes as the vertex number is indicated as <primitive_number>:<vertex_number> and the first column is the Point Num which shows you which point each vertex is referencing as it's P position and weight. Obviously you can have multiple vertices referencing a single point and this is what gives you smooth shading by default with no vertex normals (as the point normals will be used and automatically averaged across the vertices sharing this point). In the case of say a Primitive sphere, there is a single point in space, then a primitive of type sphere with a single vertex that references that point position to locate the sphere. Then there is intrinsic data on the sphere (soon to be made available in the next major release) where you can see the various properties of that sphere such as it's bounds (where you can extrapolate the diameter), area, volume, etc. Other primitive types that have a single point and vertex are volume primitives, metaball primitives, vdb grid primitives, Alembic Archive primitives, etc. How does a Transform SOP for example know how to transform a primitive sphere from a polygonal sphere? Answer is that it has been programmed to deal with primitive spheres in a way that is consistent with any polygon geometry. Same goes for Volumes. It has been programmed to deal with Volumes to give the end user the desired result. This means that all SOPs properly coded will handle any and all primitive types in a consistent fashion. Some SOPs are meant only for Parametric surfaces (Basis SOP, Refine SOP, Carve SOP, etc.) and others for Polygons (PolySplit, etc.) but for the most part, the majority of SOPs can work with all primitive types. What about attributes? The Carve SOP for example can cut any incoming polygon geometry at any given plane. It will properly bi-lineraly interpolate all attributes present on the incoming geometry and cache the result. It is this automatic behaviour for any and all point, vertex, primitive and detail Attributes that makes working with SOPs a breeze. How does Houdini know what to do with vertex attributes when position P, velocity v and surface normal N need to be handled differently? When performing say a rotate with a Transform SOP and the incoming geometry has surface normals N, velocity vector v, and a position cache "rest", each attribute will be treated correctly (well N because it is a known default attribute but for user-defined attributes, you can specify a "hint" to the vector that will tell it to be either vector, 3 float position, or of type surface normal). It is this auto-behaviour with attributes and the fact you don't need to manage attributes makes using SOPs so easy and very powerful without having to resort to code. Remember that each SOP is a small programme unto it's self. It will have it's own behaviours, it's own local variables if it supports varying attributes in it's code logic, it's own parameters, it's own way of dealing with different primitive types (polygons, NURBs, Beziers, Volumes, VDB grids, Metaballs, etc). If you treat each SOP as it's own plug-in programme, you will be on the right path. Each SOP has it's own help card which if it is authored correctly will explain what this plug-in does, what the parameters do, what local variables are available if at all, some other nodes related to this node, and finally example files that you can load in to the current scene or another scene. Many hard-core Houdini users picked things up by just trolling the help example files and this is a valid way to learn Houdini as each node is a node and a node is what does the work and if we were to lock geometry in the help cards the Houdini download would be in the Gigabytes so nodes are all that is in the help cards and nodes is what you need to learn. I'm not going to touch DOPs right now as that is a different type of environment purpose built for simulation work. Invariably a DOP network ends up being referenced by a SOP to fetch the geometry so in the end, it is just geometry which means SOPs. Shelf tools are where it's at but I hear you. Yes there is nothing like being able to wire up a bunch of nodes in various networks and reference them all up. Do that for a scratch FLIP simulation once or twice, fine. Do that umpteen times a week, well that is where the Shelf Tools and HDA's make life quite simple. But don't be dismayed by Shelf Tools. All of those tools are simply executing scripts that place and wire operators together and set up parameter values for you. No different than when you save out a Houdini .hip scene file. If you are uber-hard-core, then you don't even save .hip files and you wire everything from scratch, every time, each time a bit different, evolving, learning. So with the shelf tool logic you find so objectionable, if you open up an existing .hip scene file, you are also cheating. Reminds me of the woodworker argument as to what is hand built and what isn't. I say if you use anything other than your teeth and fingernails to work the wood, you are in essence cheating, but we don't do that. Woodworkers put metal or glass against wood because fingernails take too long to grow back and teeth are damaged for ever when chipped. And I digress... Counter that to power users in other apps that clutch to their code with bare white knuckles always in fear of the next release rendering parts of their routines obsolete. With nodes, you have a type name and parameter names. If they don't change from build to build, they will load just fine. I can load files from before there were .hip files and they were called .mot (from Sage for those that care to remember) from 1995. Still load, well with a few meaningless errors but they still load. A Point SOP is a Point SOP and a Copy SOP is a Copy SOP. No fear of things becoming obsolete. Just type in the "ophide" command in the Houdini textport and you will still find the Limb and Arm SOPs (wtf?). LOL! First thing I do every morning? Download latest build(s). Read the build journal changes. If there is something interesting in that build, work up something from scratch. Then read forums time permitting and answer questions from scratch if I can. All in the name of practice. Remember from above that a .hip file is simply a collection of script files in a folder system saved on disk. A Houdini HDA is the same thing. A shelf tool again is the same thing: a script that adds and wires nodes and changes parameters. Not pounding a bunch of geometry and saving the results in a shape node never to have known the recipe that got you there. To help users sort out what created which node, you can use the "N" hotkey in any network and that will toggle the node names from the default label, the tool that added that node and finally nothing. Hitting "N" several times while inspecting a network will toggle the names about. That and turning on the dependency options in the network will help you see just what each shelf tool did to your scene. Knowing all this, you can now troll through the scene and see what the various shelf tools did to the scene. If you like to dig even deeper, you can use the Houdini textport pane and use the opcf (aliased to cd), opls (aliased to ls), and oppwf (aliased to oppwd and pwd) to navigate the houdini scene via the textport as you would in a unix shell. One command I like to show those more interested in understanding how Houdini works is to cd to say /obj then do an opls -al command to see all the nodes with a long listing. You will see stats very similar to those found in a shell listing files or if you RMB on any disk file and inspect it's info or state. Remember Houdini "IS" a file system with additional elaborate dependencies all sorted out for you. There are user/group/other permissions. Yes you can use opchmod (not aliased to chmod but easily done with the hscript alias command) to change the permission on nodes: like opchmod 000 * will remove read/write/execute permissions on all the nodes in the current directory and guess what? The parameters are no longer available for tweaking. Just remember to either tell your victim or to fix it for them or you may be out of a job yourself. opchmod 777 * gives back the permissions. An opls -al will verify this. Now you know what our licensing does to node states as you can set the state of a node to be read and execute only but remove the write to any DOP or POP node and you have a Houdini license while a Houdini FX license will enable the write to all nodes in all networks. Also knowing this, the .hip file truly is a book with a lot of history along with various ways of inspecting who created what node and when, what tool was used to create this node, what dependencies are on this node, is it time dependent, and more, all with a quick inspection. After all this, learning Houdini simply becomes learning each node in turn and practice, practice, practice. Oh and if you haven't figured out by now, many nodes have a very rich history (some older than 30 years now) and can do multiple things, so suck it up, read the node help cards, study the example files and move forward. The more nodes you master, the more you can see potential pathways of nodes and possibilities in your mind, the faster you work, the better you are. The more you do this, the more efficient your choices will become. The learning curve is endless and boundless. All visual. All wysiwyg.
    3 likes
  23. Would it be possible for dots to survive scissoring their inputs
    2 likes
  24. this isn't necessarily true and depends on which type of dual you are using. in case of houdins barycentric based dual for instance, it isn't true. if you wanna get voronoi cells you have to compute the circumcentric (voronoi) dual instead. in this case the dual is orthogonal to it's primal triangulation which is one of the key properties of a voronoi. dual1.hipnc
    2 likes
  25. Your gif is pleasing. It is a pleasing gif.
    2 likes
  26. Also for a bit of a shorthand: http://www.sidefx.com/docs/houdini/vex/functions/ow_space http://www.sidefx.com/docs/houdini/vex/functions/wo_space
    2 likes
  27. I just made my first HDA I have also used custom Handle and Guide Geometry to easily animate and preview. I hope you will like it, but also you may experience some difficulties using it, as I am still newbie. My questions: The Ramp - adding new ramppoints and renaming the node itself is tricky ... please, how do you bind VOP to HDA? - problem is, that new points have relative path ch("../../linear1/values_ramp4value") instead of simple ch("../values_ramp4pos") HDAs: - please, is it good practice to save all my HDAs here? C:\Users\Administrator\Documents\houdini16.0\otls - I should add parameters only in the "Type Properties", right? Not in the "Edit Parameter Interface" - is it good practice to have some string parameter "Output Attribute Name" and then use "Set Attribute VOP"? ... I have the output attribute name hardcoded as I was affraid of performance loss VOPs: - is it better to use Get Attribute or the Import Point Attribute? Both work well. - inside an IF block, I output values to Cd to preview them ... and even when the IF should be skipped, Cd gets default values ... that is probably ok and inevitable, right? I will probably add some noise controls into the ramp. Any comments and suggestions are highly appreciated. linear.hdalc
    2 likes
  28. if (isvalidindex(arr, find(arr, value))) { do this }
    2 likes
  29. 2 likes
  30. I got some help from Solitude on Discord. The reason the Glue bonds re-appear every frame is because that is the constraint network default. Select your WOOD constraint network and on the Data Options tab change the purple Overwrite with SOP right-click and choose Delete Channels. This will leave you with a value of 1 which means import glue bonds every time the frame changes. Install the following code into the field. $F==1 This will cause the Glue bonds to only be imported on frame #1. This way when the bonds are broken they are not fetched back in every time the frame changes. You will need to make this change to all the various constraint networks in your scene (i.e. WOOD, BRICKS, BASE etc..) Once I did this you original scene started working for me. ap_Destruction_v5_t4.hiplc
    2 likes
  31. I was going to RFe a control for that but it's already there! Connection Snap Radius in Preferences/Network Editor, Nodes and Trees. I turn it right down to avoid the loop snapping.
    2 likes
  32. And to implement the "blow off" just drop down a PopNetwork right after the Scatter. Inside there is a a PopForce that uses the surface normal for velocity to expand outwards, other forces can work too. The activation of this velocity is controlled by an expression $F > 15. So you can pick what time/frame you want the expansion to occur. ap_quick_align_normals_OD.hipnc
    2 likes
  33. Check out Matt's example file here.
    2 likes
  34. I spoke with one of the paper's author and he mentioned that, "The implementation of the underlying MPM solver was done in OpenVDB and all the meshing and renderings where done with Houdini (using the native VDB nodes)."
    2 likes
  35. The popkill sets a the @dead attribute to 1, you can do the same in a popwrangle or directly delete the particles with the "removepoint" function. in a popwrangle (make sure you set your input1 as your curve SOP) // if the points are not within the search radius, delete them if(pcnumfound(pcopen(0,"P",@P,chf("radius"),1))==0)removepoint(0,@ptnum);
    2 likes
  36. 2 likes
  37. @marty@Infinite Rave Here's an attempt at creating convincing white hair. Funny trivia: polar bears are "actually" black - they have black skin and their fur strands are transparent. Multiple passes of light diffuse and refraction when it passes through each strand, makes the polar bear's fur look white. Inspired by this fact, that white hair IRL is actually transparent hair without pigment, I went and set the transparency (opacity tab of the hairshader) to a very low value. Also enabled "transparent shadows". Keep in mind that these will increase render times. A lot. The scene is lit with one direct light and an env. one. As soon as you add an hdr map, it will tint the color of the white hair. Ideally one would keep the original env. map for the entire scene and use a desaturated version of it (B&W is unrealistic) just for the hair. THis could be achieved in Houdini with light exclusions, but ideally one should be able to plug an env. map just for the hair material instead of using multiple lights. If this were Mentalray I'd tell you how to do that, alas it's Mantra and I don't know how or if it's at all possible. If Houdini wouldn't keep me way with its poor viewport and traditional modeling tools I'd probably be a lot more competent with Mantra too. In the image to the right is the default hair shader with colors set to white only and to the left with all the other adjustments. The lighting and all other settings are identical. Make sure you don't miss the attached .rar file - I've included the .hdr map so you'll get exact same results and if after your own experimentation you get better looking results and render times, don't forget to post them here. white_hairball.rar
    2 likes
  38. Ban network wiring that loops back on itself - don't know of any reason for it and can crash Houdini.
    2 likes
  39. Hey - here is a super basic version where the plastic moment is based on a kinetic threshold. BoxCrash.hiplc
    2 likes
  40. Open source project initiated by Oliver Hotz to copy and paste points, polygons and respective attributes across multiple apps. This is not an asset transferring mechanism but an on-the-project quick way to transfer geometry without file management concerns (You don't file manage your clipboard right?) Try it out and contribute! https://heimlich1024.github.io/OD_CopyPasteExternal/ Cheers
    2 likes
  41. 2 likes
  42. These are brilliant Rich. Every damn one.
    2 likes
  43. Something I`m working on right now. Rendered with Arnold in C4D.
    2 likes
  44. if you are using houdini 16, just include complex.h in your vex code. it´s in $HFS/houdini/vex/include.
    2 likes
  45. Here is collection of breakdowns for a project I was working on during last half of a year Vimeo album: https://vimeo.com/album/4471569 Or individual videos:
    2 likes
  46. 2 likes
  47. I think Cristin mentioned it in the launch event, but but in case anyone missed it: Nearly all the areas presented in H16 will continue on into the next dev cycle. That's not to say other projects won't be started, just that we'll be building on the cool stuff presented in H16.
    2 likes
  48. Hi everybody! Since I started to share a few of my projects in here, I thought that I just carry on, even though the "12 seconds.." title is not fitting anymore. Here is my latest work, enjoy!
    2 likes
  49. 2 likes
  50. 2 likes