I'm trying to write a maya exporter and everything works fine now except that my exporter writes 208879416 for the num of indices which is incorrect(i only exported a cube, so 36 should be right). I have a vector of shorts for my indices and i get the dwNumIndices by calling DWORD(VertexIndices.size()).Now my first thought was that i actually filled the index vector with nonsense data...but the strange thing is that that loop: for(int l=0;l<VertexIndices.size();l++) { std::vector<short>::pointer ptr = &VertexIndices[0]; ofs.write(reinterpret_cast<char *>(ptr),sizeof(short)*VertexIndices.size()); //ok i think i can use sizeof(short) here } is really executed 36 times like it should thus something has to be wrong with the conversion to the type that vector.size() (i haven't figured out which it is...it says something like size_type...) to DWORD, but i don't know what. Can somebody tell me what's wrong with that conversion? Edit: oh i think i don't need that loop...because i export all indices with one ofs.write...is that correct? Edit2: ok that is correct...but that still doesn't solve my problem... btw the debugger also says that numIndices is 208809144 if i set numIndices manually to 36...i don't know where this number comes from regards, m4gnus [Edited by - m4gnus on June 21, 2005 11:22:30 AM]

ok now i'm totally confused...the numindices just seem to be the crap that is in there if you don't assign a value...but IndexChunkHeader.dwNumIndices=NumIndices; doesn't change dwNumIndices but dwIndexSize (at least the debugger says that) which doesn't make any sense to me.

my typedef of IndexChunkHeader:


i don't know how this can happen...


regards,
m4gnus

From your second problem description, I smell some kind of difference between the executed code and the code which is executed. Are you sure you are debugging the right executable? If yes then maybe you should try to rebuilt it.

vector<T>::size_type is defined as an implementation defined unsigned integral type by the C++ standard (table 32 + §23.2.4). MS VC++ implements it as a size_t (which is probably a unsigned long if you limit yourself to the 32 bit plaftorm or an unsigned __int64 if you enable 64 bit compiling).

And you are right, you don't need the loop.

HTH,

ahh thx...i'm quite sure i debug the right code...i open my code and press f5 and i don't think that this would debug something different than what's opened in the editor...the exporter works now for boxes...i think it even worked before i posted this, but the camera was inside the box and backface culling was turned on...but now i get a buffer overrun error when i extrude faces of the box, but other shapes work ok with more faces like cones. But somehow not all cones work. i tried increasing the axis subdivisions and it worked fine with 20 but when i turned it to 100 maya crashed(about 1min nothing happened,maya didn't react then i got something with privileg read[or sth similar] 0xb0000000 or sth like that).

the whole vector.size() stuff just seems to be wrong displayed by the debugger...

regards,
m4gnus

Quote:Original post by m4gnus
ahh thx...i'm quite sure i debug the right code...i open my code and press f5 and i don't think that this would debug something different than what's opened in the editor...

It can. It executes the exe that is pointed by {project properties\debugging\command}. It can be changed rater easily to debug - for example - a DLL using another program. Which ay be your case (I don't know the structure of a maya exporter but... isn't launched by maya?)

Quote:the exporter works now for boxes...i think it even worked before i posted this, but the camera was inside the box and backface culling was turned on...but now i get a buffer overrun error when i extrude faces of the box, but other shapes work ok with more faces like cones. But somehow not all cones work. i tried increasing the axis subdivisions and it worked fine with 20 but when i turned it to 100 maya crashed(about 1min nothing happened,maya didn't react then i got something with privileg read[or sth similar] 0xb0000000 or sth like that).

the whole vector.size() stuff just seems to be wrong displayed by the debugger...

regards,
m4gnus

There is still something weird :P

Regards,

yes it is a dll used by maya...but it always rebuilds it when i change sth. so to me it seems like it's debugging the right dll.

the debugger spits out this error message "Unhandled exception at 0x77896be3 in maya.exe: 0xC0000005: Access violation writing location 0x00430ff0." when i try to export a triangulated cube with the resolution 5x5x5 or a cone with 100axis subdivisions...

Seems to me like a pointer is messed up or something is trying to acces an array-like thing with a too large index....


regards,
m4gnus

i read in a recent thread that you shouldn't write/read whole structs directly into/from a file...as i understood it right i should just write the members of the structs like this:
instead of

ofs.write(reinterpret_cast<char*>Vertex,sizeof(Vertex));

i should do:
ofs.write(reinterpret_cast<char*>Vertex.x,sizeof(float));
ofs.write(reinterpret_cast<char*>Vertex.y,sizeof(float));
ofs.write(reinterpret_cast<char*>Vertex.z,sizeof(float));

is that correct? Coudl that cause the problem?

regards,
m4gnus

Quote:Original post by m4gnus
i read in a recent thread that you shouldn't write/read whole structs directly into/from a file...as i understood it right i should just write the members of the structs like this:
instead of

ofs.write(reinterpret_cast<char*>Vertex,sizeof(Vertex));

i should do:
ofs.write(reinterpret_cast<char*>Vertex.x,sizeof(float));
ofs.write(reinterpret_cast<char*>Vertex.y,sizeof(float));
ofs.write(reinterpret_cast<char*>Vertex.z,sizeof(float));

is that correct? Coudl that cause the problem?

regards,
m4gnus

Both are correct (but the second is better), and since it only reads the data, it cannot be the source of your problem. The problem with writing/reading a whole struct is that padding may change from one compiler to another, and padding might change the size of the structure and the position of each structure member.

To be sure that you are executing the right plugin, you can add a message box at the beginning of the plugin. If it shows, then it's ok. If not, then verify the plugin path, the path where you compile and the path where maya tries to find the plugin.

Regards,

ok i added a messageboy and it poped up so there's no problem. But i don't know how i should debug these acces errors because the debugger says they occur somewhere in crt0dat.c ...

regards,
m4gnus

Quote:Original post by m4gnus
ok i added a messageboy and it poped up so there's no problem. But i don't know how i should debug these acces errors because the debugger says they occur somewhere in crt0dat.c ...

regards,
m4gnus

Good news about the messagebox (no, it isn't a boy with a message): no You and I are sure that it is not the source of your problem ;)

Problems in crt0dat.c are more than likely configuration-related. You should check the maya documentation to see whether you are using the correct settings and libraries to build your plugin.

Regards,