Page 1 of 5

Indigo Binary Mesh (.igmesh) format with source code.

Posted: Thu Sep 04, 2008 1:23 pm
by OnoSendai
Reading .igmesh files is supported as of Indigo v1.1.10.

You can use this code directly in exporters, or you can read it to get an idea of the file format.

Feedback on the file format / code welcome.

EDIT: some pseudocode / layout of the format:

Code: Select all


// uint32 is an unsigned 32 bit integer
// float is a single precision (32 bit) IEEE 754 floating point number.
// Byte order is little endian.
// bleh a[9] means that 'a' is an array of 9 'bleh's.

// Some composite structures as used below:
class Triangle
{
	uint32 vertex_indices[3];
	uint32 uv_indices[3];
	uint32 tri_mat_index;
}

// ASCII string
class String
{
	uint32 size // max length 1024
	char8 data[size] // not null terminated
}

class UVSetExposition
{
	String uv_set_name
	uint32 uv_set_index
}


// The actual format:
uint32 magic number // should be 5456751
uint32 format_version // 1
uint32 num_uv_mappings

uint32 num_used_materials
String used_materials[num_used_materials]

uint32 num_uv_set_expositions
UVSetExposition uv_set_expositions[num_uv_set_expositions]

uint32 num_vert_positions
Vec3f vert_positions[num_vert_positions]

uint32 num_vert_normals // should either be 0 or equal to num_vert_positions
Vec3f vert_normals[num_vert_normals]

uint32 num_uv_pairs
Vec2f uv_pairs[num_uv_pairs]

uint32 num_triangles
Triangle triangles[num_triangles]


Posted: Thu Sep 04, 2008 1:31 pm
by CTZn
Quads, n-gons ?

Posted: Thu Sep 04, 2008 1:33 pm
by OnoSendai
CTZn wrote:Quads, n-gons ?
Tris only currently. Quads might be a good idea to make exporting faster.

Posted: Thu Sep 04, 2008 1:46 pm
by CTZn
I put an option on quads, thanks !

Posted: Thu Sep 04, 2008 4:32 pm
by Big Fan
sorry wont be doing it
already scripting updates are really too much for my skill level and takes too much of my time (if you can work out what the hell is going on from the docs anyway)
the script I use is old and convoluted and messy but comfortable like a favourite old jersey -I dont want to keep overhauling it for stuff I dont really need for my purposes
still havent done embedded2 stuff -possibly my next mission when time permits - still thinking of practical UI improvements and such...
wont be doing read of igm stuff either, sorry.
sorry, sorry, no.

smartden may want to but I'll bow out of doing generic script updates now with this.
- even as a good samaritan to the community while he is on holiday.

Posted: Thu Sep 04, 2008 6:52 pm
by fused
finally had a look at it and i like it.

im glad to see you moving away from mesh defiitions in text formats. this plus giving us the code = big step in the right direction.
ill implement it for sure.

cant comment much on the code as youre by far the better coder, all i can say is that its well structured, understandable (pretty much self explaining, but you could have been a bit more generous with comments, hehe) and i gained knowledge from it (thanks!).

cheers

Posted: Thu Sep 04, 2008 10:03 pm
by dougal2
Does the world really need another 3D file format ?

Posted: Thu Sep 04, 2008 10:31 pm
by OnoSendai
dougal2 wrote:Does the world really need another 3D file format ?
hehe, perhaps not.
I regard this format as more of a binary encoding of the existing Indigo XML mesh format, than a new format, however.

Posted: Fri Sep 05, 2008 12:46 am
by suvakas
Sry, if it's a stupid q 8) ( I'm still learning c ), but what's the advantage of the binary format? Is it faster than writing/reading a text file ?

Posted: Fri Sep 05, 2008 1:05 am
by dougal2
I guess so, and I should think it will be faster to read and write.

However, it's not something that's going to be easy (or perhaps even possible) to implement in MtI. Probaby can be done as a python plugin, but probably not using pure MEL.

With all these recent mesh and material changes, it's *almost* worth starting MtI again from scratch... however that's a massive amount of work to do in one go. been there, done that already, don't have the time to do it again.

Posted: Fri Sep 05, 2008 1:52 am
by fused
it will be faster and quite a lot smaller.

heres an example:
in an ascii txt file you can represent a small unsigned integer (0-255) with three chars, each of them takes 7 bit(or 8 ). in a binary file you can represent a small unsigned integer with one byte(8bit). so with this example your file would be just one third of the size of a text file.

edit:
doug, just because of some xml changes you consider a complete rewrite? o.O

Posted: Fri Sep 05, 2008 3:36 am
by suvakas
Thanks for the logical explanation, fused.
Makes sense now.

Posted: Fri Sep 05, 2008 4:17 am
by CTZn
been there, done that already, don't have the time to do it again.
You did your part or more, thanks for that !

Python would definitly be prefered to mel, wich would be a non-sense here. There are various py libraries able to read/write binary formats upon description, I know that but I'm the lazy noob guy.

fused: I think Dougal means that MtI would greatly benefit from a rewrite, since he wrote the luxMaya exporter he gained some experience ;)

Currently MtI is based both on Maya shaders and a dedicated monolithic (python) shader, that's a bit messy since you can't express all parameters using either... it's not clean nor finished (and worse since I was around).

Posted: Fri Sep 05, 2008 4:48 am
by dougal2
CTZn wrote: fused: I think Dougal means that MtI would greatly benefit from a rewrite,
yeah that's really what I meant. back when it was originally written purely in MEL, the xml to generate was simple enough that it worked quite well.
As things developed some stuff was easier to implement in python, and now with the binary format, some python processing is certainly necessary.

Now MtI is an odd mix of 2 languages, interacting in a kind of ad-hoc way, and I can see that it will probably only get worse.

Also, CTZn, things certainly haven't got worse since you worked on it. stop berating yourself.

anyway, I digress.
/OT

Posted: Fri Sep 05, 2008 10:13 pm
by rgigante
Great functionality by my side.... geometry caching could be reality now!


Thanks Ono