Melee dat format...

[zankyou]

Sure, but how does your program calculate how much space each mesh structure attribute takes up in the DAT for a single object?

When I parse the mesh data I get the total number of entries from that and just use the mesh array to figure out the stride. Im pretty sure the value given is unnecessary because it doesnt always match.

 

[Achilles1515]

Definitely something wrong with the model. But its possible that the image dimensions are not compatible. I remember reading about how dolphin could take dimensions of any kind while the wii cannot so it could be that this import was only meant for dolphin. Did you try hooded marth?

Hooded Marth works.

 

[Achilles1515]

Z zankyou Tcll
Mesh Structure Unknown Flag Research (0xC of mesh struct)

0x1000 Something with Influence Matrix Array Offset
0x2000 Something with Influence Matrix Array Offset
0x4000 = Mesh Cull_Outside
0x8000 = Mesh Cull_Inside

 

[zankyou]

Z zankyou Tcll
Mesh Structure Unknown Flag Research (0xC of mesh struct)

0x1000 Something with Influence Matrix Array Offset
0x2000 Something with Influence Matrix Array Offset
0x4000 = Mesh Cull_Outside
0x8000 = Mesh Cull_Inside

Ive actually been looking into this recently. 0x4000 is cull inside and 0x8000 is cull outside. I could be wrong but I think brawl reverses the values so at first I didnt think they were related. Also 0x0000 culls both. The thing Ive been trying to figure out for the longest, is what 0x2000 does. For characters you you have to OR the cullmode and 0x2000 or it wont load. For stages Ive never gotten 0xa000 to load.

 

[Achilles1515]

Ive actually been looking into this recently. 0x4000 is cull inside and 0x8000 is cull outside. I could be wrong but I think brawl reverses the values so at first I didnt think they were related. Also 0x0000 culls both. The thing Ive been trying to figure out for the longest, is what 0x2000 does. For characters you you have to OR the cullmode and 0x2000 or it wont load. For stages Ive never gotten 0xa000 to load.

What do you mean by Brawl reverses the values?

This is what I was going by:

 

[Tcll]

Should probably edit the wiki with that

Wish I had internet =3=

Nice find guys
though I do believe zankyou stumbled on that first. ;P

 

[zankyou]

Its still not completely understood for me at least. I feel like there has to be a cull none/all mode that I cant find. It would make since for making textures disappear and reappear easily. At first I thoguht it was ordered by powers of 2 until i started looking into 0xa000. And how the values are ORd for characters. That and I cant figure out why 0xa001 appears. When I was first trying to figure out what the second byte did I think I found a relationship to character animations for it. This is super inconclusive and doesnt seem to have much use so I wasnt going to say anything about it but for anyone who wants to experiment with the second byte. When I first started importing I was doing things over jigglypuff and if set to one the stage would bob with her, otherwise it would just face the same direction as her. However now that Ive started doing character imports I find that the characters bob despite the flag. So I dont really know what its for.

 

[Tcll]

Btw, something I thought I might mention here, since it's not exactly clear on this standard...

The objects ACTUALLY follow the multiple mesh per object standard.

After fixing up UMC to support this standard, since Blender already supports it, I decided to try ugeSetObject() per object and ugeSetMesh() per mesh, instead of the old method of ugeSetObject() per mesh...
low and behold, the object relation to each mesh is actually correct

By "correct" I mean Pichu's arms are on the same object, rather than on separate objects like in my old blender screenshot...

Not to mention there's far less objects to deal with.

 

[zankyou]

Achilles1515 Ive thought this for a while, but Im pretty sure theres more to shadows then simply the material flag.

 

[Tcll]

Look at how blender does material casting >_>
It's pretty much the same...

 

[zankyou]

Ive noticed the similarities between melee and blenders materials, but on default stages the shadow casting system isnt this bad.

Side note. When you get umc to the point where you want to get it to load stages, hit me up so that I can catchup you up.

 

[Tcll]

Heh, agreed...

And yea, it's slow progress...
I still need to port that section of the script, but yes I want to know :D

Patrick: really really badly

 

[Achilles1515]

Ive noticed the similarities between melee and blenders materials, but on default stages the shadow casting system isnt this bad.

Side note. When you get umc to the point where you want to get it to load stages, hit me up so that I can catchup you up.

Im basically at a dead end with shadows and solely rely on workarounds at this point, and chalking up the vanilla stage shadows "not being weird" to some special way the original 3D models were made. Idk. I guess there is still a little more to look into.

 

[zankyou]

Yeah its probably related to one of those pointers in the maphead. Ill play around with replacing material structs in those and see how it goes. Shadows never bothered me until this stage.
If I even get opengl to do what I want Ill be able to get a better look at whats going on.

 

[Achilles1515]

It's in vanilla too, btw. Just not all surfaces.

 

[zankyou]

It's in vanilla too, btw. Just not all surfaces.
View attachment 117754

View attachment 117757

Probably melee devs using magic to get around limitations. Though I have an idea for how to get a program to detect what part of the mesh needs shadows and what doesnt so splitting of meshes might not require 3ds max.

 

[Tiberious]

Is there any way this research could be turned to making some kind of converter for Melee fighter models? I've been watching Tcll's UMC, but it seems like every time he gets close, he just scraps everything and starts over. (Just a note: He was working on this before even Smash 4 was announced, much less released).

All I've ever wanted to see was someone to make a converter so Models Resource doesn't have to rely on 3D Printscreen grabs from T-pose codes, and we could have usable models with their actual joints and skin weighting available for all.

 

[Tcll]

Way ta hit me with the truth -.-

I know how you feel man, honestly...
but really I haven't been scrapping everything recently...
yes I had something earlier with dev4b, but that had to be scrapped...
I blame myself for not scrapping it sooner and just working on the perfected version years ago...

The problem with what I had was that it was getting too far out of hand to manage, and none of my group wanted to help me work on it...

Now things are sectioned properly to where it looks like a real program, rather than the mess of garbage I had earlier...

Not to mention the complete overhaul of the scripting interface enabling UMC to do far more than what I previously had, with far less, less confusing, code...

The things that continually throw UMC in the gutter are the very things it's designed to be:
- universal (this simple word has an extremely complex implementation)
- noobishly simple (reimplementing current standards with far more common sense than anything ever conceived)
- intuitive (the pick-up must be simple enough to understand)

I could go on, but not on this phone...

Now regarding a simple converter, I'm not opposed to anyone using my work, in fact I encourage it, but I do get tired of being the only one who seems to be doing anything significant towards a simple converter...
(My converter is anything but simple when developing it)

Trust me, you have no idea how bad I want to make a release, but I just simply can't release this until it actually does what everyone wants.
and making that happen is multitudes of levels easier said than done...

And my lifestyle isn't helping anything either...
I'm really not fit for what I'm doing.

I'd like to try to set something up to better my position, but I need a secure internet connection before I can even get close to anything there, such as a PayPal account with a private email...

So yea man, things are very grim for me :/

 

[zankyou]

Is there any way this research could be turned to making some kind of converter for Melee fighter models? I've been watching Tcll's UMC, but it seems like every time he gets close, he just scraps everything and starts over. (Just a note: He was working on this before even Smash 4 was announced, much less released).

All I've ever wanted to see was someone to make a converter so Models Resource doesn't have to rely on 3D Printscreen grabs from T-pose codes, and we could have usable models with their actual joints and skin weighting available for all.

This thread is more about the unknowns in the dat file. Tcll has documented the info needed to export the models a long time ago though some of the flags will definitely make the export more accurate. If you understand the model format you want to export it in there shouldnt really be anything stopping you.

 

[Tcll]

Z zankyou You're not telling him to code, right??

Granted, that is his best option, since he definitely has the ambition he needs...

 

[zankyou]

Z zankyou You're not telling him to code, right??

Granted, that is his best option, since he definitely has the ambition he needs...

Not him in particular. Just anyone who wants something like that. I can only imagine how long it would have been if I waited for someone else to do model imports from brawl to melee.

 

[Achilles1515]

Z zankyou DRGN

Found the official GXTexGenSrc enums (flag word @ 0x0C of the Texture Structure)

typedef enum _GXTexGenSrc
{
  GX_TG_POS = 0,
  GX_TG_NRM,
  GX_TG_BINRM,
  GX_TG_TANGENT,
  GX_TG_TEX0,
  GX_TG_TEX1,
  GX_TG_TEX2,
  GX_TG_TEX3,
  GX_TG_TEX4,
  GX_TG_TEX5,
  GX_TG_TEX6,
  GX_TG_TEX7,
  GX_TG_TEXCOORD0,
  GX_TG_TEXCOORD1,
  GX_TG_TEXCOORD2,
  GX_TG_TEXCOORD3,
  GX_TG_TEXCOORD4,
  GX_TG_TEXCOORD5,
  GX_TG_TEXCOORD6,
  GX_TG_COLOR0,
  GX_TG_COLOR1

} GXTexGenSrc;

 

[zankyou]

Z zankyou DRGN

Found the official GXTexGenSrc enums (flag word @ 0x0C of the Texture Structure)

typedef enum _GXTexGenSrc
{
  GX_TG_POS = 0,
  GX_TG_NRM,
  GX_TG_BINRM,
  GX_TG_TANGENT,
  GX_TG_TEX0,
  GX_TG_TEX1,
  GX_TG_TEX2,
  GX_TG_TEX3,
  GX_TG_TEX4,
  GX_TG_TEX5,
  GX_TG_TEX6,
  GX_TG_TEX7,
  GX_TG_TEXCOORD0,
  GX_TG_TEXCOORD1,
  GX_TG_TEXCOORD2,
  GX_TG_TEXCOORD3,
  GX_TG_TEXCOORD4,
  GX_TG_TEXCOORD5,
  GX_TG_TEXCOORD6,
  GX_TG_COLOR0,
  GX_TG_COLOR1

} GXTexGenSrc;

Is this in the melee src pipeline stuff?

 

[Achilles1515]

Is this in the melee src pipeline stuff?

NINTENDO GameCube SDK 1.0\include\dolphin\gx\GXEnum.h

There are more enums in there that we need to look into.

 

[Tcll]

I also saw that in the revolution sdk, just wasn't ever sure how it correlated
that was a long time ago though when I built register identification into my mdl0 template for HexEdit...
back when I knew almost nothing about materials and textures... haha

Big thanks, I'll work on implementing that when I get a break from working on UMC's API

 

[zankyou]

Does anyone know how the text in Pokemon stadium is loaded. Its not a texture in the according to DTW. Would allow for a possible 4 player version of Indigo Stadium.

 

[zankyou]

Found something hilarious out about shadows. If the bits of the second half word of flags in the texture struct is set above 4, the texture follows character shadows.

 

[DRGN]

View attachment 118512 Does anyone know how the text in Pokemon stadium is loaded. Its not a texture in the according to DTW. Would allow for a possible 4 player version of Indigo Stadium.

They seem to be made up from the characters (textures) in the dol.

However, strangely, I couldn't change the uppercase C when I tried replacing it. Which leads me to believe that there's probably another set of characters in the dol; maybe a set with larger dimensions.

 

[zankyou]

They seem to be made up from the characters (textures) in the dol.
View attachment 118545

However, strangely, I couldn't change the uppercase C when I tried replacing it. Which leads me to believe that there's probably another set of characters in the dol; maybe a set with larger dimensions.

Ill look into that. Id assume theres a string somewhere in the grps dat which tells what pics from the dol to use. So assuming you could change ever other letter urrent might be in there. And the C would probably be right before it.
That being said my initial guess for my issue was that there was something wrong with the alignment. If the images are in the dol then the alignment should be fine so Im not sure where to go.
Edit: I got a similar issue with a different file. This effect is the result of an alignment issue. Its just going to be hard to find since the texture isnt in the dat file.

 

[Achilles1515]

They seem to be made up from the characters (textures) in the dol.
View attachment 118545

However, strangely, I couldn't change the uppercase C when I tried replacing it. Which leads me to believe that there's probably another set of characters in the dol; maybe a set with larger dimensions.

The uppercase "C" image data starts at 0x0013e9e0 in GrPs.usd.
Probably a bunch of 32x32_0 image data's packed back-to-back like in the DOL. I did not look for a start location of the text image data.
Z zankyou the text not messed up in your image uses DOL text, as DRGN stated.
EDIT: I believe I misused the term "system text" when referring to the DOL text. I guess I would associate system text with something lower level, like what you see on the Debug Menu for example.

 

[zankyou]

The uppercase "C" image data starts at 0x0013e9e0 in GrPs.usd.
Probably a bunch of 32x32_0 image data's packed back-to-back like in the DOL. I did not look for a start location of the text image data.
Z zankyou the text not messed up in your image uses DOL text, as DRGN stated.
EDIT: I believe I misused the term "system text" when referring to the DOL text. I guess I would associate system text with something lower level, like what you see on the Debug Menu for example.

I just found the error I was making as well. The 87th root node in GrPs points to an array of pointers to textures. DTW didnt pick up on these textures. I also think the game has some way of knowing where these textures are because I wiped that array and it still found them (with graphical errors). There are probably other arrays like this in that file. The root node is called SIS_GrPStadiumData. It might not even be a texture but the strings for letters because theres no image header.
Edit: Its more likely that its just an array of textures like how the CSS file has them compressed. Though usually Id expect to see an image header somewhere. At least for the first texture.

 

[zankyou]

Terribly organized notes on map plit rootnode

map plit - array of pointers
0x0 - pointer to diffuse lighting section
0x4 - pointer to shadow lighting section (possibly only works on the root node one)
0x8 - pointer to ambient lighting section

lighting section
0x0 - pointer to color and light position structure
0x4 - unknown

color and light position structure
0x8 - weird flag possibly related to the material flag (0x4 and 0xe usually)
0xc - rgba color
0x10 - pointer to light position structure

light position structure
0x4 - light position (xyz floats)

It what I call the root structures (possibly files) at 0x18 is a pointer to a map plit type structure. However only 1 of them seems to actually have an effect no matter how many root files there are. For target stages it seems to always be the second one. But as a general rule Id say the one that has an effect is the one directly after the map head section.

 

[Tcll]

I've always been intrigued by these roots, they've thrown off my pathfinder for quite a while now...

Could you explain how exactly these work, specifically for things like root texture data with no header describing the dimensions or even format of the data...

 

[zankyou]

I've always been intrigued by these roots, they've thrown off my pathfinder for quite a while now...

Could you explain how exactly these work, specifically for things like root texture data with no header describing the dimensions or even format of the data...

Theyre not really documented too well. Just finding them as they are needed. I think textures are there kinda like they are in brawl though. To be referenced later.

 

[revel8n]

Ive actually been looking into this recently. 0x4000 is cull inside and 0x8000 is cull outside. I could be wrong but I think brawl reverses the values so at first I didnt think they were related. Also 0x0000 culls both. The thing Ive been trying to figure out for the longest, is what 0x2000 does. For characters you you have to OR the cullmode and 0x2000 or it wont load. For stages Ive never gotten 0xa000 to load.

The mesh flags & 0xC000 are the cull modes i believe, i cannot remember which is which at the moment.

The mesh flags & 0x3000 is the type, and determines what type of data the offset at 0x14 points to.

1. 0x2000 is envelope/weighted, so 0x14 points to the joint weight structures.
2. 0x1000 are "shape sets", so 0x14 points to a different type of structure (have not finished investigating these, just using the terminology from the asm)).
3. 0x0000 still need to verify.

So you cannot change those bits without making other data changes.

Planning on debugging through a lot of the structure handling soon, so hopefully i can fill out more of the data structures for different areas in order to get closer to completing the file format handling.

 

[Achilles1515]

The mesh flags & 0xC000 are the cull modes i believe, i cannot remember which is which at the moment.

The mesh flags & 0x3000 is the type, and determines what type of data the offset at 0x14 points to.

1. 0x2000 is envelope/weighted, so 0x14 points to the joint weight structures.
2. 0x1000 are "shape sets", so 0x14 points to a different type of structure (have not finished investigating these, just using the terminology from the asm)).
3. 0x0000 still need to verify.

So you cannot change those bits without making other data changes.

Planning on debugging through a lot of the structure handling soon, so hopefully i can fill out more of the data structures for different areas in order to get closer to completing the file format handling.

LOL, he is risen. What program is that?

Also, what in God's name does (00000010) in the Material Struct flag do? I see this so often in vanilla material structures, but removing it seems to have no effect.

Thank you for bringing up the GameCube SDK to Tcll back in 2010. I got a hold of it and my eyes have been opened to the truth.

Z zankyou should we be following the SDK verbiage and refer to these cull modes as FRONT and BACK rather than inside and outside?

 

[zankyou]

LOL, he is risen. What program is that?

Also, what in God's name does (00000010) in the Material Struct flag do? I see this so often in vanilla material structures, but removing it seems to have no effect.

Thank you for bringing up the GameCube SDK to Tcll back in 2010. I got a hold of it and my eyes have been opened to the truth.

Z zankyou should we be following the SDK verbiage and refer to these cull modes as FRONT and BACK rather than inside and outside?

Hmm, its tricky. It think the sdk terms follow opengl's terminology which we should be using since melee follows that format. But it is nice knowing the brawl equivalent to see what it does in brawlbox.

 

[SinsOfApathy]

LOL, he is risen. What program is that?

That's IDA booting with a DOL plugin to make it the proper offsets. (or with rev's GDB client for Dolphin)

 

[IndigoSamus]

You gotta go deeper.View attachment 74553
Its funny because me and Tcll were just discussing brawls "shader" system and this might be its predecessor. Basically that FF004C, B20000, and 400000 are all red if you look at them in a color picker. Its a hard spot lol.

Im sorry to be a bother Z zankyou but can you give me a link to this or somehow explain it better? Im a bit of a noob when it comes to color changing.

 

[zankyou]

At the offset I mention you should see those 3 colors hex values. They arent fully understood though. Try setting the last 1 to white. And the first two colors to the same color.