BrianHanke
Wow, so it does. That is sneaky!
you have to relaunch houdini for any changes to OCIO to take effect.
BrianHanke
Wow, so it does. That is sneaky!
skadbone1
OK, thank you . Should this impact my caching or rendering? can you suggest what I can do to avoid this,?, or should this not be an issue, thanks, Craig
olivierth
...but How can I use a relative path? I tried this but it doesn't work:
op:/CopTriplanar/OUT_Texture
op:`opfullpath("relativepath")`
You can check if it works by middle mouse clicking to see the expanded path.
BrianHanke
Changing rules has no effect on texture appearance for me. Never has. Make a grid with a JPG texture attached, render in Karma CPU or XPU, looks fine. Change the rule to ACEScct (for example), nothing changes. No amount of resetting Karma or updating textures has any effect. I thought maybe Houdini needs a restart for the changes to take effect, but all the changes to rules are reverted after restarting. It's all very confusing.
jumax
In the attached image have 512 path traced samples and 6 light samples even after 9 mins there is no resolution. in the previous examples I let it run for 30 mins and there was not enough improvement.
toonafish
And when I use the UV_Layout SOP with an imported FBX that has 2UVsets and several parts ( like body and clothing ) I lose the UV's of the clothing after using UV_Layout.
BrianHanke
Yes, the XPU steps create an updated .rat file (the original texture is .jpg in my test). Here's a clip showing the texture corruption that happens with texcache -c (which I assume is what Render > Update Textures is doing).
BrianHanke
Karma XPU
- Can overwrite texture at any time
- Pause or restart does not update texture
- Switch to GL, Reset Karma XPU, switch to XPU does not update texture
- Render > Update Textures while XPU running does not update texture
- Render > Update Textures, restart render, texture now all black
- Repeat above step again, texture now updated
- Render > Update Textures, switch to GL, Reset XPU, switch to XPU, texture now all black
- Render > Update Textures again, restart render, texture now updated
I think there are some other combos that work with XPU, but you get the idea.
Long story short, neither CPU or XPU gets it right. CPU locks the texture, XPU does it right. CPU updates the texture without any extra steps, XPU does not. I think the way it should be in both CPU and XPU is the texture never gets locked and it updates automatically.
digitalwu
Thanks for reply, but your picture is pure white.
digitalwu
The geo is crop from part of the product. The product geo is full capped. They both have the same issue.
robp_sidefxjsmack
Like spheres and nurbs
Spheres are coming
Requires use of the Hydra 2.0 StageSceneIndex and a renderer that supports spheres, but the plumbing for this one is already in place: https://github.com/PixarAnimationStudios/OpenUSD/blob/release/pxr/usdImaging/usdImaging/sphereAdapter.cpp#L64-L73 [github.com]
digitalwuTheNotepadShow
Ahhhh... little confused? You have an ABC file loading. Now maybe the ABC file was created procedurally, but the *.abc is not included with the hipnc.
reupload the abc file.
brianshfsxddut
What is miplevel and "round-down" mode?
As Gordon says, its to do with the resolution of the miplevels in the texture.
So to create the miplevels, we take the main image and resize it by half, and store it as miplevel 1. Then for level 2 we halve level 1. And so on...
For images that have awkward image sizes, for example 230x180, then the halving will produce 115.5x90. But because we can't have 1/2 a pixel, we need to round the 115.5 either up to 116 or down to 115. GPUs can only handle "round-down" mode, so for XPU if we ever detect an image with "round-up" mode, then we stop loading the mipchain at the problem level.GnomeToys
usually it was more important back before anisotropic filtering was standard on GPUs so textures didn't flicker in the distance
Its still standard, and we will get flickering if we don't have the correct mips/filtering.hfsxddut
How can I solve the problem?
To fix this you can...
- regenerate the EXR using "round-down" mode (I'm not familiar with your tool chain, so can't say how to do this sorry)
- regenerate the EXR with no mips at all (XPU will then automatically create them, and cache the result on disk)
- resize the EXR to a power-of-two size.
tshead2
I’m sympathetic when it comes to the limitations of Karma XPU, but it’ll be a big disappointment if Karma CPU + VEX ends up missing big chunks of Mantra functionality … I’m already upset at losing shade().
evanrudefx
update: seems to be the case where if raising the max secondary samples makes the image noisier, if I lower the variance threshold/noise level and render it again, it resolves a cleaner image. Still odd that raising max secondary samples would make the image noisier.
robp_sidefx
There are a few things with lights like that (i.e., USD that you can author which doesn't translate through Hydra).
TwinSnakes007
In that list, you'll see your 'colors' defined as:
primvars:colors
primvars:colors:indices
primvars:colors:lengths