2018.1 Instancing Cd without PPM file? Tweet

[ptunstall]

I'm working with a project that uses some pretty subtle gradients and the current .PPM file workflow has a TON of banding. if I switch from instancing to copy and render the PT Attrs with 2018 all works well but it's a good bit slower. Are there plans to make instancing work like the attrs in 2018 work?

[ptunstall]

It looks like these PPM files are 8bit. Is it at all possible to get them as 32 bit? Or point me in the direction so I can make them in NUKE or something similar?

[juanjgon]

Unfortunately, the instances don't support custom attributes yet, but this is a planned feature for Octane 2019. The problem with the .ppm file is not the 8 bits file depth, it is that the colors are encoded using only 6-bits per component RGBA to get a final 4k resolution image. To encode all the possible 8-bit per component RGBA color combinations you need a 65k resolution image, something not useful at all, I think ...

I hope that we can remove this workaround soon to use native custom attributes, as we have now in the mesh objects.

Thanks,
-Juanjo

[ptunstall]

Is PPM the only format this works with? I tried converting to an EXR file and "blurring it" but with the interlaced encoding blur destroys the "book ends" of each hue/value chunk. If I simply convert the PPM to EXR "without changing it whatsoever" octane reads it properly as it did the PPM file. Can we not simply recreate this pattern at a 16-32 bit depth and write it out as an EXR file?

[juanjgon]

You must understand that this file only has RGBA encoded color values. Any change on it is going to break this encoding. Let say that you have an instance with a (1.0, 0.5, 0.2, 1.0) RGBA value. This value is encoded into an integer value (that is the variable that Octane understand) that is referencing a single pixel in the .ppm image, that has this color/alpha. This is what Octane can read, the value of this pixel to colorize the instance.

We can't store an unlimited number of colors in the .ppm file ... it is not a matter of the file format or the bit depth. It can be an EXR file if you want, but a 4k image only can store 16M combinations of discrete RGBA colors meaning that you have a 6:6:6:6 bits encoding. We could support 8:8:8:8 bits encoding, but then the texture file should be a 65k image, something that is going to eat much of the available GPU RAM.

Thanks,
-Juanjo

[ptunstall]

I see! Interesting predicament for sure. Thanks so much for clarifying Juanjo!

[juanjgon]

All this stuff is only a workaround added to the Octane core some time ago while waiting for the final proper custom attributes support. The instances (or the points or hairs) only can store a number, that is used to get a position in a texture file. This pixel in the texture must have the color that you want for the instance/point/hair, so what I had done to make something useful with this feature is to build this .ppm file (created by a custom external tool) that stores 16M RGBA color combinations, that as you have found, probably they are not enough to build full gradients without color steps.

Thanks,
-Juanjo