Page 3 of 5

Posted: Wed Sep 10, 2008 3:11 pm
by eman7613
@Whaat
if your willing to wait a day or two i could probably write one for you.

@Ono
so will we get the new igm specs soon too?

Posted: Wed Sep 10, 2008 3:35 pm
by OnoSendai
eman7613: .igm hasn't changed, do you mean new .igi?

Posted: Wed Sep 10, 2008 3:36 pm
by OnoSendai
Whaat wrote:ok. That helps a bit. Do I need to create an IndigoMesh class in Ruby that is identical to the C++ class? And then, do I have to figure out how to write the information contained in the IndigoMesh object to a file using the same template as the one that you have provided? :?
There's nothing C++-specific in the format. I'll try and get round to writing a quick summary of the format that isn't just C++ code.

Posted: Wed Sep 10, 2008 4:12 pm
by eman7613
OnoSendai wrote:eman7613: .igm hasn't changed, do you mean new .igi?
yes >.< im so horrible with these things called names and acronyms, sometimes i amaze myself that i mange to accomplish things at all

Posted: Thu Jan 08, 2009 10:39 pm
by suvakas
I finally gave a try to implement it in maxscript, but I failed miserably :)
I keep geting "String too long" error.
I'm assuming, that it has something to do with how I export the material names on line:
String used_materials[num_used_materials]

Currently I'm just writing out a single string with material name, but obviously it doesn't work like that. Can someone with more brains explain how to write that line into binary file in non C++ language? Or what's behind that line? An array of mat name strings?

Posted: Fri Jan 09, 2009 4:51 am
by CTZn
An array of mat name strings?
That's how I understand the notation. An array of predetermined size (the number of materials used by the mesh), indexing strings (their names).

Hope that helps, can't do more since I'm at much trivial things :?

Posted: Mon Jan 12, 2009 9:48 am
by suvakas
Thanks for your input CTZn.
I think I got the strings working, but now I'm stuck with the Vec3f lines.
I now get Bad allocation error.
Probably not exporting the vectors correctly with maxscript.
Ono is not making it easy for us :lol:

Posted: Mon Jan 12, 2009 12:28 pm
by OnoSendai
suvakas wrote:I finally gave a try to implement it in maxscript, but I failed miserably :)
I keep geting "String too long" error.
I'm assuming, that it has something to do with how I export the material names on line:
String used_materials[num_used_materials]

Currently I'm just writing out a single string with material name, but obviously it doesn't work like that. Can someone with more brains explain how to write that line into binary file in non C++ language? Or what's behind that line? An array of mat name strings?
String used_materials[num_used_materials]
simply means a contiguous sequence of num_used_materials Strings.

Posted: Mon Jan 12, 2009 8:13 pm
by suvakas
OnoSendai wrote: String used_materials[num_used_materials]
simply means a contiguous sequence of num_used_materials Strings.
Thanks, I think I figured that out.
You also have to export the length of the string, right?
So for example for material named "matA" I'm exporting:

uint32 4;
string "matA"

Is that correct?

What about the vector3 type?
Is it just enough when I export three floats in a row?

Posted: Mon Jan 12, 2009 8:24 pm
by fused
suvakas wrote:Is it just enough when I export three floats in a row?
i think that should be ok.

Posted: Mon Jan 12, 2009 11:42 pm
by suvakas
Thanks guys, I think I got it working.
And I like the results 8)

Exporting 2.5 million poly model took 25.984 secs using Maxscript (script is a lot slower than C code) and the file size was 112 MB.

Exporting the same model to obj format (Max native export plugin written in C) took 45.781 secs and the file size was 278 MB.

So the igmesh is half as fast and has more than a half smaller file size.
I'm planning to switch to igmesh format and dump all the "old" formats like *.3ds and *.obj.

Posted: Tue Jan 13, 2009 1:13 am
by CTZn
Congrats suv !

:cry:

Posted: Tue Jan 13, 2009 11:34 am
by suvakas
There is still one thing I don't get.
Does this format support multiple UV mapping channels?
If yes, then how and what's the limitation?

For example is this supported when num_uv_mappings = 2 and num_uv_pairs = 561 on the 1st UV channel and num_uv_pairs = 588 on 2nd UV channel ?
So that on different UV channels there could be different amount of UV pairs? It seems to me, that it needs to have the same amount on UV's on all the channels. Like 2 x 561 or 2 x 588, but not both at the same time. Is it so?

Posted: Tue Jan 13, 2009 12:09 pm
by OnoSendai
Yes, multiple UV sets are supported.
Since the UV pairs are interleaved in the uv_pairs array, just use the largest of the num_uv_pairs to calculate the length of the array.

Posted: Wed Jan 14, 2009 1:44 am
by suvakas
In Max I have 561 uv pairs on channel 1 and 588 pairs on channel 2.
Is the num_uv_pairs for indigo 2 * 588 ?
Should I export it like this:

num_uv_mappings = 2
num_uv_pairs = 1176
num_uv_pairs[1...1176]

[edit]
I'm getting messed up uv coordinates when doing like that, so it's probably wrong. Ono, could you explain the logic behind the multiple uv's a bit. I mean how it works?