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

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 0.50%. Comparing base (609c21e) to head (8393840).
⚠️ Report is 87 commits behind head on main.

Additional details and impacted files

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

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[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!