If I'm using op:in MaterialX Tiled Image to reference textures generated by Copernicus network, how can I force Karma to update textures when texture size in the referenced Copernicus network changes?
I already tried:
"Render → Update Textures",
restarting Karma render,
switching to VK then back to Karma XPU,
switching to Karma CPU then back to XPU.
None of the above works. Textures are rendered in their original size. The only working solution I found, is reloading the scene. But, as you may suspect, I'm not happy with this workaround.
EDIT: Actually, the only workaround is to restart Houdini, as reloading the scene introduces cooking problems and erratic behavior of USD MaterialX Builder subnet.
I can't seem to reproduce this. If I load the .hip file and change the resolution in the quickmaterial/sizeref1 node, Karma seems to update for me. Can you post a simple example?
Upon further inspection, I think the problem is that in order for op-referenced textures to be updated in Karma, something must be changed in the Copernicus network other than just its resolution. Something that invokes cooking. I see that you're using sizeref piped to the checkerboard generator, while I'm using the "Default Resolution" parameter of the COP Network itself. This might explain why in your case the change in size is picked up by Karma, and in mine it is not. In your scene you can easily reproduce the issue by removing sizeref operator and by changing the "Default Resolution" on the COP Network LOP. Karma will not update textures to new dimensions.
This also affects VK viewport in Solaris, so it's not a problem with Karma, but rather with communication between Copernicus and Solaris contexts. While changes of "Default Resolution" parameter on the COP Net are recooking the Copernicus network inside, somehow the information that the network has been changed is not passed to Solaris. I don't know how it works under-the-hood, so it's just my theory, but this is how it looks to me.
A workaround I found today, that doesn't involve reloading the scene or the whole program, is that in order to update textures in Solaris context after "Default Resolution" of the COP Net was changed, I need to temporarily modify any of the parameters that are on one of the operators that are at the beginning of the Cop Net. In other words, temporarily modify parameters on root operators. What I'm unsure of, is if the network begins in many places, do all roots need to be temporarily modified in order for Solaris to receive correctly updated textures, or not.
I'm using 20.5.370. That bugfix from 334 is probably addressing something else. I can think of several similar issues that were present in 278, but must have been fixed somewhere along the way to 370.
Anyway, I already reported this issue, so now I'm waiting for a fix with my fingers tightly crossed.
