Extend Vray colour to have a map slot, add in some colour correction features too?

[joconnell]

Heya Folks,

I think a few folks had mentioned it and Vlado had also said that he was going to add a few more features into the vray colour map - think it might have been colour temperature so you had that option to use inside a vray light material perhaps? Just wondering if it's possible while you guys are at it to add in a few more features to the vray colour map to make it into a general purpose map for dealing with bitmaps and hdris? The built in max colour correct map is dreadful - the hue and saturation controls seem to break colour information really easily so I wouldn't trust it to work on hdr or exr files. Having the option of hue, saturation, tint and then curves / exposure is really handy (at the minute I'm doing nothing but grading hdris to match lighting) to have in the program, and it'd be even handier to have made by someone we trust to deal with colour data correctly, and also have it installed as a default with a plugin we'll always use.

Does this sound like something feasible? Or even as an option to expand the likes of the Vray Bitmap plugin?

Cheers!

John

[vlado]

The temperature mode for VRayColor is already implemented in the latest nightly builds; we could look into a more general color correction map, but I'd be curious to learn how many people will actually use it...

Best regards,
Vlado

[super gnu]

+1 for a chaos colour correction tool. the max one, as Joconnell says, is crap. i -always- end up going back to photoshop, as the correction controls in max just screw everything up.

[vlado]

Well, one thing to keep in mind is that the corrections happen during rendering - for every single ray that hits the texture (and for complex scenes, there can be billions or rays). For this reason, complex color processing may slow down the rendering quite a bit, in which case modifying the texture itself might be more efficient anyways.

Best regards,
Vlado

[rikou]

+1 !
CC is so often used that It would be great to have a good one from Chaosgroup !

[joconnell]

Well, one thing to keep in mind is that the corrections happen during rendering - for every single ray that hits the texture (and for complex scenes, there can be billions or rays). For this reason, complex color processing may slow down the rendering quite a bit, in which case modifying the texture itself might be more efficient anyways.

Best regards,
Vlado

That's a pretty useful bit of information too!

[zeronove]

Well, one thing to keep in mind is that the corrections happen during rendering - for every single ray that hits the texture (and for complex scenes, there can be billions or rays). For this reason, complex color processing may slow down the rendering quite a bit, in which case modifying the texture itself might be more efficient anyways.

modifyng the texture in PS is what I do exactly because I had a suspect about this issue

the questions now are:
- is this true also for the output rollout or similar?
- is not possible a sort of "texture baking" on the fly just before render starts to avoid CC computation for every single ray? ...something is saying it could not be so easy

[bodhi5000]

Would this slowdown be true of using the "Output ColorMap" as well?

[vlado]

Would this slowdown be true of using the "Output ColorMap" as well?

There is some performance penalty, but it might be negligible in most cases.

Best regards,
Vlado

[trixian]

I'd definitely use an improved CC map. Especially one with curve controls like in the VFB.

Though I'm curious as to why this would be during rendering and not as a preprocess of the map. Does Vray trace rays for every single node in the material when the end result on the material is the only thing needed (in most cases)?
Does the current CC slow down rendering like you describe?

Adjusting the colour of a texture (bitmap) beforehand is rather counter intuitive when making materials, and also seems a waste of memory when yo see 10 variations of the same map with just slight gamma and hue differences. Seems more logical to vary these maps through CC nodes, and also derive other maps from them if possible.

[vlado]

Though I'm curious as to why this would be during rendering and not as a preprocess of the map.

Precisely because of the next sentence where you say this takes 10x the memory

Does Vray trace rays for every single node in the material when the end result on the material is the only thing needed (in most cases)?

No, of course. But for every surface hit, the entire texture tree is evaluated in order to get the "end result". The result is not cached anywhere - it must be recomputed for each hit.

Does the current CC slow down rendering like you describe?

There is some performance penalty, yes. Since the CC map is relatively simple, this may be negligible for most scenes. But more complex color corrections could be a lot slower.

Adjusting the colour of a texture (bitmap) beforehand is rather counter intuitive when making materials, and also seems a waste of memory when yo see 10 variations of the same map with just slight gamma and hue differences. Seems more logical to vary these maps through CC nodes, and also derive other maps from them if possible.

As with many things, it's always a balance between speed and memory

Best regards,
Vlado

[joconnell]

Makes sense - if you had an animated colour correction vray'd have to throw out it's caching each frame anyway, thinking about it there's a lot of calculations at play even with normal bitmaps - you've got a ray hitting a surface, then that doing a uv coordinate to pixel lookup, then the filtering of that pixel to interpolated sub pixels and then returning. CC might add on a penalty but it seems like using bitmaps is heavy on calculation anyway!

For something like calculations of HDRI or EXR images it might make sense in that regard to have a function to commit your CC to a baked file - you'd have all the colour correction controls live in your viewports to save swapping apps, but then the speed benefit of baking down to a file after?

[trixian]

Ok.

Well then this begs the question: Why can you not cache the materials after the first evaluation? Certain things would probably need to evaluate different nodes in the tree from time to time, but a majority could just do a lookup in the cache couldn't they?
(Do you get the sense that I have absolutely no idea how to program? )

Thinking about this for more that a few seconds, this would be impractical for materials with large bitmaps added to them, as the cache would quickly become rather large. But for simple materials and materials with smaller bitmaps in its tree, a caching option maybe? Or would this be a waste of time anyway? I feel we might be heading into renderman land with this where you end up with massive datasets and unintuitive ways of handling them.

[joconnell]

Ok.

Well then this begs the question: Why can you not cache the materials after the first evaluation?

Animated CC!

[kagemaru]

+1 for a better color correction map from chaos.
Max one just doesn't work as you would expect, especially in a lwf environment.