Open Lucasrsv1 opened 5 years ago
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.
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
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.
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
@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...
Agreed @odalet - if you could submit a PR that'd be awesome cause I am flat out!!
I'll try to provide you with something this week-end!
Here you go: PR #173 for you to review!
I found this error while trying to load a .obj file.