16 bit / 32 floating problem

[mmrender]

Hello,

while I was looking to test Combustion RPF motion blur I found this problem when saving my animation to floating 32 bit. As you can see in the image the trees get a weird halo (right image) while if saving to 16 bits deep they look correct (left).



I suppose it has to do with a premultiplied alpha but I cannot find the solution. I'm saving those frames with ZBufer, Velocity, Coverage and Render node to import them into Combustion. One courious thing is that sometimes if I save the frame manually from the Max FB in floating the result is OK. No idea.

I'd like to ask also about the advantage to use 32 vs 16 bits to do that process of MB, maybe I don't need to go with so high resolution.

Thanks,
Manuel

[Morbid Angel]

i cant remember exectly, but I think this issue is resolved in newer versions of vray. Or there was a solution on the forum a while back. About bit depth, most defenently you can go with 16 bit.

[studioDIM]

You shouldn't use vray's framebuffer with rpfs.
Use max's FB and the max's save dialog.

Also note that when saving float any gamma you might have applied is discarded(as it's a linear format), so a CC map might or might not work.

As for the 16bit/32bit choice, i'd say try and see for yourself.
It's dependant on the scene: 65k values for Z might or might not be enough to have a precise definition of depth.
The same goes for when you have trees, the velocity channel, and rendernodeid tend to grow larger (especially if leaves are individual, but even with trees as single objects) because there's more variance across the image (the relative speeds of the various parts of the tree, for instance).
So 16 bit might be a bit short, but maybe not

bottom line: test it

Lele

[Dynedain]

I spent a lot of time fighting through this problem, and what I found is that when opening 32bit floating point images, Combustion clamps the white level, not allowing anything higher in range. It will do the same thing with EXR files.

[panthon]

I spent a lot of time fighting through this problem, and what I found is that when opening 32bit floating point images, Combustion clamps the white level, not allowing anything higher in range. It will do the same thing with EXR files.

From my experience, combustion clamps higher white values only when u premultiply the footage. I know premultiplying is desirable, so it is a big big drawback.

I have noticed problems like black halos with rpf motion blur when the 3d object is rendered against black, being solved when rendered against white.

Some trees with transparency show problems with their alpha when using rpf 32 bit, with 16 it's solved. I have been using 32 bit rpf extensively and I find it lets me recover overexposed white areas and heavily underexposed ones. The problem is combustion seems to have problems with some alphas, especially when dealing with rpf motion blur. I dont see the relation between higher bit depth and crappy alpha channels...

[studioDIM]

Ah, panthon, a breath of fresh air, you are!

Nicely put.
I agree entirely.

Lele

[mmrender]

thanks for the ifo. I'll stick with 16 bit deph by now until being more aware of all this stuff.

Manuel

[panthon]

New things about this topic!

Now im finding problems when rendering to 32 bit rpf, referring to clamp output:



As you can see the top image is what I see in vrayframebuffer and the bottom one is what I get in combustion: the last one has jagged edges on bright reflections.

The image has been saving directly from the max rendersave dialog, not manually pushing the save button from vray framebuffer.

I check clamp output in vray but it seems to to ignore it and render it unclamped anyway. Does it make any sense to render to 32 bit and check clamp output? It sounds like a contradiction to me, need advice on this topic.
And, Is there any way to get float unclamped footage WITHOUT jagged edges on high lights? Read somewhere it was unavoidable...
Thanks!

[studioDIM]

clamping with 32bit means just that values will never top 1.000.
What you see in combustion is an unclamped version of that image, probably identical to the realRGB chan in vray.
Also, it seems your vray vfb has "force color clamping" active. Uncheck it, and while the display of over-1.000 colors will differ from combustion's you'll see how similar they become (a LOT more jaggies also in the vfb).


EDIT: the thing about highlights AA was under the universal settings thread. To partially correct it, you might try using an unlocked specular glossiness, with a value of something like .99/.95 and see if the slight blur to the edges helps covering the shapr stepping between high and low values.

Hope it helps


Lele

[panthon]

Thanks for the info Lele, i will try what u have suggested