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.


Popular Content

Showing most liked content since 07/20/2017 in Posts

  1. 57 likes
    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.
  2. 51 likes
    Hi all, I had been doing a rnd project on how to generate knitted garments in Houdini lately. And one my inspiration was from a project which was done by Psyop using Fabric engine and the other one is done by my friend Burak Demirci. Here are the links of them. http://fabricengine.com/case-studies/psyop-part-2/ https://www.artstation.com/artist/burakdemirci Some people asked to share my hip file and I was going to do it sooner but things were little busy for me. Here it is, I also put some sticky notes to explain the process better, hope it helps. Also this hip file is the identical file of the one that I created this video except the rendering nodes https://vimeo.com/163676773 .I think there are still some things that can be improved and maybe done in a better way. I would love to see people developing this system further. Cheers! Alican Görgeç knitRnD.zip
  3. 39 likes
    There are so many nice example files on this website that I am often searching for. I wanted to use this page as a link page to other posts that I find useful, hopefully you will too. Displaced UV Mapped Tubes Particles Break Fracture Glue Bonds Render Colorized Smoke With OpenGL Rop Moon DEM Data Creates Model Python Script Make A Belly Bounce Helicopter Dust Effect Conform Design To Surface Benjamin Button Intro Sequence UV Style Mapping UV Box and Multiple Projection Styles Ping Pong Frame Expression Instance vs. Copy (Instance Is Faster) Particle Bug Swarm Over Vertical and Horizontal Geometry Rolling Cube Rounded Plexus Style Effect Pyro Smoke UpRes Smoke Trails From Debris Align Object Along Path Fading Trail From Moving Point Swiss Cheese VDB To Polygons Get Rid Of Mushroom Shape In Pyro Sim A Tornado Ball Of Yarn Particles Erode Surface Unroll Paper Burrow Under Brick Road Non Overlapping Copies Build Wall Brick-By-Brick FLIP Fluid Thin Sheets Smoke Colored Like Image Volumetric Spotlight Moving Geometry Using VEX Matt's Galaxy Diego's Vortex Cloud Loopable Flag In Wind Eetu's Lab <--Must See! Wolverine's Claws (Fracture By Impact) Houdini To Clarisse OBJ Exporter Skrinkwrap One Mesh Over Another Differential Growth Of Curve Over Surface Rolling Clouds Ramen Noodles Basic Fracture Extrude Match Primitive Number To Point Number Grains Activate In Chunks Fracture Wooden Planks Merge Two Geometry Via Modulus Fill Font With Fluid DNA Over Model Surface VDB Morph From One Shape To Another Bend Font Along Curve Ripple Obstacle Across 3D Surface Arnold Style Light Blocker Sphere Dripping Water (cool) Exploded View Via Name Attribute VEX Get Obj Matrix Parts eetu's inflate cloth Ice Grows Over Fire Flying Bird As Particles DEM Image To Modeled Terrain Pyro Temperature Ignition Extrude Like Blender's Bevel Profile Particles Flock To And Around Obstacles BVH Carnegie Mellon Mocap Tweaker (python script) Rolling FLIP Cube Crowd Agents Follow Paths Keep Particles On Deforming Surface Particle Beam Effect Bendy Mograph Text Font Flay Technique Curly Abstract Geometry Melt Based Upon Temperature Large Ship FLIP Wake (geo driven velocity pumps) Create Holes In Geo At Point Locations Cloth Blown Apart By Wind Cloth Based Paper Confetti Denim Stitching For Fonts Model A Raspberry Crumple Piece Of Paper Instanced Forest Floor Scene FLIP pushes FEM Object Animated Crack Colorize Maya nParticles inside an Alembic Path Grows Inside Shape Steam Train Smoke From Chimney Using Buoyancy Field On RBDs In FLIP Fluid Fracture Along A Path COP Based Comet Trail eetu's Raidal FLIP Pump Drip Down Sides A Simple Tornado Point Cloud Dual Colored Smoke Grenades Particles Generate Pyro Fuel Stick RBDs To Transforming Object Convert Noise To Lines Cloth Weighs Down Wire (with snap back) Create Up Vector For Twisting Curve (i.e. loop-d-loop) VDB Gowth Effect Space Colonization Zombie L-System Vine Growth Over Trunk FLIP Fluid Erosion Of GEO Surface Vein Growth And Space Colonization Force Only Affects Particle Inside Masked Area Water Ball External Velocity Field Changes POP particle direction Bullet-Help Small Pieces Come To A Stop Lightning Around Object Effect Fracture Reveals Object Inside Nike Triangle Shoe Effect Smoke Upres Example Julien's 2011 Volcano Rolling Pyroclastic FLIP Fluid Shape Morph (with overshoot) Object Moves Through Snow Or Mud Scene As Python Code Ramp Scale Over Time Tiggered By Effector Lattice Deforms Volume Continuous Geometric Trail Gas Enforce Boundary Mantra 2D And 3D Velocity Pass Monte Carlo Scatter Fill A Shape Crowd Seek Goal Then Stop A Bunch Of Worms Potential Field Lines Around Postive and Negative Charges Earthquake Wall Fracture Instance Animated Geometry (multiple techniques) Flip Fluid Attracted To Geometry Shape Wrap Geo Like Wrap3 Polywire or Curve Taper Number Of Points From Second Input (VEX) Bullet Custom Deformable Metal Constraint Torn Paper Edge Deflate Cube Rotate, Orient and Alignment Examples 3D Lines From 2D Image (designy) Make Curves In VEX Avalanche Smoke Effect Instant Meshes (Auto-Retopo) Duplicate Objects With VEX Polywire Lightning VEX Rotate Instances Along Curved Geometry Dual Wind RBD Leaf Blowing Automatic UV Cubic Projection (works on most shapes) RBD Scatter Over Deforming Person Mesh FLIP Through Outer Barrier To Inner Collider (collision weights) [REDSHIFT] Ground Cover Instancing Setup [REDSHIFT] Volumetric Image Based Spotlight [REDSHIFT] VEX/VOP Noise Attribute Planet [REDSHIFT] Blood Cell Blood Vessel Blood Stream [REDSHIFT] Python Script Images As Planes (works for Mantra Too!) Dragon Smashes Complex Fractured House (wood, bricks, plaster) Controlling Animated Instances Road Through Height Field Based Terrain Tire Tread Creator For Wheels Make A Cloth Card/Sheet Follow A NULL Eye Veins Material Matt Explains Orientation Along A Curve Mesh Based Maelstrom Vortex Spiral Emit Multiple FEM Objects Over Time Pushing FEM With Pyro Spiral Motion For Wrangle Emit Dynamic Strands Pop Grains Slope, Peak and Flat Groups For Terrains Install Carnegie Mellon University BVH Mocap Into MocapBiped1 Ramp Based Taper Line Fast Velocity Smoke Emitter Flip Fill Cup Ice Cubes Float [PYTHON]Export Houdini Particles To Blender .bphys Cache Format Collision Deform Without Solver or Simulation Useful Websites: Tokeru Houdini Houdini Vex Houdini Python FX Thinking iHoudini Ryoji Video Tutorials: Peter Quint Rohan Dalvi Ben Watts Design Yancy Lindquist Contained Liquids Moving Fem Thing Dent By Rigid Bodies Animating Font Profiles Guillaume Fradin's Mocap Crowd Series(no longer available) Swirly Trails Over Surface http://forums.odforce.net/topic/24861-atoms-video-tutorials/ http://forums.odforce.net/topic/17105-short-and-sweet-op-centric-lessons/page-5#entry127846 Entagma SideFX Go Procedural
  4. 33 likes
    I've wanted to tackle mushroom caps in pyro sims for a while. Might as well start here... Three things that contribute greatly to the mushroom caps: coarse sub-steps, temperature field and divergence field. All of these together will comb your velocity field pretty much straight out and up. Turning on the velocity visualization trails will show this very clearly. If you see vel combed straight out, you are guaranteed to get mushrooms in that area. If you are visualizing the velocity, best to adjust the visualization range by going forward a couple frames and adjusting the max value until you barely see red. That's your approximate max velocity value. Off the shelf pyro explosion on a hollow fuel source sphere at frame 6 will be about 16 Houdini units per second and the max velocity coincides with the leading edge of the divergence filed (if you turn it on for display, you'll see that). So Divergence is driving the expansion, which in turn pushes the velocity field and forms a pressure front ahead of the explosion because of the Project Non-Divergent step that assumes the gas is incompressible across the timestep, that is where where divergence is 0. I'm going to get the resize field thingy out of the way first as that is minor to the issue but necessary to understand. Resizing Fields Yes, if you have a huge explosion with massive velocities driven by a rapidly expanding divergence field, you could have velocities of 40 Houdini units per second or higher! Turning off the Gas Resize will force the entire container to evaluate which is slow but may be necessary in some rare cases, but I don't buy that. What you can do is, while watching your vel and divergence fields in the viewport, adjust the Padding parameter in the Bounds field high enough to keep ahead of the velocity front as that is where you hope for some nice disturbance, turbulence and confinement to stir around the leading edge of the explosion. or... Use several fields to help drive the resizing of the containers. Repeat: Use multiple fields to control the resizing of your sim containers. Yep, even though it says "Reference Field" and the docs say "Fluid field..", you can list as many fields in this parameter field that you want to help in the resizing. In case you didn't know. Diving in to the Resize Container DOP, there is a SOP Solver that contains the resizing logic that constructs a temporary field called "ResizeField", importing the fields (by expanded string name from the simulation object which is why vector fields work) with a ForEach SOP, each field in turn, then does a volume bound with the Volume Bounds SOP on all the fields together using the Field Cutoff parameter. Yes there is a bit of an overhead in evaluating these fields for resizing, but it is minor compared to having no resizing at all, at least for the first few frames where all the action and sub-stepping needs to happen. Default is density and why not, it's good for slower moving sims. Try using density and vel: "density vel". You need both as density will ensure that the container will at least bound your sources when they are added. Then vel will very quickly take over the resizing logic as it expands far more rapidly than any other field in the sim. Then use the Field Cutoff parameter to control the extent of the container. The default here is 0.005. This works for density as this field is really a glorified mask: either 0 or 1 and not often above 1. Once you bring the velocity field in to the mix, you need to adjust the Field Cutoff. Now that you have vel defined along side density, this Field Cutoff reads as 0.005 Houdini units per second wrt the vel field. Adjust Field Cutoff to suit. Start out at 0.01 and then go up or down. Larger values give you smaller, tighter containers. Lower values give you larger padding around the action. All depends on your sim, scale and velocities present. Just beware that if you start juicing the ambient shredding velocity with no Control Field (defaults to temperature with it's own threshold parameter so leave there) to values above the Field Cutoff threshold, your container will zip to full size and if you have Max Bounds off, you will promptly fill up your memory and after a few minutes of swapping death, Houdini will run out of memory and terminate. Just one of the things to keep in mind if you use vel as a resizing field. Not that I've personally done that... The Resolution Scale is useful to save on memory for very large simulations, which means you will be adjusting this for large simulations. The Gas Resize Field DOP creates a temporary field called ResizeBounds and the resolution scale sets this containers resolution compared to the reference fields. Remember from above that this parameter is driving the Volume Bound SOP's Bounding Value. Coarser values leads to blurred edges but that is usually a good thing here. Hope that clears things up with the container resizing thing. Try other fields for sims if they make sense but remember there is an overhead to process. For Pyro explosions, density and vel work ok. For combustion sims like fire, try density and temperature where buoyancy contributes a lot to the motion.
  5. 29 likes
    Coarse Sub-Steps If you have an expanding gas field front that from frame 1 to 2 or frame 2 to 3 travels one or two Houdini units and substeps are set to 1, you will get combed straight velocity vectors which means mushroom caps. No matter how much turbulence or confinement you set on your Pyro Solver DOP, there simply isn't enough time to evolve these fields and have an effect on the result. More substeps means smaller velocities to deal with between substeps making things more manageable too. In an attempt to keep substeps at 1, you can manufacture noise and pump that in to vel but in the end two things will happen: The Non-Divergent step will take your noise and negate most of it, or you end up pumping in so much noise because it isn't working with smaller values you tried earlier, that it swamps the entire effect and it looks like a fractal hash and not that nice evolving fireball. Oh and if you really pump in tons of noise in to vel, it too can create many smaller velocity fronts pushing ahead and you end up with smaller mushroom caps! Doh... This is in essence what the Gas Disturbance DOP does. The Pyro Solver has a Gas Disturbance DOP in it's logic and those parameters are promoted up to the top asset interface but we're concerned about substeps right now and allowing enough time for turbulence and confinement to create the nice swirls on the leading edge of the explosion. So it's coming down to sub steps to try and allow for a lot more character around the leading pressure front for fast evolving explosion type simulations. Two ways to go about this: Brute force increase the global substeps for the entire DOP network, or use the Pyro Solver Substeps in the Advanced tab. Brute Force Global Substeps For explosions, the huge almost instantaneous velocities happen at the first 5-10 frames. It would be nice to keyframe animate the Sub Steps parameter, but you can't (DOPs is that way). If you set the global sub-steps to get enough detail in the first few frames you have to carry those sub-steps through the rest of the sim when things are moving a lot slower and those substeps are no longer required. Not that great. No wonder everyone tries to inject their own pumps to affect vel to avoid global substepping. Pyro Solver Substeps The Pyro Solver exposes minimum and maximum substepping logic to control when and how the Pyro Solver will substep. This sounds interesting and could be just what we need. But what is CFL Condition? No it isn't the Canadian Football League even though we know that 3 downs rule and 4 downs are for those that can't deal 3. It's named after a couple guys who in the '20's, that's 1920's, who were trying to figure out the frequency of data samples they required in order to map and predict fluid simulations and pressures/resistance to flow with fast moving collision objects (that be ships). The help note on the actual Gas SubStep DOP explains it quite well: timestep will be reduced if the velocity field will move only 1 voxel in a timestep. A CFL of 2 will allow it to move 2 voxels in a timestep. Or something like that. You can find it on wikipedia. You can set your minimum substeps to 1 and your maximum substeps to a high enough value such that if the CFL Condition is exceeded, more substeps will occur when the simulation has large velocities and less when the velocity is smaller. Hopefully this gives enough time to let the turbulence and other methods to stir up the vel field kick in. Keyframe Timescale There is a third option to controlling sub steps but that is to keyframe animate the Timescale. Yes more than valid to do this to slow down the sim at the start and then speed up when the huge velocities subside. As a matter of fact, the shelf tools set Timescale to 0.65 as an attempt to get a good looking explosion or fireball without having to resort to substeps. But this is not an automatic method. This requires intervention if you want to animate the timescale. This means you have to run the sim and evaluate. Then you keyframe the timescale and you end up with an entirely different simulation. Then you move your keys, run again. Then you increase the resolution of the simulation and everything changes again. In many ways, it's worth to at least give the min and max substeps a go and see if you can dial in the CFL Condition to get a happy balance. As you increase the resolution of the simulation, the CFL condition measured in voxels will allow substeps to run up a bit faster to the max without too much of a change in the final result.
  6. 28 likes
    Hi all! New version of the setup for H14. The scene is much better organised and optimised. There also some new features which makes this setup actually very useful. Have Fun! DOP_DynamicFracture_H14_v09.hiplc
  7. 27 likes
    Project Non-Divergent Step and Mushrooms The Project Non-Divergent DOP is responsible for 99.9% of the simulation's behaviour. Yes hundreds of DOPs inside the Pyro Solver all playing a part but all funnelling through that single Non-Divergent step. This means that if you don't like the look of your sim and the mushrooms, it's ultimately because of the Non-Divergent step creating a vel field that doesn't do it for you. If you want to see for yourself, unlock the Pyro Solver, dive in, find the Smoke Solver, unlock that, dive in and find the projectmultigrid DOP and bypass it, then play. Nothing. For most all Pyro sims, this is the Project Non-Divergent Multigrid as it is the fastest of the Non-Divergent micro-solvers. This specific implementation only takes the vel and divergence field and assuming across the timestep that the gas is non-compressible when divergence is 0, will create a counter field called Pressure and then apply that pressure field to the incoming vel to remove any compression or expansion and that gives you your velocity, nice turbulent and swirly, or combed straight out. Just tab-add a Project Non-Divergent Multigrid DOP in any dop network and look at the fields: Velocity Field, Goal Divergence Field and Pressure Field (generated every timestep, used, then removed later on). All the other fields in Pyro are there to affect vel and divergence. Period. Nothing else. At this point I don't care about rendering and the additional fields you can use there. It's about vel and divergence used to advect those fields in to interesting shapes, or mushrooms. If you want to create your own Pyro Solver taking in say previous and new vel, density, temperature, and then in a single Gas Field VOP network, create an interesting vel and divergence field, then pass that straight on to the Project Non-Divergent Multigrid microsolver, then advect density, temperature and divergence afterward, go for it. Knowing that only vel and divergence drive the simulation is very important. All the other fields are there to alter the vel and divergence field. So if you have vel vectors that are combed straight, divergence (combustion model in Pyro) or buoyancy (Gas Buoyancy DOP on temperature driving vel) have a lot to do with it. Or a fast moving object affecting vel...
  8. 26 likes
    Temperature Field and Divergence Field and what to do about it Combed straight velocities lead to mushroom puffs. Large directional forces lead to combed straight velocities. The pressure wave leading the divergence field leads to combed straight velocities. So what to do? Looking at Temperature first, it is directly used with Gas Buoyancy to drive the intensity whereby the upward direction is multiplied by temperature and then added to vel. Temperature is also used to burn fuel at an ever increasing rate with higher temperatures which then ultimately affects the divergence field. Temperature is also used by some of the shaping tools to inject noise or trigger confinement within the simulation, amongst other fields. Temperature and Gas Buoyancy DOP High temperature values fed in to the Gas Buoyancy DOP will affect the velocity field quite effectively, in a singular direction no less, the buoyancy direction. This inherently leads to nicely combed velocity with higher temperature values and large amounts of buoyancy as the simulation evolves which leads to nice mushrooms leading the way. Just like in real explosions and initial bursts of hot smoke/steam. But the director always wants more "character". That's fine and manageable in most cases as the velocities aren't that large, especially in smoke simulations where the temperature is driven by the sources. In the case of explosions, the burning of fuel can create very high temperatures and cause large upward velocities. Working Temperature with Disturbance By default the Disturbance field affects temperature. It is also cited as one way to break up or diminish the mushrooms. But how and why? And does it work? Using disturbance is designed to add noise to the temperature field around the simulation. This is one way to try to kick or disturb the rising velocity field, in an indirect way though. For Pyro, temperature is used to ultimately affect vel in two ways: Buoyancy and Combustion (which inevitably drives the divergence field). What is Divergence? Well it's randomly generated noise. It's not time coherent turbulence. Yep. If you dive down in to the Gas Disturbance DOP, in to the disturb_field Gas Field VOP you will find a lowly random VOP that is fed a vector 4 (vector P and an animated offset) and generates random incoherent noise per substep. If this sounds desperate, well it kinda is. But it works very well in some cases to etch the leading edge of the velocity to cause eddies that then form ripples and swirls. Think volcano smoke. Disturbance can be applied to temperature and it will eventually have an effect, or you can have it work directly on the velocity for a brute force immediate effect to try to etch away at that leading velocity front generated by the rapidly expanding divergence field. if it is strong enough and if it is localized to just around the evolving sim so that our container doesn't resize to maximum and take too much memory and take too long to simulate, it can work very well. Perhaps this is why the shelf tools only allows for a small value relative to the velocities that are present in an explosion or fireball: it doesn't really work for these types of sims at it's defaults. We have all of the necessary tools to implement this well enough. The Gas Disturbance DOP built in to the Pyro Solver and exposed as the Disturbance parameters can do this. It has support for a control field and even a ramp with min and max threshold values to really dial this in, if you have a field to use that is... For Smoke and combustion fire type simulations (no explosions), you can gleefully use the density field as both your Threshold Field to control the cut-off threshold for the disturbance and as the field to control the amount of disturbance you want. Or use temperature as the Control Field as with rising smoke, the temperature tends to lead the density. For fast rising smoke, you can set the Control Field to temperature and then use the Control Range to say 0 and 0.1 to try to etch the velocity field prior to it being run over by the advancing wave. For Explosions, there is feint hope. Unless you envelop the entire container with shredded velocity, there is no other field at your disposal to use to control where the disturbance should be applied. Yes you can create an additional field containing an expanded divergence field to try this, but there's better ways to coax swirls in the initial part of the explosion. In the end, as with all the other shaping tools, it comes down to magnitude. If the magnitude of the previous frame's velocity is much larger than the velocity shaping amplitude, knowing that velocities are for the most part added or subtracted in most simulation engines, you aren't going to see much effect, especially after the Non-Divergent step gets rid of most of this random pressure hash anyway. When you are dialling in a sim, you have to have the vel on for display and adjust the Visualization Range (working the leading red envelope) to get an idea as to where the velocity is fastest and what those values are (in Houdini units per second). If you have a velocity of 10 in the leading velocity pressure front and you set disturbance amplitude to 0.5, you know it won't have much of an effect. One thing that will have an effect is to apply Disturbance directly to vel for explosions and apply it within the divergence, burn, temperature or any other field that's playing a role in the fireball itself. But not to the surrounding area unless again you bypass the resizing of the container. Heck you don't even need to bypass the resize container DOP. If you are resizing on density and vel, the container will max out after the second or third frame anyway. And you can live with completely incoherent noise that for the most part is wiped out by the Non-Divergent counter pressure field. Divergence and Burning Fuel The divergence field in explosions and fireballs is the main contributor to mushroom caps over the first second or so. It will comb the velocity vectors perfectly straight in the leading pressure wave advancing in front of the density, temperature, fuel, whatever. We know why. It's the Non-Divergent step trying to remove any pressure across the timestep outside of the divergence field. It makes perfect sense then that when carefully inspecting the velocity around the leading edge of the divergence, you will find the greatest velocities. Divergence pushing outward creating a large pressure front causing the Non-Divergent step to add a very large counter pressure field that gives you that front of straight combed velocity. Large amounts of burning fuel (fuel + temperature = burn, divergence (gas expansion) then uses burn and fuel to drive the expansion of the sim) leads to a strong divergence field. Gas Buoyancy affects vel very effectively and divergence allows for rapid expansion. How do the explosion and fireball shelf tools try to avoid mushrooms? Well we see that the timescale is reduced for both options in an attempt to add enough time to evolve interesting swirls in the simulation as it evolves. But for many cases doesn't give you that nice character over the first few frames of the simulation. We also see Disturbance added but at a meagre 0.75 Shredding is set to 1. Shredding is a very nice tool for adding character to fire. As it's name implies, within the threshold tolerance of the effect, the velocity field is either stretched along a gradient direction or compressed. It is the transition between the two that gives you the real nice licks of fire. Shredding defaults to 1 and it has visualization option to see where this shredding occurs and how strong it is by it's color in relation to the velocity. If you look at the shredding, by default it is being applied along the surface of the temperature field where the Threshold Width is being set. Again this won't work for the first second of the explosion. Same for Turbulence and Confinement. They too work within the fireball and not the leading edge of the explosion. so what to do?
  9. 14 likes
    Use VDB point advection to output geometry. You need to compute a velocity vector, it's up to you. For example, just a curl noise (first image) is a good starting point, as well as cross product of @N and position delta using point cloud (second image, some noise applied also). It may be anything you could imagine, from fluid trails to volume thickness. curlypig.hipnc
  10. 12 likes
    Hello Everyone, This is a recording of the presentation I gave at the sidefx booth at GDC. Topic: Creating a custom grooming system in Houdini for VFX and Games. Chapters: --Hair grooming For VFX. --Auto generating cards with texture for Real-time rendering. --Exporting the hair for real-time rendering using Nvidia Hairworks. I hope you guys like it! If you have any questions please feel free to email me at sabervfx@gmail.com Link: https://vimeo.com/sabervfx/hairfx Thanks Saber
  11. 12 likes
    Sounds like a typical space colonization task. spacecol_zombie.hipnc
  12. 12 likes
    // Point wrangle. #define PI 3.1415926535897932384 float u = fit01(@u, -PI, PI) * ch("revolutions"); vector pos = set(sin(u), cos(u), 0) * ch("radius"); matrix3 t = set(v@tangentu, v@N, v@tangentv); @P += pos * t; Where tangents and normal was computed by PolyFrame SOP, and @u is 0..1 point's position on curve. spiralize.hipnc
  13. 12 likes
    There was an error in pop_too_close wrangle. It deleted both intersecting bubbles, not just the smaller one, drastically reducing bubblecount. Normally it should remove only degenerate bubbles almost enclosed by neighbours. It also seems that whole loop can be replaced with a point wrangle. So, it cooks instantly now, retains topology and scales better. Scattering and pscale setup really matters. You need to generate a good foam first, before doing intersections. The current setup should be improved somehow. bubbles2.hipnc
  14. 12 likes
    Try this... Put down a measure SOP and set it to measure the perimeter of your curves. After that a primitive wrangle and write. #include <groom.h> adjustPrimLength(0, @primnum, @perimeter, @perimeter*@dist); groom.h is a included file containing some functions used in the grooming tools and one of the functions is... void adjustPrimLength(const int geo, prim; const float currentlength, targetlength)
  15. 11 likes
    I am not sure if this has been posted before but just came across this site: http://wordpress.discretization.de/houdini/ To quote: "This website is here to help you to get started with Houdini in order to complete the Mathematical Visualization course at the Technical University of Berlin. The aim is to enable you to run your own geometry related algorithms while taking advantage of Houdini’s excellent visual graphics while avoiding to dig deep into the theory behind it." There seems to be some great material on here. In particular a unique way of getting scipy/numpy to work with Houdini - apparently you just copy and paste the entire anaconda 2.7 build into the Houdini python directory?! http://wordpress.discretization.de/houdini/home/advanced-2/installing-and-using-scipy-in-houdini/
  16. 11 likes
    hey all thought i'd just drop a grenade of Houdini work i put together over 2016 & early 2017 - nothing particularly complex - most of this is all stuff i've learnt off this forum and youtube video tutorials by ppl like @mestela @ParticleSkull @Farmfield @rohandalvi the guys at Entagma, Sidefx, and a bundle of other ppl whom i cant seem to tag like Ben Watts - i just want to say thankyou for all your help and tutorage on forums and the time you guys take to put all those epic videos together and encouraging me to learn cheers ant hoob (houdini noob geddit?!) this was my first project set in houdini - following tutorials and clearly inspired by Method (who isn't c'mon) and their video.. I then went away and did some more twiddling with sop based stuff to try some more fun effects - had alot of fun with this one - i love balloon boy lol... this was inspired by all the Hydraulic press channels and just trying a fun few setups... this one was inspired by Erik Fergusons fem stuff... and this one was an attempt to try some fun ragdoll/crowd sim stuff :)
  17. 11 likes
    Thank you ! Here it is the zip file including PDF and all the hip files with the ink setup and tornado setup. The scene files have been created with Houdini 15.5.632. Enjoy ! Hug_Nov2016-AlessandroPepe.zip
  18. 11 likes
    A lot of very advanced setups in this thread, just what I wanted to avoid when I created this. Sometimes you just need something simple. I feel almost ashamed to post a setup like this, but someone might have use for it. simple.edge.displace.v1.hiplc
  19. 11 likes
    ok, here is the example file with 4 ways (cache the instance geometry first, both blue nodes ) 1. (Purple) rendering points with instancefile attrib directly through fast instancing 2. (Green) overriding unexpandedfilename intrinsic for any packeddisk primitive copied onto points without stamping 3. (Red) just for comparison Instance SOP, which is using copy stamping inside, so it will be slower than previous methods 4. (Yellow) copying static alembic without stamping and overriding abcframe in this case to vary time for each instance independently (if you need various alembics you can vary abcfilename as well) ts_instance_and_packed_examples_without_stamping.hip
  20. 11 likes
    Basic: // Primitive wrangle. int pts[] = primpoints(0, @primnum); vector rest = point(0, "P", pts[0]); vector prev_pos = rest; matrix3 frame = ident(); for (int i = 0; i < len(pts); i++) { vector pos = point(0, "P", pts[i]); rotate(frame, 0.1, {0, 0, 1}); vector new_pos = (pos - rest) * frame + prev_pos; rest = pos; prev_pos = new_pos; setpointattrib(0, "P", pts[i], new_pos); } Advanced: // Primitive wrangle. #define TWO_PI 6.2831852 addpointattrib(0, "N", {0, 0, 0}); int pts[] = primpoints(0, @primnum); int npt = len(pts); // Loop variables. vector rest = point(0, "P", pts[0]); vector prev_pos = rest; matrix3 frame = ident(); for (int i = 0; i < npt; i++) { vector pos = point(0, "P", pts[i]); vector delta = pos - rest; rest = pos; // Make normal. Point normals could be used instead. vector normal = normalize(cross(cross({0, 1, 0}, delta), delta)); if (length(normal) == 0) { normal = {0, 0, 1}; } // Drive a shape with ramps and multipliers. vector axis; float ramp, angle; // Twist the bend axis. axis = normalize(delta); ramp = chramp("twist_profile", (float) i / npt); angle = fit01(ramp, -TWO_PI, TWO_PI) * ch("twist") / (npt - 1); rotate(frame, angle, axis); // Bend the curve. axis = normalize(cross(normal, delta)); ramp = chramp("bend_profile", (float) i / npt); angle = fit01(ramp, -TWO_PI, TWO_PI) * ch("bend") / (npt - 1); rotate(frame, angle, axis); // Compute new position and normal. vector new_pos = delta * frame + prev_pos; prev_pos = new_pos; setpointattrib(0, "P", pts[i], new_pos); setpointattrib(0, "N", pts[i], normal * frame); } curl.hipnc
  21. 10 likes
    Scene with test tornado. https://vimeo.com/58393324 tornado_v02.hip
  22. 10 likes
    The main thing you can learn from these types of things is the art of self promotion
  23. 10 likes
    I created a basic upres example. simple_upres_bunker.hipnc
  24. 9 likes
    Hello Everyone, I put together a short video tutorial on how to use the particle system to break glue bonds that are holding together fractured geometry. You can view the video here: I have other videos posted in this link as well. http://forums.odforce.net/topic/17105-short-and-sweet-op-centric-lessons/page-5#entry127846
  25. 9 likes
    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:
  26. 9 likes
    Hey Diego! Sure! Here is a very basic FLIP surface tension implementation using laplacian as a factor; You can change from Laplacian to Curvature to see some little differences, But for most cases Laplacian works better for my tests, and even better yet for smoke, as you can see in the example file, the FLIP sim behaves almost like a pyroclastic cloud at the begining, so imagine this in a gas sim. Hope That Helps! Alejandro ST_tutorial.hip
  27. 9 likes
    Twisting box http://beesandbombs.tumblr.com/post/109914868554/twisting-box bees_and_bombs_twisting_box.hipnc
  28. 9 likes
    I found here on forums quite good solution: * lower collision padding in rbd object * pop drag node (works with packed prims) with vex code: if (length(@v)<0.4) { airresist = 30; } * pop wrangle: if (length(@v) < 0.4) { v@w *= 0.85; // rotational velocity drag v@v *= 0.85; // velocity drag } if (length(@v) < 0.05 && @Frame > 50) { i@active = 0; }
  29. 9 likes
    A prototype for a job that never was: a scragly tree gets formed by growing wires: The bit that creates root-to-ends curves from an lsystem might be useful. It starts from all the end points, and walks down it's neighbors, always taking the neighbor with the lowest point number. Seems to work wiretree_v005.hip
  30. 8 likes
    During the last 3 weeks, a did some Rnd and published my results on vimeo . Some people asked me to share my files here, so here we are i hope it will help!
  31. 8 likes
    The Houdini node view explained - what it really is all about: Unbelievable :-) Cheers, Tom
  32. 8 likes
    HIP DOP_BendConstraint_v01_SIMPLE.hipnc
  33. 7 likes
    HI FRIENDS! So over the past year I've been doing far too much Houdini in my free time, and I noticed that all of the people I look up to in the community have their own cute ODForce threads. So with the release of my latest blog post on Voronoi Diagrams and Remeshing, I thought it best to make one of those threads, to avoid flooding the Education section with tons of new posts... Anyways here's a link to my new blog post: https://medium.com/@jakerice_7202/voronoi-for-the-people-60c0f11b0767 And if the link itself isn't enough, here are a couple of GIFs from the blog post, including one that didn't make the cut. All credit for the post title goes to @mestela <3 Big thanks to @toadstorm for editing my grammar as well, and the whole ThinkProcedural discord for putting up with my insanity
  34. 7 likes
    Here a quick Gif on a hda I'm working to smooth the seams of an boolean operation. You have control how far from the boolean seams you want to smooth the geometry. Nico
  35. 7 likes
  36. 7 likes
    Recently I wanted to make constraints based on impacts. I finally managed it. Here's the basics of the system. It uses a couple of ForeEach SOPs to step through and delete any constraint between the same two rbd's. Phew! This one was really tricky to work out. The hip file is available here
  37. 6 likes
    TOPs = Texel Operators. SOPs based, like DOPs. Fast texel-wise texture manipulation, painting and projection; new real-time texture generation workflow replacing render-time texture baking. Texels use optimized data structure and work faster than using dense meshes.
  38. 6 likes
    Hi Odforce! I present you my first personal project done entirely in Houdini. I basically learn the software throught this project and finally I came to the end of it. Please let me know what you think of the dynamics, the look and breakdown. I am really scratching the surface of Houdini so critics are well appreaciated! Ill update the hip file for those who wants to wonder around the network (H 14.0.474) thanks to the amazing Odforce community for helping me implementing the scene. meteorite_v100.zip
  39. 6 likes
    Hey guys, I worked on the simulations for this spot, it was my first serious houdini project, hope you like it
  40. 6 likes
    Hello community, I am creating this thread where I will be posting links to my tests, experiments, RnD's and other uncategorizable stuff. Also often I will include scene files so feel free to explore them and to learn how not to do things ...hope it will help somebody, somehow. Juraj
  41. 5 likes
  42. 5 likes
    hi, This is a shot I did with my colleague. This shot is a imitated shot from the Prometheus movie. So it´s not an creative achievement but it´s great to get deeper into Houdini and for learning some new techniques. We created this shot completely from scratch for ourselves to get more experience and speed in more cinematic like sequences which are a nice variety to our daily work. I was responsible for the ground setup, Lighting, Rendering, Compositing, FX. My colleague did all the animation, modeling of the rover and mountains, matte painting. Except modeling of mountains, camera animation and rover model everything is houdini. After a little RnD about the ifd workflow I was pretty surprised how well mantra performed with millions of stones and the ultra wide scale of the scene. Average rendertimes of the scene was around 10 minutes. Of course its no high-end quality but its the quality what we were able to achieve in the amount of time we had. We leave it like that for know and concentrate ourselves on the next shot I hope you like it. kind regards Jon
  43. 5 likes
    I've followed Allan for a long time and he's got good tips and general effects advice and has a lot of experience creating high end effects work. But his main tool is 3dsmax, so if you want to become an expert at that it might be worth it. If you want to learn Houdini at the high-end my vote would go to the CG Circuit series as well as Matt Estela's Tokeru mixed in with a bit of Entagma. Also on the main sidefx website you can go through the masterclasses too: https://sidefx.com/tutorials/?title=&user=&categories=&level=2&version=&paid= If you are near LA you could come take my houdini class at Gnomon. My class is an advanced houdini class, I used to teach the beginner and then the intermediate levels as well, but now I only teach the advanced Houdini level. My class goes into some of the underlying computer graphics principles and data management as well. Over the last 3 years I've taught around 30-40 new junior Houdini artists. The majority of them are all working as fx artists in the LA area. The main reason why I started teaching was to create a houdini talent pool in LA that I could draw from as an fx supervisor. Also to teach the knowledge that I think the students should know and that prepares them for industry. The side effect was that a bunch of other studios also gained access to more junior houdini talent and that some of the more traditional Maya or Max houses started to adopt Houdini in their fx pipeline. So by the time I need more mid level talent the original students have had a bit more experience at a variety of studios and then they can move around. Also I have directly hired students from my own course as production needs arose. Some of my students also became assistant technical directors or show technical directors because they gained a deep understanding of cg. This is the curriculum (10 weeks total, 3 hours per class, I think Gnomon charges students around $2k - so not cheap either) Class 1: Lightning bolts setup, tool building, custom mask for comp, case study Class 2: Clustering techniques for efficiently processing large volumetric data sets and breaking down complexity. Class 3: growth systems 1: growing patterns, tool building, chaos theory, feedback systems, growth behaviors, 2d & 3d growth, reconnecting branches. Class 4: growth systems 2: procedural animation, tool building, pathfinding, custom masks for comp. Class 5: Art directed destruction 1: rigid body dynamics, fracture patterns, constraint networks, case study Class 6: Art directed destruction 2: constraint networks, hero pieces flying at camera, secondary simulations Class 7: Art directed destruction 3: Destroying a production asset and bringing all elements together. Class 8: volumes 1: liquid explosion - pyro sim sourced from flip simulation, detailing sims and shader, fractals. Class 9: volumes 2: nebula, tornado, cloud puff, portal, and custom volumetric solver. Class 10: Controlling data through multiple phase changes - rigid, melting, liquid, evaporation, rigid Since you are in Canada, you might also want to consider Andrew Lowells program at Lost Boys - I've heard good things about it and Andrew is a long time houdini user as well: https://lostboys-studios.com/effects-technical-director-fx-td-program/ I think overall there are a lot of good resources available (mostly for free or for less than ~$500 online), it will mostly cost you time. There are no short-cuts. For me the in-person teaching experience is something I enjoy as well as you can instantly get a students level of understanding and expand on where they need more clarification or sometimes expand on a tangent that they are interested in. Also a physical teacher will generally have good ties with industry and can help you build connections. - I recommend each of my students to be active on the forums, post to vimeo and share some of their hip files so they can get to know the community and the community gets to know them. I just provide a stepping stone. Good luck!
  44. 5 likes
    Alexey Vanzhula Could you please create your own topic for Flux in forum. I think will be more interesting your topic like was made BulletSop. All information and video will be in one place and it will be more useful. This topic for Random links of interest. Thank you for understanding!
  45. 5 likes
    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!
  46. 5 likes
    Well really, is happening again, 16 is not even released and we start to ask about 17. Honestly give the guys a well deserved rest for a month, like they can enjoy what they have achieve in 16 which is huge, and then start to think in 17. Take it easy
  47. 5 likes
    Update: A new awesome method is to use an Attribute Wrangle set to "Run Over: Primitives" with the following code: First line adds a point to the center of every primitive. (I believe it uses the point average for the center). The second line is optional and removes the original primitives. Original thread: https://www.sidefx.com/index.php?option=com_forum&Itemid=172&page=viewtopic&t=35541
  48. 5 likes
    Here are some things that I used to do some crystals. Unfortunately i don't have a rendering at hand right now: I created a variety of crystal shapes with a for each loop using booleans. This worked surprisingly well. Next I created a system to semi randomly place those individual crystals to get the whole structure according to my needs. For rendering these are a couple of things that helped (beware, rendering times will go through the roof): - create internal geometry (cracks, bubbles, dirt) at rendertime using the vex volume procedural and rendering it as an isosurface. - use a varying IOR and maybe include some birefringement (double refraction) - for ultimate realism you should consider a small amount of dispersion - those quartz crystals tend to get cloudy at their root. Some SSS, very glossy refractions and/or translucency can help There are ressources which explain all the interesting optical phenomena that can happen in various crystals. I can see if I can find some RnD files on a backup drive, but chances are I don't have them anymore. Cheers, Dennis
  49. 5 likes
    Excellent, that worked. Thanks! For anyone interested: Go to the extra files pane in the type properties of your digital asset. On the bottom, type 'Presets' into the 'Section Name' field without selecting a file. Click 'Add Empty Selection'. That will create a Presets section. Then in the 'Filename' field, select your presets file. This will autopopulate the 'Section Name' field with the name of the presets file. Change this to 'Presets'. Click 'Add File' Your presets should now be added to (and stored in) the digital asset!
  50. 5 likes
    UVs will not help you in this case, neither area attribute or any other trick to get consistent pointcloud from scatter sop since even consistent pointcloud will fracture mesh slightly differently in each pose but you can do one very simple thing store animated positions as an attribute on a static geometry fracture that static geometry (that attribute will be interpolated to pieces) use that attribute as point positions to get it back to life here is the example fracture_01_fix.hipnc