Melee Arcive Viewer (MAV) in development project.

[Tcll]

hey Milun :O

I thought of a better way to explain the face hex...
you only highlighted the first parts... not the whole part
here is your code:
98 00 7B ;descriptor
03 15 03 15 01 A6 ;V-Point X face 1
03 16 03 16 01 A7 ;V-Point Y face 1
03 17 03 17 01 A8 ;V-Point Z face 1
03 16 03 16 01 A7 ;V-Point X face 2
03 10 03 10 01 A1 ;V-Point Y face 2
03 16 03 16 01 A7 ;(V-Point X face 3)
03 13 03 13 01 A4 ;V-Point Z face 2
03 15 03 15 01 A6 ;and so on...
03 12 03 12 01 A3
03 11 03 11 01 A2
03 12 03 12 01 A3
00 A8 00 A8 01 A6
03 13 03 13 01 A4
00 A9 00 A9 01 A7
00 72 00 72 01 A1
00 A9 00 A9 01 A7
00 E1 00 E1 01 A8
00 A8 00 A8 01 A6
00 DE 00 DE 01 A5
03 11 03 11 01 A2
00 DE 00 DE 01 A5
00 DF 00 DF 01 61
00 E1 00 E1 01 A8
00 E0 00 E0 01 62
00 4B 00 4B 01 5F
00 E0 00 E0 01 62
01 19 01 19 01 63
00 DF 00 DF 01 61
01 16 01 16 01 60
03 11 03 11 01 A2
01 16 01 16 01 60
01 17 01 17 01 2A
01 19 01 19 01 63
01 18 01 18 01 2B
00 36 00 36 01 28
01 18 01 18 01 2B
01 4F 01 4F 01 2C
01 17 01 17 01 2A
01 4C 01 4C 01 29
03 11 03 ...unfinished
when you put the data differently... you get different ideas...
notice how the 5th column is nothing but 01...

and don't ignor that duplicate data...
it basically means 2 face verts (in the same spot) that arn't connected.

dont quote me on this however...
this is pretty much just a really good guess...

All data means something. (a good rule to go by)

[Tcll]

To Milun:
I might be able to help you out with the UV's...

so let's see...
I know they only have an x,y axis
and I know that they're farmatted the same as verts

but what I don't know is how they're linked to the mesh

any ideas??

[Milun]

Well I'm back, and I have to say how extremely impressed I am with your edge data discovery. I was tearing my hair out trying to figure it out. Oh, and I'm sorry, but I can't help you with the textures, mainly because of how pre-occupied I was with finding the edges, but I'd wager that the last value in the above column has something to do with it, but I'd have to research it to be sure.

[Tcll]

lol
that's ok...
I'll try to find it when I can...

btw: your vert data helped me out alot.
here's a first run sceenshot of my test prog in blender

click on the image for a larger shot.
see if you can guess who it is before looking at any data or clicking on the image.

but yea... you can see my prob...
it seems alot of the Z axis likes to go to 0 before being exported
and btw... this isn't the original import either

here is my 1st test obj
Download

[Milun]

Well, from your example I downloaded, I can't exactly tell what's the problem with the Z values, but I see you forgot the:

"If the number is smaller or equal to 127, then it stays the same.
If the number is larger than 127, then 256 must be subtracted."

That would explain why it was divided into four sections, but I still don't know what's wrong with the Z, my advice is to check your code on a .ty file (trophy) such as the TyEgg.dat.

Trophies are easier:



Edit: Hmmm... there's also this problem:



And incidentally, this is the best I've ever accomplished (shown in steps):


Every face hex is in the leftmost two columns (it's for the Mario trophy btw), but notice these ones skip less hex than the one you showed.

[Tcll]

actually...
I didn't forget that.

the original numbers are over 400 so I did subtract the 256 value from them...
but was I supposed to go back and redo it??
if the numbers are still bigger than 127...

as of your problem...
it's got me stumped... O.o

however I'm not there yet
I'm still on the verts...

EDIT:
I know what's wrong with mine however...
X is rotated by 90 so that turns Y into Z
so that means the prob lies within the Y convertor

My program converts the raw data into hex before converting that into a decimal value.
this means my prob is the raw to hex conversion on the Y values
or tmp3 and tmp4
(the vars that hold those values)

this is my final format
vert = "v "+tmp1+"."+tmp2+" "+tmp3+"."+tmp4+" "+tmp5+"."+tmp6
this is how I have it formatted to output the obj decimals

[revel8n]

hey Milun :O

I thought of a better way to explain the face hex...
you only highlighted the first parts... not the whole part
here is your code:
98 00 7B ;descriptor
03 15 03 15 01 A6 ;V-Point X face 1
03 16 03 16 01 A7 ;V-Point Y face 1

First part should be interpreted like this:

98 00 7B ; primitive flags, index count

primitiveFlags & 0xF8

0xB8 // points
0xA8 // lines
0xB0 // line strip
0x90 // triangles
0x98 // triangle strip
0xA0 // triangle fan
0x80 // quads

The index data start with a byte value that determines the primitive type to be rendered, then a 2-byte value that determines the number of index groups that follow. Unfortunately this is where things can get trick, because not all models will have normals, and untextured models may not have uvs, or if a model ever has multiple textures there could be multiple uv indices. As such there may not always be an index group size of 3 like is being assumed here (vertex, normal, uv index values per indexed vertex in this case i am assuming from what has been shown). Also for models that have less than 256 values to index, it is not always guaranteed that index values will even be 2 bytes. Just something to be aware of if you see some files that don't seem to match the pattern you are adhering to now.

03 15 03 15 01 A6 ;Vertex 1 (vertex index, normal index, uv index) *assuming i have the order correct

After count number of groups, the sequence may repeat with another primitive type byte and 16-bit index count and so on. May help you to look up some info on how the gamecube/wii send data for rendering to the graphics card.

Hope that helps.

[Tcll]

KK... O.o
as I said "Don't quote me on that" XD
I thought I might have been off...
but yea..., I'm going to be looking back on this.
thanks

I do wish Jahra!n was here...
------------------------------------------------------------------------------------------

btw Milun...

I tried out your stratagy of putting the hex data from HxD into a txt.

it worked out better than my stratagy...
but I couldn't help but notice how none of the verts were in the right place

the model was a complete mess
they were off by values of at least 0.1 to 0.3

[revel8n]

Oh, also, make sure you are treating values as signed when necessary.

To take an example from Milun's page:
(F5 50 becomes 62800) as unsigned is very different when compared to
(F5 50 becomes -2736) when treated as a signed value.

[Tcll]

Oh, also, make sure you are treating values as signed when necessary.

To take an example from Milun's page:
(F5 50 becomes 62800) as unsigned is very different when compared to
(F5 50 becomes -2736) when treated as a signed value.

ok...
being an amature py programmer <XD
umm... I don,t quite get the differance between them...

or should I say, I'm not quite sure how to do that...