Jump to content


Popular Content

Showing most liked content on 08/19/2017 in all areas

  1. 1 point
    In this tutorial we will go over how to set up optimized pyro clustering with oriented DOP containers in Houdini given a piece of geometry moving through a scene. This process will lower simulation time and be more efficient when saving to disk because there are fewer voxels. Link to Tutorial -> https://gum.co/TqUNR We first go over how to get things set up quick and easy and in the second half of the tutorial we make further optimizations using VEX. We'll look at how to rewrite cluster points to do exactly what we need it to, which includes rewriting the resample sop using VEX. An intermediate tutorial for those looking to speed up their pyro workflow and learn some VEX. Includes the scene file! Hope to see everyone leveraging these optimizations in the future and squeezing in those extra few iterations before deadline! You can reach me at trzankofx@gmail.com for questions or comments.
  2. 1 point
    Thought this research by Nvidia quite interesting https://blogs.nvidia.com/blog/2017/05/10/ai-for-ray-tracing/
  3. 1 point
    I had EVGA 980 TI's (SC ACX 2.0) before upgrading to the 1080 Ti's but kept one for GL duties. If my renders don't require a lot of VRAM or when running smaller OpenCL simulations I add the 980 Ti' to the mix. The Founders Edition blower style of the 1080 Ti's are significantly quieter than the EVGA 980 Ti's (I'm very much an EVGA loyalist so a move to a vanilla nVidia design was a new route for me). I made the decision to go with a blower style design based on the advice of a few users on the Redshift forum that run GPU farms. I wouldn't automatically judge all blower style cards with your AMD experience. At the end of the day, going with most 1080 Ti designs are a good value/performce choice, just avoid the hyper overclocked designs. They're more trouble than they're worth and the price premium isn't worth it (IMO).
  4. 1 point
    evga 1080ti works well and is quite, running at around 1.5Ghz IIRC. I too had a blower style AMD card once and was rubbishly noisy and eventually roasted itself on openCL calcs. The evga cards are super quiet. If heat is an issue just open the case as it radiates into the comp instead of out the back. no big deal.
  5. 1 point
    Hey dunken, here it is: - I added nodes under yours in the vop - i made a similiar setup using vdb (on the right). It's often the best way to deal with volume (faster and lighter) boby vol_disp.hipnc
  6. 1 point
    Use pcfind and a foreach? So something like: //Set color to black @Cd = 0; // Pc find float radius = ch("radius"); int maxpoints = ch("max_points"); int pointcloud[] = pcfind(1, "P", @P, radius, maxpoints); foreach( int point ; pointcloud){ @Cd = {0,1,0} ; } I think that's what you were looking for... pcfind_example.hiplc
  7. 1 point
  8. 1 point
    I'm a Redshift user with 1080Ti's and would recommend Founders Edition models as they exhaust hot air out of the back of the case. You'll be able to run up to 4x 1080 Ti's in a case without extra cooling (PCIe lane, motherboard and power supply allowing). As much as Redshift allows up to 8 GPU's in a single node, the cost of building a system capable of hosting 8 GPU's rises significantly. There are faster 1080 Ti models available with greater overclock capabilities but those gamer centric cards are not necessarily the best for GPU rendering. You should also consider something like a 1070 (or even an AMD workstation card - great performance for OpenC sims is a bonus here) to drive your GL viewport, otherwise you'll be losing a significant chunk of VRAM to system resources. With the way that GPU rendering works, if a single card has 3 GB allocated to system resources, all cards are limited to using the same amount of memory as the smallest available VRAM. Alternatively if you believe that most of your output requires no more than 7/8GB VRAM, stacking your system with 1080 Ti's alone is the best performance/price option. A final consideration is operating system. If you take a look on the Redshift forums at the benchmark table, you'll see that Linux basewd builds using the same hardware have a significant performance boost and utilise far more of the available VRAM. But don't take my word for it. Ask for advice over on the Redshift, Chaos Group and Octane forums.
  9. 1 point
    here's a workaround (not convinced with this method tho)...btw, in your Boolean, the cutters should be treated as surface IMO, not solid VDB_boolean_workaround.hipnc
  10. 1 point
    it's same problem as this: basically, the Prim Normals aren't consistent and that confuses Boolean...haven't found a solution to your setup yet but I'm quite sure the Prim Normals have to be 'unified' first...(if you put Reverse after your convertVDB and quickly flip flop it, you'd see there's some potential clues around the ears)
  11. 1 point
    Glad it helped Anthony, that shot is looking so badass!! May I ask what project this is for? Oh, and is this a Mantra render or? As for the added 102.377, it's a random number that's added to make sure the rand function seed is a float value instead of an integer, and also to spread the seed numbers out. The help for the "rand" function states that non-integer numbers work best for the argument, but @ptnum will return integer values. I may be misinterpreting this though, so hopefully a Vex guru will set me straight here if I'm way off base! Another thing I've found useful when up-rezzing grains is to use the point velocities vector length to spread the replicated points further away from the source grain point, helps avoid the blobby look with free-flying grains. Let me know if you're interested in this technique and I'll whip out a quick example. --Dave
  12. 1 point
    Hi Dave yeah it scared the crap out of me.. sounded like the turbo under the car at one point haha! Right I'll give that a go.. yeah I did find that when I took the values down in my initial vex lines to something like 0.00000004 for example then it seemed to be less strain on the pc. The original number still resulted in enormous sprites lol! What you explained there about the changing grain count makes good sense. I think my grain count stays the same because I generated it from a simple shape on the ground initially. So once i have my initial base grains sim.. i yank that into a new geom node and I had to use a few blast nodes to clean up a few weird particles. After that I then apply my upres. So I can try that vex script you mentioned Thanks Dave I'll pop a little playblast up later Ant
  13. 1 point
    Ant, I see what you mean, I think your OGL driver is getting blown away by the quantity and large scale of the sprites. Try adding something like this to the setseed_adjust_pscale wrangle: @pscale *= fit(rand(@ptnum+102.377),0,1,0.5,1); This will modify the existing @pscale values, multiplying them against random values ranging from 0.5-1 This won't work if you have a changing grain count though, as the @ptnum values will be varying per frame. We also can't just inherit @id and use that, as each set of duplicated points will inherit their parent's ID and will get the same random seed value. --Dave