Jump to content


Popular Content

Showing most liked content on 10/13/2017 in all areas

  1. 2 points
  2. 1 point
    Few tips and tricks to manipulate gas simulation. 1. Independent resolution grid. E.g. Overriding vel grid size independent to a density grid. 2. Creating additional utilities. E.g. gradient, speed, vorticity and etc which can be used to manipulate forces. 3. Forces via VEX and some example snippets. smokesolver_v1.hipnc P.S. Some of this technique are not Open CL friendly though.
  3. 1 point
    Assemble creates Packed Fragment primitives, while Pack just creates Packed Primitives. A Packed Fragment refers to a portion of an underlying shared geometry. In this case, all the packed fragments will refer to the same geometry, just different parts of it. The viewport can then draw this as a single mesh. But when you pack to Packed Primitives, the parts of the geometry you are packing from are extracted into new geometry for each packed prim. When the viewport goes to draw this it sees 7000 separate meshes. This takes much longer to draw as the overhead of sending 7000 batches is a long higher than sending a single batch. It's this overhead that slows things down a lot.
  4. 1 point
    Hello, by raising your sphere division, your sim is more accurate but i takes more time to compute... and sometimes, the result is still not perfect ... and it seems you are in this case. if i were you, i would keep your sim as it is , and after that, i would make some adjustements with sop point nodes to reduce overlapping. bellow 2 variations of the same method. have fun with your muffin ! ++ testme-sop adjustements-ok++.hipnc
  5. 1 point
    Yes, see Geometry Data parameter type and a new Stash SOP
  6. 1 point
    No, nothing you can do about it. OS constantly sends all sorts of events to Houdini application, and since the latter waits while you editing code, Windows assumes that your application experiencing problems
  7. 1 point
    Hey Atom. I would usually do something like this in maya, but I did have a crack at doing it in Houdini. It uses curves to define the shape instead of a boolean. You still get ngons and tris around the borders of the shape, but theres not of that weirdness in the center. Its a bit janky (only had about 10 minutes to do it), but with a bit of love (and maybe some VEX) I'm sure it can be cleaned up into something workable even_quads_v1.hipnc
  8. 1 point
    The problem seems to be that you are not keeping both sides equal. When you convertvdb for one side, make sure you match the settings on the other (i.e. Convert Fog to SDF). Also, turn off that vdbresample unless you plan on resampling the other side too. It worked fine for me after that, no more exploding velocity.
  9. 1 point
    Yes,. well Potentially as a FX artist who mainly makes tools / codes / programs etc. which is always needed, But I would say you have less chance of becoming an actual fx artist if you ONLY have previous experience within Houdini coding and no actual 'FX' or simulation knowledge, - If I were you with what you've said I would learn code as much as you can (Vex/Python/C++ may even be useful to add to your CV) - And then do whatever simulation practice you can to show FX or concentrate on making optimized/streamlined Houdini tools which really aid the FX or any other process's. (Essentially in my eye if you want to go to work as a FX artist or TD and produce simulations/renders (explosions/fire/magic etc.) as well as some technical stuff (coding etc.) you need some simulations in your reel to a good level. Otherwise with coding alone I think you may struggle to get more artistic jobs and live in the world of programming/coding (Pipeline TD's/Coders etc) which is if that's your aim no problem! BUT if not make sure to try and produce whatever simulations you can using what you have. (PS; ive been told by senior artists and recruiters often rendering isn't always necessary especially if the simulation itself is very good or accurate and presented well (something to consider when you have a lower end pc spec etc. not rendering can save a lot of time) Hope this helps just my opinion on the matter
  10. 1 point
    Subjective question, at least this how I started: 1. Shelf tools, learn the basics and concepts. 2. Dive into DOPs OTLs/HDAs and look around to see how they are implemented. My examples are just a product of what those Side Effects guys implemented. 3. Read Houdini's documentation. 4. Be inspired by all the test that posted on Vimeo/YouTube that doesn't look like off the shelf imagery.
  11. 1 point
    Categories were introduced, so feel free to give us feedback on the split of channels. Some things are a trial to see if it takes off.
  12. 1 point
    An example of grid clustering. cluster_v01_01.hipnc
  13. 1 point
    Now it's working, thx a lot Matt. scene file + stick notes is attached: Grains Constraint v1.a.rar
  14. 1 point
    toggles = [p for p in node.parms() if p.parmTemplate().type() == hou.parmTemplateType.Toggle] toggles = [p for p in node.parms() if isinstance(p.parmTemplate(), hou.ToggleParmTemplate)] Not sure which is better.
  15. 1 point
    Because houdini uses a little bit different version of rpyc, in order to use hrpyc you need to add to sys.path (or PYTHONPATH) the following folders: (On windows) $HFS/python27/lib/site-packages and $HFS/houdini/python2.7libs
  16. 1 point
    Hi everyone this is my first topic in this community! I am a maya TD and I have been developing and rigging a lot in that software , then one day a collegue showed me houdini and I had a big "woah" moment , it s amazing how you can move and manipulate data in houdini , that s why i decided to learn it. I wanted to start with something I thought basic . Basically i would like to make a node (digital asset) that calculates normal along a curve by using the parallel frame transportation. The best would be to have as input the curve then and as output the computed normals. The algorithm is pretty simple and this is the c++ procedure i used in my maya nodes : MVector currentNormal = firstUpVecV; for ( int i = 0 ; i < numberOfSamplesV ; i++ ) { double param = curveFn.findParamFromLength(i*subvidsSample); MVector tan = curveFn.tangent(param , MSpace::kObject); MPoint outPos; curveFn.getPointAtParam(param , outPos , MSpace::kObject); tan.normalize(); MVector cross1 = currentNormal^tan; cross1.normalize() ; MVector cross2 = tan^cross1; cross2.normalize(); currentNormal = cross2 ; normals[i] = cross2; } [/CODE] Basically you start from a given normal and you use it to compute the next normal , then you keep in memory the normal computed and you use it for computing the next normal. I think that might be easier with python but I really want to get it done with nodes. What i have done so far (check the attached file please ) I start with a curve and i resample it (the number of samples is the number of normals I want to compute) then I use a polyFrame to compute the tangents and then i go inside a vopSop : then inside the vopsop i plug the firstUpVector (the starting normal) and the tangents in a for loop in the end inside an if loop i start with the cross products , my problem is that if the index is 0 i use the firstUpVector as a normal then when i have recomputed the normal with a double cross product i want to keep that normal somwhere and use it for next computation . something like nromals[i - 1] ^ tangents[i] anyone have idea about to get throught that if statement? I am stuck thanks a lot guys! testNormal.hipnc