Float precision error

[AtlasOmegaAlpha]

BrawlBox seems to screw up high poly/complex models because of float precision. This is actually a .NET problem, with the System.IO ReadSingle/WriteSingle function which does not flip the exponent correctly. Riidefi found out a way to get rid of it by using BitConverter:

byte[] floatBytes = base.ReadBytes(4); Array.Reverse(floatBytes); return BitConverter.ToSingle(floatBytes, 0);

byte[] floatBytes = BitConverter.GetBytes(value); Array.Reverse(floatBytes); base.Write(floatBytes);

[libertyernie]

Do you know which .cs file(s) this should go in?

[AtlasOmegaAlpha]

Most likely into any file that contains a BinaryReader that reads Singles. I guess it would be a tedious work to change all file readers just to change that. Maybe you can create a class that modifies BinaryReader's single reading function?

[libertyernie]

Looks like the only file that uses a BinaryReader is PMDModel.cs, for PMD model import/export. (It actually reads the bytes and then uses BitConverter to create a float.) Does that sound right?

[AtlasOmegaAlpha]

Yes, that's how it should be. Can you find out how are DAE files read? I assume it uses a XML reader

[libertyernie]

It does (ColladaParser.cs.)

Does the problem you describe happen with any format of models, or only certain formats?

[AtlasOmegaAlpha]

I only tested with complex DAE models imported into MDL0 so far; other programs which use float format for the model data handle them properly

[libertyernie]

OK, so I don't think PMDModel would be the issue.

Could you post a link to a DAE model for testing?

[AtlasOmegaAlpha]

This one should be a clear example: https://mega.nz/#!17B31SbK!mbhzzPme7cMO5JxyLKWli3h7b7OqKBCTMqR5fwA_gs0

It's an extreme case because the model is really high poly, but other 3D tools don't seem to break its normals as BrawlBox does.

Here's a more usual example, which is a track model from a Wii game: https://mega.nz/#!0yQFDCTY!B6rOdVqnObN0N-8fss2EZ_nCAIKboXa6GvVW9dtemlU

In this one, you can notice some faces are split, creating more vertices, and slighly moved from each other. Zoomed in screenshot of two separated vertices that should be welded in the same position: http://prntscr.com/ku3sby

[libertyernie]

I'm not sure I have enough experience in this area to be able to fix a bug like this without breaking something else. Maybe someone else should tackle this...