Indigo Binary Mesh (.igmesh) format with source code.
Damn I cant do simple multiplication. It should be 2.4 bytes. The approximate formula to calculate this for any number of bits is nbits*0.3 ex 8*0.3 = 2.4 bytes for a byte 4.8 bytes for a 16 bit number etc.
XML tags, line feeds, whitespace etc also adds overhead obviously.
Its dependant on the XML structure and other things but its rougly 5:1 overhead in the general case. The normal way of "fixing" this architecturally in a modern file format while still retaining size and the strength and flexibility of XML is to use zlib or similar to compress the XML stream. Good examples of this in practice is JARs, XPS (Vistas pdf "replacement") and Indigo files. It requires CAREFUL implementation and reading speed and size will still suffer a bit but not as bad as 5:1 size wise.
It's important to realize is that XML is really strong because
A) It can be manually typed in an editor
B) Its easily extended
C) Underlying architecture is easily understood by just reading documents written in the specification and understanding = engineering trust and engineering trust = something that gets used i.e. xml makes people want to use the product or platform
However. For "trivial" things that is well known prior art and that is highly unlikely to change over time XML is NOT the best choice. Examples of this is bitmaps, masses of raw data (audio, geometry)
Onos choice to go for a binary format here is a good choice and I hope I gave some of you a bit more insight into software architecture and data formats.
Im starting to babble here It's important stuff though.
/ D
XML tags, line feeds, whitespace etc also adds overhead obviously.
Its dependant on the XML structure and other things but its rougly 5:1 overhead in the general case. The normal way of "fixing" this architecturally in a modern file format while still retaining size and the strength and flexibility of XML is to use zlib or similar to compress the XML stream. Good examples of this in practice is JARs, XPS (Vistas pdf "replacement") and Indigo files. It requires CAREFUL implementation and reading speed and size will still suffer a bit but not as bad as 5:1 size wise.
It's important to realize is that XML is really strong because
A) It can be manually typed in an editor
B) Its easily extended
C) Underlying architecture is easily understood by just reading documents written in the specification and understanding = engineering trust and engineering trust = something that gets used i.e. xml makes people want to use the product or platform
However. For "trivial" things that is well known prior art and that is highly unlikely to change over time XML is NOT the best choice. Examples of this is bitmaps, masses of raw data (audio, geometry)
Onos choice to go for a binary format here is a good choice and I hope I gave some of you a bit more insight into software architecture and data formats.
Im starting to babble here It's important stuff though.
/ D
right. my words.Deus wrote:Onos choice to go for a binary format here is a good choice and I hope I gave some of you a bit more insight into software architecture and data formats.
i implemented it into cindigo and the results are quite impressive:
Code: Select all
Exported mesh: Buddah, 1085617 tris, 548494 vertices, 543717 uvs. Processing time: 3.125s. Total export time: 3.502s.
igmesh size: 45.6MB
Code: Select all
Exported mesh: Landscape, 3992000 tris, 1996002 vertices, 2000997 uvs. Processing time: 7.333s. Total export time: 8.698s.
igmesh size: 167MB
will export those to embedded_2 and post the results, too. for coparison.
results embedded_2:
Code: Select all
Exported mesh: Buddah, 1085617 tris, 548494 vertices, 543717 uvs. Total export time: 21.78s.
igs size(mesh element only): 153MB
Code: Select all
Exported mesh: Landscape, 3992000 tris, 1996002 vertices, 2000997 uvs. Total export time: 60.27s.
igs size(mesh element only): 429MB
Who is online
Users browsing this forum: No registered users and 1 guest