You can use the exrheader command-line tool that comes with the OpenEXR sources - it will show everything you need to know about an OpenEXR file.
Best regards,
Vlado
You can use the exrheader command-line tool that comes with the OpenEXR sources - it will show everything you need to know about an OpenEXR file.
Best regards,
Vlado
Hi Vlado,
nice to meet you ![]()
if I:
1) dont flag “don’t affect colors”
2) set output gamma 1.0
or if I:
1) flag “don’t affect colors”
2) set output gamma 2.2
Do I get the same result?
Thank you in advance ![]()
It depends on where you set the gamma. If you set it in the V-Ray color mapping options, then the results should be the same (but it depends on your other color mapping settings as well). If you change the 3ds Max output gamma, then they will be different.
Best regards,
Vlado
Yes Vlado,
sorry… hehe you’re right.
I was supposing in “V-Ray color mapping options”, but just in my mind!
Thank you for clarify ![]()
Vlado,
I think we found an issue in Vray 2.2.02. We’ve noticed strange happenings when using Composite maps fed into the texture slot of Vray Area lights in use with RT (CPU). It’s difficult to reproduce though. With bitmaps or standard maps fed into layer input slots of a composite map and others feeding into their mask inputs, when you adjust the opacity slider in that composite map, RT will sometimes freeze or return black in those lights. I’ve been trying to build a scene to post here but this issue is crashing max completely.
Are the DR problems sorted out now ? Not been keeping up to date with the updates.
Ok I’ve pin pointed the issue. The problem: RT (CPU) using a composite map in the texture slot of a vray area light and lowering the opacity to zero on the bottom layer of that composite map, will cause the entire light to go black in Vray RT (CPU) 2.20.02. The bottom layer’s opacity seems to effect all layers above it. I’ve linked a simple scene here that demonstrates the problem. If you run RT (CPU) and adjust the composite map layer opacity on layer 01 you will see the issue.
There should be some improvements in that area for the new service pack. Whether they will sort out completely all DR problems, I do not know.
Best regards,
Vlado
Thanks, will look into it.
Best regards,
Vlado
I don’t have 2.2.3 here (still running 1.5sp5) but can anyone confirm massive crashes to desktop with particle flow toolbox#2 and it’s particle skinner (that allows for ripping and tearing) and changing topology? In particular when this changing topology mesh is cached with SuperMesher at any given sub frame sampling quality.
It would be best if you can get me a scene for this to vlado@chaosgroup.com
Best regards,
Vlado