recalculateNormals produces (0,0,0) - not enough precision

[hendu]

Model: dragon_vrip_res2.ply from http://graphics.stanford.edu/data/3Dscanrep/

The Stanford models don't come with normals, so naturally they need to be generated. At least the two highest-resolution models produce normals of all 0 with recalculateNormals, maybe the two lower ones too, didn't test.


When I replace the cross-product and normalization with some higher-precision code, the normals are correct:

Code: Select all

static vector3df cross64norm(vector3df a, vector3df b) {
        vector3d<long double> newa(a.X, a.Y, a.Z);
        vector3d<long double> newb(b.X, b.Y, b.Z);
 
        vector3d<long double> newc = newa.crossProduct(newb);
        long double len = newc.X*newc.X + newc.Y*newc.Y + newc.Z*newc.Z;
        newc /= sqrtl(len);
 
        return vector3df(newc.X, newc.Y, newc.Z);
}
 

Probably double/f64 would be enough, but I just needed good normals here, not speed. BTW trying to write the resulting mesh out to PLY (only format supporting 32bit ), the result is quite mangled too, probably a bug in the PLY writer.

[hybrid]

So where is the precision lost? crossProduct or normalization? Introduction of a new type "internalFloat" would be good, which specifies the type the intermediate calculations and results are made with. Not sure if it's always easily convertible, though, as we also want to avoid unnecessary data assignments e.g. in the case if internalFloat==f32
About the PLY writer problem: Does it occur for the 32bit data only, or always? And with which mesh viewer did you cross check the results?

[hendu]

Both, I think. Further, the reciprocal_sqrt function always uses the float-level sqrt (f32).

About the PLY writer problem: Does it occur for the 32bit data only, or always? And with which mesh viewer did you cross check the results?

I don't know, this is the first time I've tried to use Irr's mesh writing. Irr is also the only app I have that can read PLY (I use Greg Turk's ply_to_obj converter to edit the models in obj-supporting apps).

But the point being, irr fails to read the same model it wrote out 32-bit indices and quite a lot of them, yes.