Jeff Lait
jlait
About Me
EXPERTISE
Developer
Connect
LOCATION
Not Specified
WEBSITE
Houdini Skills
Availability
Not Specified
My Badges
SideFX Staff
Since Jul 2005
My Tutorials
Recent Forum Posts
OpenCL and Varying Layer Jan. 30, 2026, 9:06 p.m.
@dst accepts only float4, but OpenCL will widen float -> float4 for you. It doesn't widen the others.
Varying Layer means the real type of the output will not have to be strictly float4.
The problem is we want to write a gamma kernel, but not have to write a float, float2, float3, and float4 versions of it. So we write only the float4 version, and let COPs throw away the extra data when we write to @dst. Likewise, when we read from the source layer we implicitly widen.
This does mean we are doing extra computation; but as the time seems to be dominated with the memory costs we bear with it...
If using #bind to set up the signature, the varying is created with the float? type. The size for outputs will then be determined by the first menu of the "Metadata" option on the signature page. By default this is "First Input", which means all the varying writeable layers will match your first input, which usually is a good guess.
You can alternatively set it to "Match Name" so the source of the same name will be used, if it exists, or specify a specific input to copy the size from.
Varying Layer means the real type of the output will not have to be strictly float4.
The problem is we want to write a gamma kernel, but not have to write a float, float2, float3, and float4 versions of it. So we write only the float4 version, and let COPs throw away the extra data when we write to @dst. Likewise, when we read from the source layer we implicitly widen.
This does mean we are doing extra computation; but as the time seems to be dominated with the memory costs we bear with it...
If using #bind to set up the signature, the varying is created with the float? type. The size for outputs will then be determined by the first menu of the "Metadata" option on the signature page. By default this is "First Input", which means all the varying writeable layers will match your first input, which usually is a good guess.
You can alternatively set it to "Match Name" so the source of the same name will be used, if it exists, or specify a specific input to copy the size from.
Stamppoint and alpha. Jan. 7, 2026, 1:58 p.m.
Checking the code, we aren't binding Alpha :< So the alpha attribute is not supported. I've submitted an RFE (152678)
How to read pixel value via hscript in parameter? Jan. 5, 2026, 12:42 p.m.
The attributes are probably most similar to "primitive" attributes, but Copernicus has one-wire-per-primitive so they also look like detail attributes.
They are for whatever extra non-image meta data you may need to attach. USD in particular uses them to store the output file name to ensure things are saved in the proper location.
The File COP will also fill out all the extra data from .exr here, so you can get stuff like cryptomatte manifests, etc, in it.
Having a wrangle to update them does seem like a good idea.
They are for whatever extra non-image meta data you may need to attach. USD in particular uses them to store the output file name to ensure things are saved in the proper location.
The File COP will also fill out all the extra data from .exr here, so you can get stuff like cryptomatte manifests, etc, in it.
Having a wrangle to update them does seem like a good idea.