Jump to content

Leaderboard


Popular Content

Showing most liked content since 10/19/2017 in all areas

  1. 14 points
    Few tips and tricks to manipulate gas simulation. 1. Independent resolution grid. E.g. Overriding vel grid size independent to a density grid. 2. Creating additional utilities. E.g. gradient, speed, vorticity and etc which can be used to manipulate forces. 3. Forces via VEX and some example snippets. smokesolver_v1.hipnc P.S. Some of this technique are not Open CL friendly though.
  2. 12 points
  3. 12 points
    Filament like structure, combination of Smoke Solver, VDB Advect Points + Volume Rasterize Particles. smokesolver_v3.hipnc
  4. 10 points
    Hi, I played around your scene a bit. This is the result. I also ended up changing your extrusion expression using exp() instead of pow(). The gist of it was to do 2 iteration phases. 1 is ahead, and the other is behind. Then just blend between those two. The challenging part was to create the attributes needed to specify the iteration level, and the blending amount (check the blend_and_iter wrangle node for how I processed it). Although this seems to chug to slow when there's already too many polygons to process. I wanted to place it inside a compiled block, but polyExtrudes are not yet compilable. H16.5.268 NC - Subdiv_Test_v2.rar
  5. 9 points
    Another, focused on instancing smoke objects. Manipulating points with basic instancing attributes, i@cluster, v@scale and f@sourceframe. How to activate smoke object and holding a volume source. This method ideal for triggering independent gas simulation on impact data. Additional examples, e.g. grid clustering method for trail and non-trail which I'm merging from a separate thread. smokesolver_v2.hipnc
  6. 8 points
    Hello, here you can download my files from softbody week-6 : You can use my files for your jobs or just for fun/learn/make tutorial/ whar ever . It's free BUT Keep in mind i am not a professionnal, so pay attention : i'm quite sure my way to work is not the best way to work in production/studio. cheers ! Yohann upres-shirt.hiplc balloon-v2.hiplc baloons-grain solver.hiplc upres-attribtransfer.hiplc upres-curvature.hiplc
  7. 7 points
    I had chance to test new Flip NarrowBand workflow and wanted to share resaults with community
  8. 7 points
    Yes you heard it right.
  9. 6 points
    Hi guys, Just want to showcase our work in progress and ask everybody's opinion. The demo is HERE. In short, were able to transfer Houdini vertex animation to a Web Browser. To accomplish that we used Houdini texture cache tools, 3js library, and tinyexr loader which was compiled to JavaScript. We are exited about the result and looking for a project to apply it. Kirill and Snay
  10. 6 points
    primuv already is basically a 2d representation of the primitive's footprint. a not-aligned bounding box of each primitive can also be found in the primitives intrinsics called "bounds". if you want to copy and squeeze models onto primitives I would create the copies first, create a "copynum"-attribute and distribute the models with something like this: vector bbox = relbbox(0, @P); int prim = point(0, "copynum", @ptnum); float height = sqrt( primintrinsic(1, "measuredarea", prim) ); @P = primuv(1, "P", prim, set(bbox.x, bbox.z, 0) ); @P += prim_normal(1, prim, {0.5, 0.5, 0}) * bbox.y * height; The bounding box from line 1 is stretched across the primitives from line 2 with primuv in line 4. The approximate height of the copies gets derived from the primitives area size in line 3 and is raised along the primitives normals in line 5. copy_on_prims.hipnc
  11. 6 points
    Inspired by couple of papers and Houdini tutorials I started playing with fractals and raymarching. Here are some of the results so far. EDIT: see the following post for the project file
  12. 5 points
    Hey I checked the logs and we were getting hammered from a social media crawler bot which was basically DOS'ing us. I've blocked it, so hopefully things will get better. The site seems snappier now, but we should keep an eye on it for a few days. Please reply here if things go south again. Thanks M
  13. 5 points
    Christian Arnesen did an awesome piece of animation with MASH, and I wanted to replicate it in Houdini: Here is the breakdown of 3 techniques for doing so, using Alembic caches, Copy Stamping, and VEX (file is attached below or at the link): Hope it's helpful! arnesen_cubes_in_houdini.zip
  14. 5 points
    My open source solution to render volume light effects in Houdini Mantra based on the first part of this paper. Equiangular sampling (better sampling around light sources) Per-Light export Physically correct result Support for colored absorption (attenuation) Source code and example here https://github.com/somesanctus/volumelight
  15. 5 points
    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!
  16. 5 points
    oflow will generate vectors per channel of your volume, I've found it cleaner and faster to just use alpha (so convert your image to luminance for example, and copy to A), then you get clean vectors to push to dops or whatever. optical_flow_flip.hipnc
  17. 5 points
    Launch Event in Toronto
  18. 4 points
    Hi Guys, Sharing my last projects with Houdini (as a hobbyist), for getting feedback and critics ! Destruction of a building from drone shot : https://vimeo.com/208997392 Tornado destruction of a farm / barn : https://vimeo.com/169982113 Kind regards
  19. 4 points
    It is now possible to get surface distance from the softselection with the new function of H16.5! geodesic_distance_softsel.hiplc
  20. 4 points
    Finally it's out!!! https://www.youtube.com/watch?v=KfaSxIkLslE [www.youtube.com] https://www.framestore.com/news/paddington-ms [www.framestore.com] A long journey, lots of artists involved and excruciating detail to be honest with such an amazing character. A lot of Houdini for all the VFX as you can imagine. I hope you like it!
  21. 4 points
    Here you can download my files from softbody week-5 : cloth-fem solid-fem hybrid.hiplc pizza.hiplc spider.hiplc spoon bubble-v2.hiplc springs-wiressolver.hiplc
  22. 4 points
    Thanks @Sierra62 I did a video showing the process, you can check here: Right now I'm making another setup, the idea is to randomly generate shapes and then have some parameters to tweak Cheers!
  23. 4 points
    I did a little python toolset to speed up my VEX writing. It replaces "code shortcuts" into "code snippets" and also updates the parm interface (default values, channel ranges from comments, ramps are generated from custom library). You can build your own libraries of snippets with specific channel ranges and defaults. I am really python newbie, so it is "alpha". The code is not prepared for exceptions, it is not exemplary, but I hope it would help somebody. It helps me already so I will debug it on the fly. The initial idea comes from here, Matt Estela: http://www.tokeru.com/cgwiki/index.php?title=HoudiniUserInterfaceTips#customise_right_click_menus qqReplace.py rampCollect.py updateInterfaceFromComments.py
  24. 3 points
    here's my take on things...look at the classic case in the top left corner, a piece that is a triangular shape, imagine if BBox logic was applied to get the 'center'...it would have been ON the hypotenuse (right angle triangle, basic trig)....WRONG !!! But with my simple CoM logic (I won't claim it's foolproof, I'm wondering how it works on an L shape)..it's on the inside of the tri itself... vu_CoM.hipnc
  25. 3 points
    hey, this are some shots I did with houdini the past months. I know its short and still not the quality I want to achieve but yea... Some of the shots e.g. the leather inflate is a not just a hobby shot rather a production shot I did most recently. Switching from 3ds Max to Houdini was the best decision I made.... kind regards Jon
  26. 3 points
    @sb526, did you try VDB Reshape SDF? I think the video used pretty close stuff on erode part. Convert to fog, add noise, convert to SDF, erode, convert to polygons. sdf_erode.hipnc
  27. 3 points
    I've recently started using Houdini coming from a Grasshopper/Rhinoceros + Architectural background and quickly I realized it's such a great tool for parametric & procedural design for modeling some geometrical shapes which sometimes GH is not good at. I'm planning to post tutorials for Houdini to following Facebook page and Youtube channel as my note how to make geometries I'm interested in. [Facebook Page] https://www.facebook.com/ParametricProceduralHoudini/ [Youtube Playlist (Fast ver.)] [Youtube Playlist (Slow ver.)]
  28. 3 points
    Couple of nice older topics on the subject:
  29. 3 points
    Here is it.:) nbody_opencl.hipnc
  30. 3 points
    avoid using fluid source. My advice for fast moving sources is using points, create attribute fuel, temperature, pscale and trail points to have v attribute. Then create a sop geo node in dops bellow your pyro object pointing to your points. put default operation to set always. then do particle to field nodes for fuel, temperature and vel (you should put attribute v and field name vel). oh... and in sops use a timeblend to have point interpolation. This way you have great results and super fast simulations without the need of caching your fluid source.
  31. 3 points
    depending on your mesh and accuracy there exist numerous different algorithms to compute discrete curvature, all with their pros and cons. i don't think there's a single one which works flawlessly in all situations and for all meshes. anyways, here's a file i've posted a while ago on discord with different implementations. it might be a bit confusing without the conversation we had in the chat but you can just try which algorithm works best for you. (from left to right: classical taubin tensor using integral formula, tensor using euler formula, approximated shape operator, proper shape operator in surface space, polynomial fitting) hth. petz curvature.hipnc
  32. 3 points
    Thanks a bunch for the detailed setup! Im genuinely curious, where does one start if they want to learn these things?
  33. 3 points
    Hello, since last week i can play with houdini again to keep going my tests ... and bellow , some of my latest hip files from this video: torus+wrinckles+.hiplc stick man rbd+ .hiplc bubbles- rbd+cloth-2.hiplc
  34. 3 points
    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
  35. 3 points
    some other files from "softbody- week3" video to understand how to mimic interaction between rbd/cloth , pyro/cloth, how to play with attributes and multisolver like @massdensity. same way for fluid/cloth interaction and other attributes used in the video. ++ cloth+pyro.hipnc blob+boxes-shellmassdensity.hipnc blob-shellmassdensity.hipnc
  36. 3 points
    to get a plasticity effect by replacing @baseP with @P when @potentialdensity is high enough. cloth+baseP+potentialdensity+multisolver.hiplc
  37. 3 points
    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.
  38. 2 points
    Low Poly MiG-23 DPRK Combat Plane I made using Houdini 16. I made the High Poly, Low Poly, and UVs using Houdini 16. I baked material ID and high to low normal map using the Games Baker ROP. Additional Normal details like the panel lines were in Substance Painter. It was exported from Houdini to Unity. Let me know what you think. Render is from Substance Painter. Currently there is no glass shader for Substance Painter, that is assigned in Unity. Thanks. Waiting on screen shots in Unity. Will post as soon as I get them. *Edit - Screenshots from Unity. I was required to block out the UI elements. You can see the glass shader applied with the pilot inside. *Edit - Low Poly Hydra 70mm Rocket (AH-64 Apache Ammunition) and M789 HEDP Round (AH-64 Apache Ammunition)
  39. 2 points
    i think the detail (cuts) on the "heights" (which is also found in the "valleys") is just simple voronoi lines (couldnt figure out a clean way in my scene so I eyeballed it) cube_v002.hipnc
  40. 2 points
    I just tried another approach building the transformation matrix itself, the transform contains the transformation values of the set of points B pc_match_001.hip
  41. 2 points
    There is a range functionality in the Group SOP, where you can refer to the X divisions of the grid.
  42. 2 points
    I've made a new tutorial showing how to create fractal based crystal using VEX and solver based on following idea. http://www.digital-grotesque.com/design_composition.html?screenSize=1&color=1
  43. 2 points
    https://vimeo.com/241036613#comment_16154324 Cristin Barghiel9 hours ago Glad to tell you that zooming and tumbling under the cursor, using ‘s’ as a sticky/volatile key for selection in the viewport and network editor, and many other much-requested features like them are indeed in H16.5. We simply couldn’t mention them all in our presentation.
  44. 2 points
    There is an example here that might help you configure your setup. http://forums.odforce.net/topic/25591-cloth-based-paper-confetti-setup/?do=findComment&comment=148781
  45. 2 points
    This is a personal project i've been working on in houdini . so hope u like it .
  46. 2 points
    check the mods I did in your first setup fastpyro_particletofield.hipnc
  47. 2 points
    I get the same results every now and again.. then I restart. Sometimes this fixes it, sometimes not so much. Right now I only get black color maps. Something broke between houdini 16.705, and h16.736 it seems. These effects are awesome when they work. I've got them in my game at the moment The button is a soft vertex anim, and the explosions are fluid. remember to keep color as point data if you want to export colormaps Good luck man!
  48. 2 points
    you might be surprised but it's actually quite straightforward ts_CopyToQuads.hip
  49. 2 points
    I just gotta share this for inspiration - I could watch this for hours...
  50. 2 points
    Just got Sergei-Tomas-Pavel example working in H14, if someone need this. dynamic_constraint.hipnc
×