Closed ghost closed 10 years ago
So initially I thought that changing the number format would go against the specification (since supporting both adds some unnecessary complexity), but then I looked at the obj specification. Turns out it doesn't mention a thing about how numbers should be formatted at all, and Maya loads it just fine, so I'll make the change in a few minutes. Thanks!
I think you misunderstood a bit, the problem is not that the file can contain commas but that your program didn't understand points in certain system locales. The specification and all properly written tools export only points as decimal separator, so it should be enough to always use just them.
The problem is that .NET automatically switches to "commas only" depending on the current locale, which means your program breaks with existing (invariant/point decimal separator) files in most not-English-language regions. Specifying CultureInfo.InvariantCulture
restores the correct behaviour for non-UI/exchange formats.
The fix means it will always only work with points, not that it will understand both.
Oh, yeah, I see how I thought the issue was the inverse of what it actually was. Turns out, Maya still imports OBJ files with commas as the decimal separator, though float.TryParse
will see it as a "thousands" separator and give me a much larger number than expected for most files...
Either way, the original issue is fixed.
If you want it to throw on ,
and currency symbols, use NumberStyles.Float
.
Any
will parse e.g. 19,99€
as 1999
if I read the documentation correctly.
Hi, in your object importer you are using "float.TryParse". (ObjModel.cs Line 57 for example) // if (!float.TryParse(line[1], out v.X)) continue;
You forgot to specify InvariantCulture. I live in germany and we use ',' as separator for the decimal places.
Use this line to fix the bug and make it work for English and German cultures:
if (!float.TryParse(line[1], NumberStyles.Any, CultureInfo.InvariantCulture, out v.X)) continue;