Found 11 posts.
Search results Show results as topic list.
Technical Discussion » ACES and MaterialX. Missing colorspace transforms
- mkschmitty
- 11 posts
- Offline
Good to know. I was worried about hardcoding the colorspace of the autogen .rat files. Thanks again for your help. Progress!
Technical Discussion » ACES and MaterialX. Missing colorspace transforms
- mkschmitty
- 11 posts
- Offline
I think I figured it out. I noticed Houdini creates a .rat file from the .exr automatically.
So I added this line to the ACES config file
- !<Rule> {name: rat, extension: "rat", pattern: "*", colorspace: ACEScg}
To tell Karma that .rat files are also ACEScg
Now Karma CPU and XPU give me the same results when switching between "Color" and "Vector 3"
I think without this line, Karma XPU was interpreting the .rat file as Linear Rec 709.
(Though, Karma CPU isn't -- does this mean Karma XPU requires the auto generatied .rat file and Karma CPU doesn't?)
So I added this line to the ACES config file
- !<Rule> {name: rat, extension: "rat", pattern: "*", colorspace: ACEScg}
To tell Karma that .rat files are also ACEScg
Now Karma CPU and XPU give me the same results when switching between "Color" and "Vector 3"
I think without this line, Karma XPU was interpreting the .rat file as Linear Rec 709.
(Though, Karma CPU isn't -- does this mean Karma XPU requires the auto generatied .rat file and Karma CPU doesn't?)
Technical Discussion » ACES and MaterialX. Missing colorspace transforms
- mkschmitty
- 11 posts
- Offline
Technical Discussion » ACES and MaterialX. Missing colorspace transforms
- mkschmitty
- 11 posts
- Offline
Thank you for checking and confirming it works.
I looked back at the houdini scene I was testing yesterday and made sure it was reading the correct config file. (opened a new shell, opened a new houdini etc.) -- and it still didn't work.
Then tried copying the nodes from the non-working Houdini scene to a fresh Houdini, and it's still doesn't work.
I then built a fresh houdini scene from scratch, using the exact EXR texture and it WORKS! -- switching between "Color" and "Vector 3" gives me the same results.
This led me to wonder why the scene from yesterday wasn't working, it's basically the same Karma rendering setup.
I then noticed... that I was using Karma CPU in the viewport for the scene that works, and Karma XPU for the scene that doesn't work.
Could you confirm this on your end? Using both Karma CPU and Karma XPU, switch between "Color" and "Vector 3" and see what you get.
Thanks!
I looked back at the houdini scene I was testing yesterday and made sure it was reading the correct config file. (opened a new shell, opened a new houdini etc.) -- and it still didn't work.
Then tried copying the nodes from the non-working Houdini scene to a fresh Houdini, and it's still doesn't work.
I then built a fresh houdini scene from scratch, using the exact EXR texture and it WORKS! -- switching between "Color" and "Vector 3" gives me the same results.
This led me to wonder why the scene from yesterday wasn't working, it's basically the same Karma rendering setup.
I then noticed... that I was using Karma CPU in the viewport for the scene that works, and Karma XPU for the scene that doesn't work.
Could you confirm this on your end? Using both Karma CPU and Karma XPU, switch between "Color" and "Vector 3" and see what you get.
Thanks!
Technical Discussion » ACES and MaterialX. Missing colorspace transforms
- mkschmitty
- 11 posts
- Offline
I tried this and it doesn't appear to make a difference.
As per your suggestion, here's the new rule list in our config:
file_rules:
- !<Rule> {name: OpenEXR, extension: "exr", pattern: "*", colorspace: ACEScg}
- !<Rule> {name: Default, colorspace: ACEScg}
When the my scene is reloaded (after restarting Houdini), the EXR texture appears different when I switch between Signature = Color, vs. Signature = Vector 3. I would expect them to be the same. (The texture looks correct when I switch to Signature = Vector 3)
Also, changing the Default rule colorspace to ACES2065-1 or "default" makes not difference.
As per your suggestion, here's the new rule list in our config:
file_rules:
- !<Rule> {name: OpenEXR, extension: "exr", pattern: "*", colorspace: ACEScg}
- !<Rule> {name: Default, colorspace: ACEScg}
When the my scene is reloaded (after restarting Houdini), the EXR texture appears different when I switch between Signature = Color, vs. Signature = Vector 3. I would expect them to be the same. (The texture looks correct when I switch to Signature = Vector 3)
Also, changing the Default rule colorspace to ACES2065-1 or "default" makes not difference.
Technical Discussion » ACES and MaterialX. Missing colorspace transforms
- mkschmitty
- 11 posts
- Offline
Thank you so much for the reply. Now this is making sense.
I didn't realize the mtlximage node automatically converts the colorspace of the input image to scene-linear -- in this case "ACEScg" since this is the OCIO "Render Working Space" in Houdini as determined by the ACES config file. And, if Signature is set to Color, and that the "File Color Space" field has no effect on the colorspace transformation. Good to know.
And it appears the colorspace transformation is triggered by the file type? This is the behavior I observe:
- .hdr or .exr is assumed to be Linear Rec.709 and therefore a color transformation from Linear Rec 709 -> ACEScg occurs.
- *A gotcha - if the .exr or .hdr is encoded in ACEScg colorspace, it's important to set Signature to Vector 3 so no color transformation occurs.
- .jpg or .png is assumed to be sRGB - Texture, so is color transformed to scene-linear (ACEScg).
Is there any internal code we could tweak to set a rule such that if "ACEScg" is in the filename, it sets "Signature" to Vector 3 automatically? This would reduce user error.
Thank you for your feedback. We appreciate the clarification.
I didn't realize the mtlximage node automatically converts the colorspace of the input image to scene-linear -- in this case "ACEScg" since this is the OCIO "Render Working Space" in Houdini as determined by the ACES config file. And, if Signature is set to Color, and that the "File Color Space" field has no effect on the colorspace transformation. Good to know.
And it appears the colorspace transformation is triggered by the file type? This is the behavior I observe:
- .hdr or .exr is assumed to be Linear Rec.709 and therefore a color transformation from Linear Rec 709 -> ACEScg occurs.
- *A gotcha - if the .exr or .hdr is encoded in ACEScg colorspace, it's important to set Signature to Vector 3 so no color transformation occurs.
- .jpg or .png is assumed to be sRGB - Texture, so is color transformed to scene-linear (ACEScg).
Is there any internal code we could tweak to set a rule such that if "ACEScg" is in the filename, it sets "Signature" to Vector 3 automatically? This would reduce user error.
Thank you for your feedback. We appreciate the clarification.
Technical Discussion » ACES and MaterialX. Missing colorspace transforms
- mkschmitty
- 11 posts
- Offline
Hello,
We are starting a new project with H20 and this ACES configuration: cg-config-v2.0.0_aces-v1.3_ocio-v2.2.ocio
Downloaded from here: https://github.com/AcademySoftwareFoundation/OpenColorIO-Config-ACES/releases/tag/v1.0.0 [github.com]
Building a simple MaterialX shader in /stage context materiallibrary reveals there are quite a few missing ACES colorspace transforms missing to convert a mtlximage from sRGB to ACES, or Lin Rec709 to ACEScg. All of the existing items in the MaterialX/Colortransform menu convert to Lin Rec709. We would expect nodes to convert to ACEScg as well. (for example: sRGB to ACEScg, and Lin Rec709 to ACEScg)
Could the existing nodes in this menu be inverted?
Also, the mtlximage node has a "File Color Space" field with a dropdown menu of existing colorspaces available in the ACES config we are using. We would expect a selection of one of these colorspaces as the input color space would do a colorspace conversion to ACEScg at render time. (also called "Lazy ACES"). But field has no effect, no matter what we try.
Is this something SideFX is aware of? Your thoughts or workarounds are appreciated.
Thank you.
Mike
We are starting a new project with H20 and this ACES configuration: cg-config-v2.0.0_aces-v1.3_ocio-v2.2.ocio
Downloaded from here: https://github.com/AcademySoftwareFoundation/OpenColorIO-Config-ACES/releases/tag/v1.0.0 [github.com]
Building a simple MaterialX shader in /stage context materiallibrary reveals there are quite a few missing ACES colorspace transforms missing to convert a mtlximage from sRGB to ACES, or Lin Rec709 to ACEScg. All of the existing items in the MaterialX/Colortransform menu convert to Lin Rec709. We would expect nodes to convert to ACEScg as well. (for example: sRGB to ACEScg, and Lin Rec709 to ACEScg)
Could the existing nodes in this menu be inverted?
Also, the mtlximage node has a "File Color Space" field with a dropdown menu of existing colorspaces available in the ACES config we are using. We would expect a selection of one of these colorspaces as the input color space would do a colorspace conversion to ACEScg at render time. (also called "Lazy ACES"). But field has no effect, no matter what we try.
Is this something SideFX is aware of? Your thoughts or workarounds are appreciated.
Thank you.
Mike
Technical Discussion » Using VEX to determine unique ID per point
- mkschmitty
- 11 posts
- Offline
I added a Trail SOP and a TimeWarp SOP to the .hip file to illustrate the problem of the points jumping around due to the lack of a unique ID per point over time. See attached. All suggestions welcome!
Technical Discussion » Using VEX to determine unique ID per point
- mkschmitty
- 11 posts
- Offline
Hello!
VEX newbie here.
I would like to timewarp a 140 frame scientific visualization to make it 10x longer. In order to do this, I need a unique ID per point.
The simulation includes an ID attribute per point, however, each ID is duplicated multiple times, and the number of duplicates per ID changes over time.
The simulation includes other attributes per point, that could be used to help uniquely identify each point, such as P, density, internal_energy and metal0.
I was wondering if anyone on this forum can think of a way to cycle through each group of duplicate IDs, analyze/compare the additional attributes per point, to assign a truly uniqueID per point that is consistent through the entire frame range? Note that the point IDs stay fixed per frame, but the other attributes (density, metal0, internal_energy) change. Perhaps the rate of change of one or more of these attributes, relative to the ID, could be used to create a uniqueID?
Here's a screenshot of the data, and I've uploaded a small sample of the sim data. Thank you in advance.
Mike
VEX newbie here.
I would like to timewarp a 140 frame scientific visualization to make it 10x longer. In order to do this, I need a unique ID per point.
The simulation includes an ID attribute per point, however, each ID is duplicated multiple times, and the number of duplicates per ID changes over time.
The simulation includes other attributes per point, that could be used to help uniquely identify each point, such as P, density, internal_energy and metal0.
I was wondering if anyone on this forum can think of a way to cycle through each group of duplicate IDs, analyze/compare the additional attributes per point, to assign a truly uniqueID per point that is consistent through the entire frame range? Note that the point IDs stay fixed per frame, but the other attributes (density, metal0, internal_energy) change. Perhaps the rate of change of one or more of these attributes, relative to the ID, could be used to create a uniqueID?
Here's a screenshot of the data, and I've uploaded a small sample of the sim data. Thank you in advance.
Mike
Image Not Found
Houdini Indie and Apprentice » Some Display options do not work. Win7
- mkschmitty
- 11 posts
- Offline
Hi Lari,
My graphics card is a Quadro FX 5600
I just checked the 3d viewports scene render option and it was set to GL3.2.
I changed it to GL2.1 and now everything works!
Thank you. That's exactly the answer I was looking for.
Mike
My graphics card is a Quadro FX 5600
I just checked the 3d viewports scene render option and it was set to GL3.2.
I changed it to GL2.1 and now everything works!
Thank you. That's exactly the answer I was looking for.
Mike
Houdini Indie and Apprentice » Some Display options do not work. Win7
- mkschmitty
- 11 posts
- Offline
Hello,
I have Houdini Apprentice 12.1.185 installed on my Windows 7 workstation and I cannot get some of the Display options to the right of the viewport to work (i.e. Display points, point normals, point numbers, primitive normals, primitive numbers… all of the way down to Display custom attributes).
I have tried the following steps to fix:
- change the world Display Options. This doesn't work
- uninstall, reinstall houdini
- delete the Houdini12.1 in my Documents folder. Restart houdini
None of these work. Any ideas?
I have apprentice installed on my Mac laptop and it works fine there.
Thank you very much for your help.
Mike
ps. Please see the attached frame grab.
I have Houdini Apprentice 12.1.185 installed on my Windows 7 workstation and I cannot get some of the Display options to the right of the viewport to work (i.e. Display points, point normals, point numbers, primitive normals, primitive numbers… all of the way down to Display custom attributes).
I have tried the following steps to fix:
- change the world Display Options. This doesn't work
- uninstall, reinstall houdini
- delete the Houdini12.1 in my Documents folder. Restart houdini
None of these work. Any ideas?
I have apprentice installed on my Mac laptop and it works fine there.
Thank you very much for your help.
Mike
ps. Please see the attached frame grab.
-
- Quick Links