Add double-precision floating point feature 'use_f64'

[ipadjen]

So, I opened the issue #55, but then wrote the thing myself.

It's a feature 'use_double' that enables switching the float type from f32 to f64.

[Twinklebear]

Thanks for adding this feature @ipadjen ! Maybe I'm remembering another project or it was this one, but I think there had been some discussion about adding fp64 support by using some templating. I think it was actually this PR in arcball camera: https://github.com/Twinklebear/arcball/pull/3/files . I'm not sure if I want to add cgmath as a dependency here since apps using this library may be using their own math library, and I don't want to dictate/push one on them. However it looks like cgmath is pretty widely used, and we'd just be using the BaseFloat type from it, so maybe that's ok? Then you'd be able to load fp32 and fp64 OBJ files in the same codebase (might not be a use case anyone really has). Let me know what you think, since you'd be the user of the fp64 functionality.

For the CI tests:

• looks like build_linux is just failing on a formatting thing
• build_windows failure is kind of odd to me, I don't see changes here that should effect it and it was passing before
• nightly_features_linux: maybe we should exclude fp64 from the all features test somehow? It looks like a precision difference is causing this failure

[ipadjen]

I tried to keep it similar to tinyobjloader where they set the precision as a cmake option.

Just like you said, I don't have a use case for loading both f32 and f64 in the same codebase. I deal mostly with geospatial data, so a roundoff error can be pretty significant with single-precision. I personally don't know of a case where someone would benefit from both?

As for CI tests, I have no idea what's going on with windows. I can take a look into features test in the next few days.

[Twinklebear]

Cool, yeah keeping it as a build option is fine with me, it will help avoid adding breaking changes to the API too.

I'll take a look at the windows failure, it's pretty odd. Maybe something changed w/ cfg if or some other package.

[ipadjen]

Alright, sounds good!

So, 4c9e45d is my try to accommodate the tests. I added the float_eq crate with a relative tolerance (r2nd here) of 1e-7 and changed all floating point assertions with it. I figured 7 decimal points would keep all the tests within the single-precision accuracy. I tried fiddling with the test values a bit, I think it works fine.

[ipadjen]

Also, maybe 'use_f64' would sound more Rust than 'use_double'?

[Twinklebear]

I agree on use_f64, that matches the Rust type name so it'll be more what people expect 👍

[ipadjen]

I think the linux test should pass now with the updated formatting in 6cad6b3

[Twinklebear]

Cool! I think this looks good, I'll make some time to look into the windows/cfg-if specific issue

[Twinklebear]

Looks like the issue was that we actually were setting that split debug info flag in the Cargo.toml, and it seems to now be unstable/giving an error on windows when I don't think it was in the past. I've fixed that on master so I'll squash/rebase/merge this PR.

Thanks again @ipadjen !

[Twinklebear]

Actually, after doing that manual squash/merge/rebase github doesn't recognize this PR as being merged :/ . Would you mind squashing the commits down? Then I can just rebase it on to master w/ the GH UI.

[ipadjen]

There. Seems ready to merge now!

[Twinklebear]

Perfect, thanks @ipadjen !

[Twinklebear]

This is now released in 3.2.4: https://github.com/Twinklebear/tobj/releases/tag/3.2.4