Jeff Lait

Cool! A note from the github:

@xres / @yres are always 0 inside COP wrangle context — Scale COP uses hidden spare parameters to pass resolution to VEX.

Note that the cop wrangle is the same as the SOP Volume Wrangle. Thus it uses @resx/@resy for the resolution of the volume.

I haven't looked at the HDA, but using parameters to read the input size will run into issues when the network gets compiled so is not advised normally.

Note using COPs does mean you are bouncing back to the CPU so lose the advantage of the GPU. It maybe the same math could be done in an OpenCL COP....?

Very cool to see solutions being built!

dnew
Anything I may be missing here?

I don't think so, if you can bundle this up, please submit a bug to support.

Glad to hear the 50% worked around this.

That baked geometry texture looks very suspicious, if that was the output and not a display issue, I'd expect things to be massively wrong not just de-ressed...

Cropping or saving the output should let you see if it is a display issue.

For the lack of improved quality, there could be various things... First make sure you haven't switched to 16 bit precision to save memory. 16 bit floats only have 1024 different grey levels so when you use them for things like positions in fractal noise they'll start to quantize and stop improving. This is what led us to change our defaults to 32 bit everywhere, so unless you fiddled, it should be 32 bit. (But you had memory issues so may have fiddled :>)

There could also be precision problems even with 32bit, but for most stuff you have 16million shades of grey with 32 bit so you should be safe for a "mere" 16k.