malexander

Volumes are rendered as many parallel planes blended together, so if the number of pixels in the viewport is large and it's a large volume (or several), you're probably maxing out the GPU's ROPs which do the framebuffer blending and writes. You can try adjusting the volume quality and/or size in the Geometry and Texture tabs of the display options.

Split your viewer into 2 viewports, don't use 2 viewers. Separate viewers do not share selections, viewports within the same viewer do.

Does what does iinfo report for the tiff file? It may be that Houdini doesn't recognize it.

Either icp or iconvert should work. eg. icp Mandril.pic Mandril.tiff I'm not sure why .pic wouldn't work, it's our native format.

Those are the project settings. Changes made to those affect only the current hip file, and are "live" (ie, changing the Res will cause all Generator COPs that aren't overriding the res to resize and recook to the new res). What you want is the compositing Resolution Limit in Edit > Prefs > Compositing, Cooking tab. If you've already set that, I'm not sure why you'd be getting the resolution limit warning. You may want to check hcomposite.pref in $HOME/houdiniX.Y and see if cache.maxresx and cache.maxresy are set correctly to the values you're using. Also, once you get this working, I highly recommend setting the proxy cooking resolution in the COPs view toolbar from "Full" to 25% or 12.5%.

If you tag a parameter with one of the recognized OGL tags, and the parameter's type is what is expected (ie, ogl_emission_map is IMAGE_FILE), then it should be recognized by the viewport. The tag names were taken from the names of the original OGL parameters, which still work as well.

Deform parameter: Shift by UV Gradient.

Try "Gradient" mode. It's a lot more forgiving.

Is the Principled shader's Effect Scale tagged with 'ogl_displacescale' (in Edit Parameter Interface). If it's not, it'd be using a displacement scale of 1.

You only need the tag if the parameter isn't a recognized GL parameter. The viewport looks for ogl_tex1 - if it finds it as a parm, it uses that. If not, it looks for a parameter with the ogl_tex1 tag on it. This is so users can generate their own parameters (diffuseMap) without having to tediously channel reference them to a ogl_tex1 parm.

That's the correct way to do it if you want true parallelism. You can't render multiple GL ROPs within the same session simultaneously. You could use ROP dependencies to render frame 1 of GLrop A, frame 1 of GLrop B, frame 2 of A, frame 2 of B, etc, however this just interleaves the rendering in the same session. It doesn't render the frames at the same time.

If your laptop has Nahimic audio installed, try shutting it down before launching Houdini. It tries to install some 3D positional audio nonsense to OpenGL and that ends up destabilizing Houdini.

You can turn the Origin Axes off and then select Save as Default (highly recommend doing this in a fresh Houdini session) This setting can be saved to the hip file, but can't be saved as a preference. I don't think you can change the default setting for Export Relative. It's on by default for HDAs - absolute paths are a pain if you go to convert a network to an HDA.

You can press PageUp in the viewport to go to the first SOP (box1) and then Shift+PageDown to select the next sibling to the right (or Shift+PageUp for the left). If you have handles displayed, it'll show the handles for each one as you move. Is this what you're looking for?

It's also good to note that any high-core count processor (usually above 10) has memory bandwidth issues because of Non-uniform Memory Access (NUMA). The AMD 2990X is a bit of an extreme case of that, to be sure. But pretty much all CPUs with many cores will partition the cores into clusters with their own memory controller attached to their own bank of RAM. If a core requests bit of memory that's in the RAM bank attached to their core cluster's memory controller, all is good. If the memory is in another bank, it has to hop to another cluster's memory controller, adding a bit of latency to the request. Because of this, both Intel and AMD have redesigned their core interconnects to work around this, so at least there's no more than 1 hop involved. Another interesting thing about high-core CPUs is that the "uncore" parts of the CPU now actually use more power than a CPU core, and these are not easily shut down like cores are when power savings is activated. This includes stuff like the interconnect and the memory controllers. So the idle power of these monster CPUs is quite high. Just something to bear in mind.