Dikkker wrote:forgeflow wrote:One thing to make note of though - 100% white doesn't exist in the real world. That would be a surface that reflects 100% of all light hitting it. The whitest white you'll encounter in the real world reflects *maybe* 80% of the light hitting it. Keep this in mind - C4D's conventions don't really simulate real-world conditions. I've done perfectly reasonable renders of "white walled" rooms in LuxRender where the wall colour was 50% grey in C4D.
Ok - I'll play with the different modes and post the results later today.
Anyhow - the question (from a usability standpoint) is, if there should be some sort of "adapted conversion" between a non-physical editor and a physical renderer. Otherwise you can never use any kind of (editor) preview for your final rendering, which would turn the renderer useless IMHO.
If Lux needs a white value of ~80% (or less) for the brightest natural white, then a 100% C4D-white should convert to that. I know this depends a lot on other factors such as lighting and camera settings, but if a renderer should be useful for any person from a creative rather than a technical background, than this is inevitable...

IMHO.
How does this work in other renderers, such as Blender or Maya?
Cheers
Dirk
Hi Dirk,
I think there is still a misunderstanding: It's not that Lux "needs" a 80% grey to get a bright natural white. You can get a bright white with 50% grey as well as with 20% grey - it's just a matter of exposure time. Lux just behaves like a camera: If you expose long enough even the darkest colour (except 100% pure black) becomes white eventually.
And yes you can get good results with 100% colours, too. The problem is more a numerical one: In some circumstances you can get fireflies, which are caused by numerical degeneration while light bounces between perfectly white surfaces.
I have thought about capping or scaling colours during export. There are two reasons why I haven't done it yet: I don't know where to cap (at 80%, 90%, 95%, 98 or 99%) and I don't know how to cap textures (which can be 100% white, too) without adding extra load (by putting all textures into a scale texture) which slows down Lux again.
And I didn't think it was necessary. All the above problems are mainly tone-mapping problems and not colour problems. That's the reason why by default the next version of LuxC4D will use "maxwhite" as default tone-mapping (check your Lux mailbox

), which I hope to release this weekend.
Cheers,
Marcus