Jump to content

shawn_kearney

Members
  • Content count

    146
  • Donations

    0.00 CAD 
  • Joined

  • Last visited

  • Days Won

    1

shawn_kearney last won the day on December 11 2016

shawn_kearney had the most liked content!

Community Reputation

35 Excellent

About shawn_kearney

  • Rank
    Initiate

Personal Information

  • Name
    Shawn

Recent Profile Visitors

1,004 profile views
  1. I thought I'd share my experience with this, being what a MAJOR pain it was for me. Maybe I can save someone else the trouble. So here's the issue. I have a Quadro M4000 that I want to use as display, and a Vega FE I want to use for compute (please, don't ask why I have an AMD card, I have my reasons and I've been pretty pretty happy with it). AMD Pro drivers allow you to install in "headless" mode, which will only install the OpenCL drivers. So this is pretty great. I can use my Quadro for display, and I can use my AMD for compute. Only. No. The DKMS module fails every single frickin' time, and you'll find online all these crazy, often version-specific patches and fixes. But the solution is actually pretty simple. Just install ROCm first, get that running, and then install the AMD Pro Driver with the --opencl=pal,legacy --headless flags. It will now install without any errors. I am not sure if the card is running under ROCm or not, or how all that works. However, ROCm alone is not fully compatible with Houdini, and returns an incorrect data type in the FLIP solver. Installing the AMD drivers after first installing ROCm does not have this same behaviour. I am not sure if it is safe to remove ROCm at this point. Since I have this up and running, I really don't want to mess with anything.
  2. Clarisse iFX ?

    I really liked using Clarisse, and I respectfully disagree with Atom's opinion. Clarisse can do a lot of really cool stuff in terms of pre-compositing and scene layout. It's a very fast and intuitive system when managing huge scenes with lots of assets and tons of passes. Working on a project that uses a large variety of assets I often feel like it'd be really nice if we had clarisse to manage it all. I've easily written enough python for c4d/arnold to pay for at least one or two clarisse licenses. That said, if you don't work with large, complex layouts then there probably isn't a lot of use for it, and Houdini is certainly capable of managing the scale that Clarisse does. Only that Clarisse is kind of purpose-built for this sort of task.
  3. I wanted to play around with PyOpenCL in SOPs so I had to change out the symbolic link from HFS OpenCL to OpenCL 2.1 (from the Intel SDK) to get it to work. Upon testing to make sure I didn't completely break Houdini, I noticed that OpenCL performance in Heightfields and FLIP seemed noticeably faster. Is this possible, or is it just my imagination? (cross posted on Facebook Houdini Artists)
  4. FLIP Energy transfer?

    wait. the what to WHAT? Oh this is going to get fun. I knew that there was something like this, just wasn't sure how to get to it! THANKS.
  5. FLIP Energy transfer?

    Another issue is that this would account for all force, not just collisions... Though this might not be a problem. And yeah, i would do it in a SOP solver. I want to take a stab at non-Newtonian fluids that change viscosity with force.
  6. FLIP Energy transfer?

    Ok. That was kind of my plan. I suppose I could use a POP Collision(?) DOP to isolate RBD- collided flip particles ... haven't used that node for a while....
  7. FLIP Energy transfer?

    Is there a way to calculate or obtain the degree of energy imposed onto FLIP particles resulting from collision as either a scalar or vector value?
  8. Houdini 17 Wishlist

    A simple framework to permit deformations on volumes, if not the facilities to sculpt directly onto SDF would be kind of cool. Does anything like this currently exist?? I know that there are volume paint tools.
  9. How to render Volume Z-depth for Htoa

    As far as I know you can't; not directly. You need to use deep rendering for this. If you're using arnold, then I am pretty certain that's the only way. It sounds a lot scarier than it is though.
  10. Is Voronoi pre-fracture obsolete?

    I've known about clustering, but it makes sense now how clustering can help here. I've always thought of clusters more thinking in terms of the dynamics and how the fracture plays out, I wasn't really thinking of it in terms of the overall shape of the pieces. You've given me a lot to think about.
  11. Is Voronoi pre-fracture obsolete?

    Awesome reply, @jonmoore
  12. Is Voronoi pre-fracture obsolete?

    First of all, I'm not doubting you at all. As popular as Voronoi is and as new as I am to Houdini I feel like I must be overlooking things. Even asking this makes me feel foolish. But one reason I'm wondering is because in Jeff Wolverton's Image-based Destruction tutorial he mentioned off-hand that there are better ways to do fracture, but did not discuss what those were (FEM seems like it'd be overkill). Perhaps it was some other approach to Voronoi (i.e. RBD Fracture), but it seemed like he didn't care for Voronoi in general. But I have used Voronoi some, and by comparison VDB Fracture SOP is generally faster both in set up and performance for complex interior noise, and much easier to control (though large numbers of small, detailed pieces are still problematic, though so is true of voronoi). Add a platonic, subdivide, copy onto point and displace points with mountain sop. I can control the exact shape, placement, size and interior noise of pieces with a high degree of visual feedback before cutting up fractures. Yes, from my limited experience I can get the same results when doing a basic fracture as explained above. Buteven for a basic random fracture VDB fracture just seems more responsive and direct. Like I said, probably I'm missing something. I'm just not sure what it would be. VDB fracture is a SOP that cuts SDFs into multiple primitives based on mesh input. You then use Convert VDB sop to import into DOP normally. It's not immediately obvious how it all works and there aren't many tutorials out there.
  13. Copy random fracture pieces over points via copy sop

    I figured my method would be inefficient since I had to copy all the geometry for each iteration. I'll be sure to take a look at your hip later.
  14. Copy random fracture pieces over points via copy sop

    Slight improvement to my version to account for part the centering of pieces, and got rid of some weirdness in VOP. Not sure if this is possible without a for-each (is it?). Mine works by attributing one random piece to a group called "sel" and using that group to define the source group on the copy SOP. The seed for the random selection is based on the point number of the template point. This point number though is lost inside the for-each since it only brings in one point at a time, so it must be written to the "id" point attribute piror. I then multiplied the random number generated (which is between 0-1) by the total number of packed primitives and converted it to an integer. Now I have a random integer that corresponds to a single packed primitive. I use this index number to assign the primitive to the group "sel" So for this iteration I have one randomly selected packed primitive belonging to the group "sel" which I can use as the source group. In practice I'd probably do it a little differently and instead delete all but the selected and transform to the point, orienting to normal if needed and skipping the copy sop entirely. randomselection.hiplc
  15. Copy random fracture pieces over points via copy sop

    I'm pretty new with houdini, so I am sure there is a better way. randomselection.hiplc
×