It's not a normalization issue as the normal vectors are normalized in Euler space before being converted to RGB color space. If it were a post process problem, there would be differences in all cases. So far I only see the difference when one or both meshes are transformed indicating it's a coordinate space computation issue.
There is no issue with a cage either. See my previous reply to the this thread with example scene. The cage is only relevant when there are many layers of overlapping surfaces. In my example it's a simple cube and sphere, so no need for a cage. Matt -----Original Message----- From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Tim Leydecker Sent: Friday, January 03, 2014 3:11 AM To: softimage@listproc.autodesk.com Subject: Re: ultimapper issues - tangent space normal maps Hi Matt, A shift in the final intensity could come from a per channel normalisation. You´d get different results if you don´t have such normalisation/levels operation as a postprocess of your saving calculations to file. But it should be easy enough to test if suc a normalisation would give you similar results to XSI. In the dirtiest&cheapest way, in Photoshop>Auto Levels. Since Szabolcs already pointed out that there is no cage option in Ultimapper, e.g. no manual control of a min and max searchdistance for calculations, I´d guess the min and max is fixedly determined by the maximum distance between highrez and lowrez mesh and the results are "smoothed out" by remapping to 0-1 per channel for best use of the file´s available intensity steps. I could be completely wrong, thought. In general, I will most likely use ZBrush and CrazyBump to create and modify Normals in a let´s say, artsy partsy mashed potato kind of way that gives me the look I want without knowing much more than Green>light from Ground, Red>light from Right to work in Cryengine/UDK/3DSMax. Cheers, tim On 03.01.2014 07:51, Szabolcs Matefy wrote: > Hey Matt, > > Your result might be different because of the tangent space > calculation. I suppose that the normal map calculation might be done in > object space, then Ultimapper converts it into tangent space. Ultimapper > could be quite good, but lacks a very important feature, the cage. So finally > we dropped in favor of xNormal. > > You might check few things (I'm not a programmer, so I may be wrong). > Check the transforms. In my experience transforms has effect how vertex > normals are calculated. Certain distance from the origin might result > imprecision (is this the right word?), and the farther the object is from the > origin, the bigger this imprecision is. > > There are discrepancies, for sure, because these tools have different > approach to derive tangent space. For example, Softimage uses the > vertex color to store the tangents, and binormal is calculated from > this. But, if your smoothing on the geo and on the tangent space > property differs, you won't get any usable normal map. For example the > smoothing on tangents made Ultimapper quite useless for us, so I wrote an > exporter for xNormal, and since then we have no issue at all. As our > technical chief explained, a normal is correct only if the normal baking and > displayer use the same tangent calculation. He wrote a tangent space > calculator for xNormal, that uses the same algorithm CryEngine uses. So, > unless your game engine approached tangent space differently than Softimage, > you won't get good result. > > I think the whole game pipeline should be redesigned in Softimage. > > *From:*softimage-boun...@listproc.autodesk.com > [mailto:softimage-boun...@listproc.autodesk.com] *On Behalf Of *Matt > Lind > *Sent:* Friday, January 03, 2014 5:17 AM > *To:* softimage@listproc.autodesk.com > *Subject:* ultimapper issues - tangent space normal maps > > I am writing a modified ultimapper to convert tangent space normal > maps from one mesh to another. The tool is needed because our tangent > space normal maps are not encoded in the standard way and softimage's tools > cannot be modified to support our proprietary tangent space. For prototyping > I'm using the softimage tangent space and tangents property to do the > transfer so I can check my math against ultimapper. Once I get a 1:1 match, > I'll modify the logistics to support our proprietary stuff. > > So far when the hi and low res meshes are untransformed I get a 1:1 > match with ultimapper, but when I transform one or both meshes a wide > discrepancy appears between my result and the softimage ultimapper > result. The softimage result tends to be significantly brighter on the red > and green channels, mostly on the green. In some cases, the colors are not > even close to the same. The odd part is when I trace through the process > step by step to debug, my numbers look correct both visually and > mathematically. I'm in a weird situation in that I do not know who's result > is more correct, mine or Softimage. > > Some of our artists have mentioned there have been some discrepancies > compared to other commercial normal mapping tools (beyond flipping the Y > axis). Has anybody had issues getting correct results from ultimapper when > transferring tangent space normal maps between meshes? > > Matt >
