Welcome to od|forum

Register now to gain access to all of our features. Once registered and logged in, you will be able to contribute to this site by submitting your own content or replying to existing content. You'll be able to customize your profile, receive reputation points as a reward for submitting content, while also communicating with other members via your own private inbox, plus much more! This message will be removed once you have signed in.


  • Content count

  • Joined

  • Last visited

  • Days Won


Community Reputation

286 Excellent

1 Follower

About malexander

  • Rank
    Houdini Master
  • Birthday 03/06/1974

Contact Methods

  • Website URL sidefx.com

Personal Information

  • Name Mark Alexander
  1. What marty says is good advice - if the driver you have is working for you, and you don't have any particular need to upgrade it, leave it be. OpenGL has effectively tapped out at GL4.5, and the only things added are vendor-specific extensions which we rarely use. Lately Nvidia has had some bad driver releases, especially on the consumer side as they alter the driver support the current AAA game of the month.
  2. It's due to the compositing of the color-managed beauty pass (in which the volume is drawn) and the unmanaged pass (where the grid is drawn). Any user geometry will appear correctly blended, it's just the grid that doesn't play nice. Out of all the solutions we had on hand we figured this one was the most acceptable in terms of speed/quality balance.
  3. It depends on whether it's a bug in our Exporter or their Importer. I'd submit it to both.
  4. Have you submitted a sample alembic to SideFX as a bug?
  5. That is due to how the grid and beauty pass are composited together. The faint edges of the volume are closer to the camera and block out the grid. They can't be drawn together because the volume is color managed and the grid is not.
  6. It's sort of possible. You can write a HDK scene hook which completely takes over the beauty pass, then renders the scene 5x with 5 different projections to a cubemap. Then you'd take that cubemap as a texture input to a GLSL shader which does the fisheye lookup and writes it to the beauty pass framebuffer. I say "sort of" because the rendered image will be out of sync with everything else in the viewport, such as picking, handles, construction plane, etc. so in my mind it's not really a valid solution (more of a hack). This is probably something that'd be better in the OpenGL ROP or the Flipbook, which is less concerned about those other things.
  7. You could be running out of file descriptors ("Too many open files"). On Linux, you can run 'limit' (or ulimit) to see how many files can be open at once. On my system, it's 1024 by default. Which OS are you running?
  8. There's also Ce (emission color), Ca (ambient color), and Cs (specular color). Only Cd is supported by the viewport, though. For the principled shader, Cd is considered the base color (PBR rules).
  9. The menu item does work for me - What desktop are you using, or is it a custom desk?
  10. The easiest way to do this is to click on the arrows in the middle of the split bar:
  11. No, you pretty much can't do this at the moment. Large angle FOV projections will severely mangle geometry with large triangles, so it'd have to render to a cubemap, then sample from there into a regular 2D image using a lens shader. I don't think that you could accomplish this with the HDK right now. You could render a cubemap with the GL ROP in 16.0 and post-process that, though.
  12. If they ran the test with the CPU-CL driver, I'd expect the 1800X to slightly edge out the 1700X. But even then, it'd be "roughly the same" in that you as a user wouldn't notice the difference unless you were sitting there with a stopwatch
  13. When you're simming or rendering, you'll notice those extra two cores. If you do that a lot, 400eu will pay for itself in a short fraction of the CPU's lifetime.
  14. On a 32" 4K you could also try Large UI Size, if you find High DPI is too large.
  15. Yep, you could run a bunch of them in 16x mode, and have some lanes leftover to access a couple of PCI-Ex-based SSDs for large datasets. This is particularly important as AMD GPUs now have virtual addressing which could target the data on SSDs directly (though I'm unsure if that's currently supported for external SSDs, or just the TB one built in to the new Radeon Pro SSG cards). Usually there's a few lanes taken up by ethernet, the chipset, and slow storage as well, so 40 can go really quick.