unsigned values do not allow for negative numbers, where as signed values do. so an unsigned 16-bit value would range from +0..+65535, where as a signed 16-bit value would range from -32768...+32767. "Technically" negative numbers would represent the upper half of the unsigned range if converted directly, which is why if you treat a signed number as unsigned you appear to get a very large value. You could visualize the range value wise as being +0...+65535 for unsigned and signed as +0...+32767,-32768...-1 (i.e. 0x7FFF == +32767 and 0x8000 == -32768, 0xFFFF == -1, and so on.)

Don't know how python handles this. but after a quick search it appears pythons conversion types are already signed, but i don't know what your conversion code looks like.

in c/c++ it would just be the difference between 'signed short' and 'unsigned short'.

Last edited by revel8n; February 10th, 2010 at 16:25.
Reason: added slightly more info

use this in idle and copy the data from the interpreter.Be sure to get rid of the spaces in the txt fileinstead of F5 50it should be F550
after that...
just wait for the error at the end of the conversion.
the error means it's finished.

"\n" is for newline - which is similar to what pressing enter would do when typing, yes.

struct was necessary for accessing the pack and unpack functionality for python. i looked these things up on google solely to achieve the results i was looking for. Cannot really tell you too much more about python related functionality as i am a c/c++ programmer. But basically the 'H' used in pack converts things to unsigned short (16-bit) values while the 'h' format specifier used with unpack treats the values as signed short values. Then i just convert the values to float so that i can scale the values down by 100 (* 0.01). Technically the values don't really need scaling, and if things come out smaller than you would like you can just change the scale value i use, but best to keep them consistent if you are going to be converting multiple files.

The faces work as i described earlier. The first value in a group of indices is the vertex index, then you may or may not have index values for normals and uv coordinates. The data repeats this pattern for the number of indices specified after the primitive flags. To determine how to build faces you have to look at the primitive type value you get from the primitive flags (triangles means every 3 index groups defines an individual face, and so on). If you are not accustomed to the methods used to render things in real-time graphics may need to look into that for some useful information (both opengl and direct3d documentation have information on interpreting the various primitive types).

Finding the data in the first place can be a little tricky if you are doing it by hand, although it is easy to pick out once you have found the right area in the file. i am looking into some things i have been trying to decipher to see if it holds some of the relevant data i am seeking. i use 010 Editor (www.sweetscape.com) and i may have some things that would make it even easier to see the relevant data through the use of their binary template format. Will have to see what i can dig up.

Also note that because gamecube/wii api design allows for indexing vertices, normals, and uv coordinates separately, it is quite likely you will need to have a prepass that either converts things to triangle lists (duplicating vertices and other values as necessary depending on the support of your intended application or renderer api).

Let me know what other questions you may have, and i will see what information i can provide.

and I kinda mis-stated myself...
I ment how do I decipher the face data??
I would like to know the math on how to if you know...

im tired of reading through numberous docs that dont tell me exactly what I need to know...
IDK...
maybe it's just my fault...
maybe I do have what I need to know...
but I'm just not looking at it correctly.