Bug fix. Using comma instead of dot in Convert.ToSingle

[Lucasrsv1]

I found this error while trying to load a .obj file.

[codecov]

Codecov Report

Merging #158 into master will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff          @@
##           master   #158   +/-   ##
=====================================
  Coverage     0.5%   0.5%           
=====================================
  Files          91     91           
  Lines        3781   3781           
=====================================
  Hits           19     19           
  Misses       3762   3762

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 609c21e...8393840. Read the comment docs.

[dwmkerr]

Thanks @Lucasrsv1 - do you know why this occurs? Is it localisation related? Just want to make sure I don't cause issues for other locales

[Lucasrsv1]

Hi. Yes, it's related to location. It looks like the function Convert.ToSingle takes into consideration System.Globalization.CultureInfo.CurrentCulture in order to parse the value it receives.
I've just run a test calling Convert.ToSingle("12.45"), when CurrentCulture.Name was "en-US", it returned the float 12.45, and when CurrentCulture.Name was "pt-BR" (Brazilian Portuguese) it returned 1245.

[dwmkerr]

Ahah I see - in that case as the obj file itself always uses a dot for decimals. This means that Convert.ToString is not going to be enough - we should call Convert, but specify explicitly that we use the CultureInfo.InvariantCulture culture. This means no matter what the locale settings of the user's machine, the decimal point will always be read correctly. With the current PR anyone who has a local culture which does not use a comma will not be able to read the files properly

[odalet]

@dwmkerr I would advise you don't merge this PR. I think it will not work anymore for any culture such as English that use . and not , as the decimal separator.

I too (on French machine) experienced issues when loading .obj files which I fixed differently (and arguably in a more portable way).

What should be done is: everywhere you use float.Parse, Convert.ToSingle, double.Parse, Convert.ToDouble and the like... append a CultureInfo.InvariantCulture as the second parameter. This will make sure the conversions do not rely on the machine's current culture, but instead always use . as the decimal separator.

I'll try to find some time, and submit here another PR...

[dwmkerr]

Agreed @odalet - if you could submit a PR that'd be awesome cause I am flat out!!

[odalet]

I'll try to provide you with something this week-end!

[odalet]

Here you go: PR #173 for you to review!