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

A forum for exporter development discussion.
User avatar
OnoSendai
Developer
Posts: 6241
Joined: Sat May 20, 2006 6:16 pm
Location: Wellington, NZ
Contact:

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

Post by OnoSendai » Thu Sep 04, 2008 1:23 pm

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]

Attachments
IndigoMesh.zip
(2.23 KiB) Downloaded 768 times
Last edited by OnoSendai on Wed Sep 10, 2008 10:58 pm, edited 3 times in total.

User avatar
CTZn
Posts: 7240
Joined: Thu Nov 16, 2006 4:34 pm
Location: Paris, France

Post by CTZn » Thu Sep 04, 2008 1:31 pm

Quads, n-gons ?
obsolete asset

User avatar
OnoSendai
Developer
Posts: 6241
Joined: Sat May 20, 2006 6:16 pm
Location: Wellington, NZ
Contact:

Post by OnoSendai » Thu Sep 04, 2008 1:33 pm

CTZn wrote:Quads, n-gons ?
Tris only currently. Quads might be a good idea to make exporting faster.

User avatar
CTZn
Posts: 7240
Joined: Thu Nov 16, 2006 4:34 pm
Location: Paris, France

Post by CTZn » Thu Sep 04, 2008 1:46 pm

I put an option on quads, thanks !
obsolete asset

Big Fan
Posts: 745
Joined: Tue Oct 17, 2006 9:37 am
Location: Nelson NZ

Post by Big Fan » Thu Sep 04, 2008 4:32 pm

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.

User avatar
fused
Developer
Posts: 3648
Joined: Fri Sep 22, 2006 7:19 am
Location: Berlin, Germany
3D Software: Cinema 4D

Post by fused » Thu Sep 04, 2008 6:52 pm

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

User avatar
dougal2
Developer
Posts: 2532
Joined: Wed Nov 15, 2006 8:17 am
Location: South London

Post by dougal2 » Thu Sep 04, 2008 10:03 pm

Does the world really need another 3D file format ?

User avatar
OnoSendai
Developer
Posts: 6241
Joined: Sat May 20, 2006 6:16 pm
Location: Wellington, NZ
Contact:

Post by OnoSendai » Thu Sep 04, 2008 10:31 pm

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.

User avatar
suvakas
3rd Place Winner
Posts: 2613
Joined: Mon Sep 04, 2006 11:08 pm
Location: Estonia
Contact:

Post by suvakas » Fri Sep 05, 2008 12:46 am

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 ?

User avatar
dougal2
Developer
Posts: 2532
Joined: Wed Nov 15, 2006 8:17 am
Location: South London

Post by dougal2 » Fri Sep 05, 2008 1:05 am

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.

User avatar
fused
Developer
Posts: 3648
Joined: Fri Sep 22, 2006 7:19 am
Location: Berlin, Germany
3D Software: Cinema 4D

Post by fused » Fri Sep 05, 2008 1:52 am

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

User avatar
suvakas
3rd Place Winner
Posts: 2613
Joined: Mon Sep 04, 2006 11:08 pm
Location: Estonia
Contact:

Post by suvakas » Fri Sep 05, 2008 3:36 am

Thanks for the logical explanation, fused.
Makes sense now.

User avatar
CTZn
Posts: 7240
Joined: Thu Nov 16, 2006 4:34 pm
Location: Paris, France

Post by CTZn » Fri Sep 05, 2008 4:17 am

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).
obsolete asset

User avatar
dougal2
Developer
Posts: 2532
Joined: Wed Nov 15, 2006 8:17 am
Location: South London

Post by dougal2 » Fri Sep 05, 2008 4:48 am

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

User avatar
rgigante
Posts: 326
Joined: Wed Jun 28, 2006 6:46 am
Location: Italy

Post by rgigante » Fri Sep 05, 2008 10:13 pm

Great functionality by my side.... geometry caching could be reality now!


Thanks Ono

Post Reply
66 posts

Who is online

Users browsing this forum: No registered users and 4 guests