Jump to content

  • Log In with Google      Sign In   
  • Create Account


#ActualTom KQT

Posted 03 October 2012 - 12:36 AM

binary formats are usually the fastest, and also take the least space on disk, but are comparatively much harder to parse.

Hm, I would say the exact opposite (talking about the parsing part).

Text formats are easier for human to read and understand, but reading them from a code is harder because you must do some string processing, finding keywords etc. and last but not least - converting textual representations of numbers into actual numbers.

Binary formats are nearly impossible for a human to read. But for a computer code it's usually very easy. Specifically when talking about 3D mesh formats, there isn't much surplus information in the binary files, all you need to know is that for example the first 4 bytes represent the number of faces, then you have 3*4 bytes for a normal vector, then 3*3*4 bytes for 3 vertices of a face etc etc etc (simplified example of a binary stl).
And when reading those bytes, for example 12 bytes of a normal vector, you can directly use this data to fill your vector structure in the code, no processing needed, just file.read or memcpy.

The best format for a game that is loading models on the fly will be a custom one that maps directly to it's internal data structures. Otherwise, it doesn't matter.

My vote for this. There's nothing better than being able to fill your whole vertex buffer by a single file.read call, reading (vertexsize * vertexcount) bytes.

#2Tom KQT

Posted 03 October 2012 - 12:35 AM

binary formats are usually the fastest, and also take the least space on disk, but are comparatively much harder to parse.

Hm, I would say the exact opposite (talking about the parsing part).

Text formats are easier for human to read and understand, but reading them from a code is harder because you must do some string processing, finding keywords etc. and last but not least - converting textual representations of numbers into actual numbers.

Binary formats are nearly impossible for a human to read. But for a computer code it's usually very easy. Specifically when talking about 3D mesh formats, there isn't much surplus information in the binary files, all you need to know is that for example the first 4 bytes represent the number of faces, then you have 3*4 bytes for a normal vector, then 3*3*4 bytes for 3 vertices or a face etc etc etc (simplified example of a binary stl).
And when reading those bytes, for example 12 bytes of a normal vector, you can directly use this data to fill your vector structure in the code, no processing needed, just file.read or memcpy.

The best format for a game that is loading models on the fly will be a custom one that maps directly to it's internal data structures. Otherwise, it doesn't matter.

My vote for this. There's nothing better than being able to fill your whole vertex buffer by a single file.read call, reading (vertexsize * vertexcount) bytes.

#1Tom KQT

Posted 03 October 2012 - 12:33 AM

binary formats are usually the fastest, and also take the least space on disk, but are comparatively much harder to parse.

Hm, I would say the exact opposite (talking about the parsing part).

Text formats are easier for human to read and understand, but reading them from a code is harder because you must do some string processing, finding keywords etc. and last but not least - converting textual representations of numbers into actual numbers.

Binary formats are nearly impossible for a human to read. But for a computer code it's usually very easy. Specifically when talking about 3D mesh formats, there isn't much surplus information in the binary files, all you need to know is that for example the first 4 bytes represent the number of faces, then you have 3*4 bytes for a normal vector, then 3*3*4 bytes for 3 vertices or a face etc etc etc (simplified example of a binary stl).
And when reading those bytes, for example 12 bytes of a normal vector, you can directly use this data to fill your vector structure in the code, no processing needed, just file.read or memcpy.

PARTNERS