Jump to content


Popular Content

Showing most liked content on 03/31/2016 in all areas

  1. 6 points
    I just wanted to share my short film exploring cubes in Houdini. Please enjoy in Full HD and fullscreen. Br, Hamp
  2. 2 points
    Hello friends, here is the second part.
  3. 2 points
    Ah, nice clean technique Yader, thanks! (obscenely large gif, sorry) curve_grow_pops_3d_col_v02.hipnc
  4. 2 points
    curvature computation on grid data like volumes is fairly easy. just compute the hessian and extract the curvature information you need. hth. petz vol_curv.hipnc
  5. 1 point
    Keep the size under 256x256 (stumbled across that by accident)
  6. 1 point
    Nice work, I think you threw in about every major effect.
  7. 1 point
    But can you really get as good a behaviour using that as you can with the Realflow forces? And I'm not a Realflow user myself, just played around with the basics a couple of years back, but I worked with Realflow artists and I've just got the impression the RF forces are way easier to setup and get looking good compared to using the POP forces in Houdini. Same with the morphing tools, etc... Or maybe it's just me not having dug deep enough into this.
  8. 1 point
    A nice evolution of the concept. There is a little bit of additional setup to prepare a shape other than the torus. Initially when I used the font the line did not "cling" to the shape. But after centering it on the world origin and adding more faces with the Divide node, in bricker mode, the line eventually took hold. Because the resulting line is open we can measure the length and use that to drive the polywire radius, here the line is thinner at the start compared to the end. 1.0-$PT/($NPT-1)/100 And, of course, random sized Wire Radius. rand($PT)/50
  9. 1 point
    Thanks Matt, I'm really humbled! Your wiki has really helped me in my houdini exploration - more than you can imagine. So let me take this opportunity to say thanks!
  10. 1 point
    Couldn't help myself, I dug into this a bit more tonight. Volumes were definitely the next step, and I've got them kinda working in my setup (this is my first bash at volumes). The thing I haven't cracked is that they loose the shape I love so much in the surface versions. I need to work on a way to get the surface tendrils to prefer to stick to the surface if possible. I have a few ideas, but nothing that I managed to hook up tonight. Right now the volume versions are quite cool, but look too random to me. The volume version has another force called contain_force. It needs to be high-ish to do anything useful. I also added a second set of points in the surface version that act as another repelling force. It looks really cool. The line tends to wrap around them creating a circular entrance point. This is the exclusion force. Should be easy to hook up for the volumes, but I haven't done it yet. Anyway, i'll render an animated version soon. If the settings are all sensible, the wires tend to be pretty stable now. 16_03_30_grow_line_SOLVER_01.hip
  11. 1 point
    There is no general solution which covers wrapping of "any mesh" to "any other mesh" without some guides. Guides could be let say UV or any other attribute which exists on both geometries. Those could be used for matching which parts from both topology correspond to each other. Without guides, it is possible but with lot of limitations from case to case. In your example, sphere wrapping against torus, there should be a definition what to do with topmost and bottom-most points from sphere? It is obvious that those can not be parts of torus surface if you want resulting topology has sense. So I suppose those have to "stick" to an imaginary plane(s) parallel with XZ plane. Anyway, Houdini have a tools for matching different topology (with or without guides). Used algorithm for your example is: 1. Define some search radius which will be used as search distance for each point on sphere 2. For each point on sphere find as much as 500 points on torus which are in that radius distance and average all those point positions. Take also normals from those points from torus and average their directions too. 3. Move each point from sphere to averaged position and assign averaged normal. That will generate geometry similar to extremely smoothed torus but some points will be inside it some outside. 4. Peak all points enough so each point is outside torus 5. Do ray cast in opposite direction of stored smoothed normal and mark points which failed to intersect geometry by ray casts Here is modified scene: http://wikisend.com/download/670898/iterativeShrinkWrap_2.hipnc
  12. 1 point
    ^ my thinking exactly, though using a POP network for the forces and a SOP solver in pops for creating the line, resampling, and piping the points back out into POPs. Doing it manually in a solver with PC lookup makes it even more controllable, sounds like an awesome setup and will absolutely dissect this one! Much appreciated! Oh, and please don't casually use terms like slerp like that, someone's gonna get an aneurism.
  13. 1 point
    There is a core of the Voronoi Fracture node called Voronoi Split. A very simple node expecting geometry and fracture points connected as polylines. It slices geometry right at the middle of them. That is why different scales not work. We can slice each bubble and move neighboring points closer or further to move middles right at the place of two spheres intersection. Another quick idea is to find two nearest points of a point wrangle's second input's pointcloud and set point positions (or pixel values at rendertime or even volume density) when two distances are close to intersection point. bubbles.hipnc UP: there is better version below.
  14. 1 point
    Ok, ill bite here. Ive been wanting to understand these effects for awhile, so maybe this will spark some experimentation. Heres my initial idea for making it work. I'll spend a bit more time documenting the process tommorow, but heres the basic steps. Its all done in a solver node: 1 - resample a line, adding a point each frame (alterable with an attribute) 2 - avoid_force - use a point cloud to sample all the nearby points and create a vector that pushes them away from each other 3 - edge_force - measure each line segment and create a force which attempts to extend the line to a maximum distance. (this was difficult as if you have a totally straight line you never get any interesting motion. My crap solution was to turn the direction vectors into quaternions and slerp between them) 4 - add up the edge force and the avoid force and move the points a little bit along that vector. 5 - use a ray sop to make the points stick to a surface. As long as the movement is not too great, this isn't too bad. I've ran out of time to tweak this tonight, hopefully i'll get back to it soon. This version barely works! Id love to see other peoples ideas for how to create this. sopsolver_growth.hip
  15. 1 point
    Also, 2GB is the minimum if you're not running multiple monitors or very high-res monitors. Two QHD (2560x1440) or a 4K (UHD) monitor requires more VRAM (4GB or above is safe) simply due to the large framebuffer requirements for those setups - they eat VRAM for breakfast. If you run multiple Houdini sessions that the same time, you also might feel a bit constrained by 2GB.
  16. 1 point
    I see your two specs are for xeons. Their extra on-board cache is nice but I'd look at substituting with 3rd gen i7's with 6 cores on board. I bet that with the cost of the xeon, you could probably get a dual core i7 for a total of 12 procs. Certainly helps Mantra sweep through a frame. Either that or go for an additional SSD for the os install and local cache along with a 2TB 7200rpm drive for files. I'd stay away from liquid cooling in search of a silent system which is only one of two reasons to install it: you want less fan noise or you are an over-clocker. Over-clocking a machine that will be doing hard rendering and simulation for long period of times, well, will generate huge heat and even with adequate cooling, the thermal stress and today's flimsy components will see your machine rendered dead in no time. Play it safe on production machines. As far as the GeForce GTX680, great card for Houdini at this time. Good balance between on-board memory and enough GPU cores to make running the odd OpenCL fluid sim workable. Instancing geometry in the viewport on the GPU will become ever more important moving forward. If you get a job that requires tons of dust and will pay the bills, just add a Tesla to get a very large amount of gpu memory and procs to process much larger OpenCL fluid sims. Again let the job pay for the Tesla. No other way to warrant this unless you are independently wealthy and don't need to justify it. As far as Houdini goes, it's an environment variable that you set to point Houdini to use the Tesla instead of the GeForce. Nvidia has their Maximus technology that bridges a Quadro with a Tesla. Great if you are in to medical visualization and can take advantage of this specialized arrangement. More intended for companies like Siemens and Philips who are in to medical imaging equipment. Houdini doesn't take advantage of Maximus at this time.