Jump to content


Popular Content

Showing most liked content on 08/16/2018 in all areas

  1. 1 point
    By far the processor does more work than the GPU for a typical user. Only a few things heavily use the GPU like the viewport and some simulations. I wouldn't bother upgrading to another quad core on the same platform. I also wouldn't bother upgrading only the GPU on the existing system.
  2. 1 point
    In all honesty I would hold off just a little longer and try your system with a new graphics card, I know people always say something new will always come out but after seeing the new Nvidia RTX graphics cards at Siggraph with *built in* hardware ray tracing, you might kick yourself in the butt for buying anything graphic card wise before they arrive, they will be a real game changer to rendering, Redshift has an even brighter future now imho, the pro versions of these card are available but still $2500 for the average user for a graphics card is probably a bit much, I am assuming you are an average user from your current setup. Judging by the past Nvidia will find a way to include a cut down RTX for home users, they would be foolish not too, which is why I say hold off just a little while....and since your current system is five years old a couple of months wont hurt to know you made the right choice. And just as I was typing this I hear that Nvidia have just been hinting at a more reasonably priced RTX ....the RTX 2080....typical eh
  3. 1 point
    Have you noticed that the viewport is sluggish with the scenes you're using? If not, you can limp along with the 960 for a while until you notice it becoming a bottleneck. If you're going amd, the threadripper 2950X looks like a great value. If that's a bit rich for you, a Ryzen will do just fine. I'd recommend 32GB for a new system.
  4. 1 point
    I dig it. looks cool! well done
  5. 1 point
    yep, you're right! the point expression syntax doesn't work the same way as VEX. generally speaking, in VEX when you're trying to grab data from something that's not directly connected to your given node, you need the op: syntax to signify that you want to fetch the underlying data. for example, the point() function's help shows that the first parameter is <geometry>, not a string. the op: syntax signifies that you're trying to cook that operator and return the geometry data. similarly, you use op: syntax to fetch pixel data from COPs when you want to use a COP as a texture input rather than a file on disk.