Category: hou-rendering

Archived post by andrewhazelden

**Houdini HQueue on macOS Sonoma Setup Tip**
The recent Houdini 20.0.724 release (houdini-20.0.724-macosx_arm64_clang14.0_13.dmg) has several issues that impact the ease of running HQueue on macOS Sonoma systems.
Step 1. The first problem is the Launch Daemon file (/Library/LaunchDaemons/com.sidefx.hqclient.plist) points at a missing Python v3.9 library, while HQueueClient’s Frameworks’ folder now ships with Python v3.10. This requires an edit of the plist file in two places to correct the file paths to point at Py 3.10:
“`/Library/HQueueClient/Frameworks/Python.framework/Versions/3.10/bin/python3“`
and
“`DYLD_LIBRARY_PATH /Library/HQueueClient/Frameworks/Python.framework/Versions/3.10“`
Step 2. The macOS Sonoma operating system now uses “AirDrop” on port 5000. This setting can be disabled by changing the “System Settings… -> General -> AirDrop & Handoff -> AirPlay Receiver” setting to OFF. This is relevant if you really want to keep HQueue running on the default port 5000 setting for Houdini cross-platform consistency.
The following macOS zsh terminal command checks for programs using an open network port (like port 5000): “`lsof -i :5000“`
You will likely see an lsof output similar to the text below when running on a default install of macOS Sonoma:
“`COMMAND   PID USER   FD   TYPE             DEVICE SIZE/OFF NODE NAME ControlCe 436  vfx   10u  IPv4 0xf…      0t0  TCP *:commplex-main (LISTEN) ControlCe 436  vfx   11u  IPv6 0x3…     0t0  TCP *:commplex-main (LISTEN)“`
In the Isof output, the text “ControlCe” indicates that the macOS AirDrop setting is active, which in turn means port 5000 is already in use. This is solved by disabling the AirPlay Receiver.

Attachments in this post:
http://fx-td.com/houdiniandchill/wp-content/uploads/discord/20241006/26/24/Airplay_receiver_uses_port_5000.png

Archived post by midgaard78

With regard to the color space talk, I happened to have closely investigated what H20 is doing just yesterday. The issue I was running into is that Karma’s output respects the Input File Rules set up in the OCIO editor (Edit > OCIO Settings…). So even if your working space is set to ACEScg, the rendered image will still be linear rec.709 unless you take some step to prevent it.
– You can put the string “ACEScg” in the render’s filename, and Karma will obey the file rule. – You can change the file rule for *.exr to ACEScg. If you’re already pre-processing your inputs, this is what you should do. This is the “correct” ACES workflow. – You can set the Output Colorspace parameter for each AOV that should be ACEScg. – Or you can use the OCIO filter in the render settings to apply a post conversion. I recommend against that one, though, as I do not believe the conversion is lossless, and it risks a double conversion.
The SDR 1.0 Video view transform from ACES 1.3 ought to be sufficiently visually similar to Output – Display – sRGB from ACES 1.2, but I haven’t verified that yet. The Un-tone-mapped view should be the same as Input – Texture – sRGB.
The ACES 1.2 config can be found here: github.com/colour-science/OpenColorIO-Configs/tree/master/aces_1.2

Archived post by mattiasmalmer

how do i get the cameras uv space in a materialx shader? i want to do projective texturing in the shader.

This works half-assedly but only on CPUkarma. I load the hit position in worldspace. transform it to cameraspace (using space:camera in the transformpoint) then divide that with hit distance to get a projection. (using ray:hitPz in the mtlxdot) but the camera:space thing does not work in XPU.
I thought this would be the easiest thing ever. anyone having any better tricks?

generating precooked uv data on the geo from the camera is not as good as one tends to get projection errors over larger polygons and such.

ok after the longest time mucking about I found how it is actually done:
You use the coordsys node in LOP:s to define the coordinate system and reference the camera. Then use that coordsys in a mtlxposition and use myCoordinateSysName:ndc to get it in the camera projection space. Neat because then you can use any camera as a projector and so forth.

aw frekk. does not work in xpu.

Attachments in this post:
http://fx-td.com/houdiniandchill/wp-content/uploads/discord/20232109/07/23/image.png