I’ve exported from zbrush 32bit exr displacement maps and imported them to mari into a 32 bit linear/raw (tried both) channel for the purpose of making higher-res additions to the displacements in mari, but I’ve discovered that even an unaltered re-export of the zbrush maps from mari renders very differently than the raw zbrush export. Specifically, there is a loss of detail and even overall volume. I’ve never encountered this before… that I am aware of… Does anybody else have an idea of what’s going on here?
Hello @Francis_Bezooyen
I can’t speak to what may be going on in your external application. Questions regarding its use should be directed at resources devoted to that program. From your description though, it sounds like your external program may not be exporting the images as true 32 bit. Again, this is only a guess.
I just found this thread again and thought I should share what I eventually learned about this issue.
I still don’t know why the renders from the two different outputs turn out differently but I did figure out a way to resolve the issue, namely to apply desaturation to the zbrush maps in Mari prior to exporting them. But, it has to be a specific method of desaturation. The same correct result can be achieved in three different ways. They are:
- Set the saturation to zero in an HSV node/adjustment layer (NOT HSL)
- Use a shuffle node to set the g and b channels to r
- Use a desaturation node (I think this comes with the mari extension pack… I’m going off of memory here) and set the method to “maximum”
Each of these methods appears to achieve the same result, and once processed in this way the zbrush map exported from mari renders displacements correctly.
It is very strange that this step should resolve the issue. The closest I can come to conceiving of an explanation is that some form of data in the zbrush exports must cause the render engine to treat each color channel as though it possessed the same data that is held in the red channel. That is very much a guess but it is one that seems suggested by the method of desaturation that is required to produce correct results in the render.
This may be of no interest to anyone but me, but - the reason I hadn’t encountered this problem before is that I have always been in the habit of applying a desaturation to exported zbrush maps simply to make them easier on the eyes while applying edits to them. It was a series of unusual events, that I won’t bother detailing, that led me to discover this issue. It’s kinda funny how your workflow can resolve potential problems without you ever knowing about them.
BTW @Spyndel - thank you for your reply. I’m sorry I missed it.