malexander

There are also Mtlx Noise VOPs that you can use to generate random values, though you need to feed them a seed that varies per pixel (like a uv or position).

You can use MaterialX VOPs to generate the triplanar projection in your shader with the MTLX Triplanar VOP. GL and Karma at least recognize MaterialX shaders.

If you are using an Nvidia card and have a driver version that's >495, rollback to a driver version that's <495 and everything should work again. We've contacted Nvidia about it, and this should be fixed in an upcoming driver.

I'm guessing you probably have the Nvidia 496 driver installed. If you do, rollback to a version < 495 or no shader program that uses a geometry shader will compile (and Houdini uses them a lot - it'll be unusable with 496). We contacted Nvidia earlier last week about this and they're looking at it.

gplay doesn't accept wildcards in a filename. At a command line, "gplay *.bgeo" works because the shell is expanding *.bgeo to a list of valid filenames. You'll need to to the same.

If you're referring to "hview", it's just a script which starts the appropriate houdini app for a given file. "hview image.exr" will run mplay, "hview geo.bgeo" will run gplay, and "hview file.hip" will run houdini (likely the one you have a license for).

The hotkey is still Shift - and Shift =. You need to have at least one object selected for it to do anything, as it changes the objects' "Display As" parameter. It also does not do anything within a LOP-contained SOPnet, as there is no object parameter to change.

I believe that means that the bbox is invalid, likely because the extents weren't authored on the prim.

They're available online: https://www.sidefx.com/docs/

The code itself is likely limiting the number of threads adaptively so it doesn't completely tank performance. Most threaded code processes data in chunks. The chunk size might be quite small when divided by 32, so it reduces the number of threads to keep it larger. There's a non-trivial overhead for spawning and waiting on threads, and if you don't give a thread enough to do this starts dominating the cores as all you're doing is thread management. Plus there's usually some single-threaded code in between threaded code which can affect the %cpu reported, as it's averaged over the monitored interval.

If you're using HOM, grab the SceneViewer object from the desktop and iterate through the GeometryViewport's (SceneViewer.viewports()) and check the type() against hou.geometryViewportType.Top. When you find it, use changeType(hou.geometryViewportyType.Perspective) on that viewport object.

The RAT file format specifies that all color values stored in it are in linear space, so rendering to them will write the values as-is (no sRGB conversion). Rendering to a PNG, on the other hand, will convert the rendered linear color values to sRGB because it's a sRGB format. If you're writing a normal map to PNG, you do not want any colorspace conversion to take place on export or import - the value should be stored linearly (otherwise normal values are unevenly distributed across[-1,1]). So if you are reading the RAT into COPs, extracting the normals into a separate plane and writing them to PNG, disable the "Convert to Image Format's Colorspace" toggle in the Composite tab of the Composite ROP. This will write the linear values into the PNG as-is, without sRGB encoding.

useDefaultCamera and setCamera must be called on a GeometryViewport object. You have one in your script, 'viewport'. You can stash the default camera to a python object using: prev_view = viewport.defaultCamera().stash() // set your camera and flipbook viewport.setDefaultCamera(prev_view)

In your BIOS/EFI, look for a setting called "Core Performance Boost" and set it to Disabled. A lot of motherboards have this Enabled or set to Auto, which causes a lot of instability with some systems.

You could try GeometryViewport.draw(), but it's quite possible the redraw request won't be processed until the end of your script.