Hi,
I created an ocean in sop and rendered it karma.

But there is a error report(please check the following pics).

What is miplevel and "round-down"
mode? How can I solve the problem?

Thanks!

hfsxddut
But there is a error report(please check the following pics).

What is miplevel and "round-down"
mode? How can I solve the problem?

That's not an error, you can ignore it. The error on your render node is unrelated. Maybe you have sop layers that don't have save paths set?

jsmack

hfsxddut
But there is a error report(please check the following pics).

What is miplevel and "round-down"
mode? How can I solve the problem?

That's not an error, you can ignore it. The error on your render node is unrelated. Maybe you have sop layers that don't have save paths set?

Thanks anyway but I do not believe that this can be ignored..seems that this error is critical, maybe something wrong here..

Mip levels are smaller versions of a texture map that are used in the distance where the full resolution isn't required (or visible) if necessary... usually it was more important back before anisotropic filtering was standard on GPUs so textures didn't flicker in the distance. I can't imagine XPU would even need them... I guess .exr supports embedding them in the file since that's where it says it found them. The round-down mode is presumably how it's supposed to be picking sizes for those. Traditionally it's the next power of two down to some arbitrarily small number. I don't know enough about .exr to know whether "miplevels" is a flag or refers to actual pregenerated textures (they're usually done on the fly these days since it's cheap to downscale images) or whether round-down mode is specified on the material node or shader, but the message makes it sound like it's all issues with the file. Normally you'd just warn and keep using the lowest resolution map available or downscale it yourself though. It's possible the image ended up at some non-even number and round-down mode is literal so it was supposed to go to round the resolution down to the next integer when it divided that by 2 but the file included an image that was rounded up instead.

I'd open it in Krita or Photoshop or something and see if you can resave it without mipmaps which probably just involves re-saving it since that format is used for high resolution HDR photography more than anything and I seriously doubt Karma isn't filtering textures itself.

Check the oceanspectrum file you saved. I had the same issue, and it was and wrong file I saved.

hfsxddut
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.

brians

hfsxddut
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.

The original problem texture is one built into Houdini, a color lookup ramp of some kind. Perhaps the Houdini tools do not abide the round down rule when creating mips for exr?

jsmack
The original problem texture is one built into Houdini, a color lookup ramp of some kind. Perhaps the Houdini tools do not abide the round down rule when creating mips for exr?

Oh appologies, we fixed this bug in 20.0.584
What version of Houdini is the original poster on?