Kingdom Hearts Birth By Sleep models

[valvoga]

Hey,that was awesome zerox,aqua look awesome
to implement bone you can ask MrAdults zerox ,since he can implement bone in smd
But MrAdults hasn't been here for a long time cause he is taking a vacation
You're awesome zerox

[ultimaespio]

Zerox, you just needed to make a bat file for it Coz you didnt use one, thats why the ended up in a random folder.

The flipped geometry is a problem with the normals, Falo hasnt figured those out yet.

[ChrisSquareFan]

The flipped faces are caused by the order of face indexes written in the obj file.
You can try playing with that order.
I wrote an exporter for kingdom hearts models some time ago, i had the exact same problem with the normals.
However i still haven't figured it out... My only guess is that the KH BBS game engine doesn't care about the normals at all...

[Zerox]

Zerox, you just needed to make a bat file for it Coz you didnt use one, thats why the ended up in a random folder.

The flipped geometry is a problem with the normals, Falo hasnt figured those out yet.

Well hopefully Falo or someone else can figure out the problem soon. And I'll take note of that and try using a .bat file next time. Maybe I sound like a total noob here but what would I put into the .bat file then?

Hey,that was awesome zerox,aqua look awesome
to implement bone you can ask MrAdults zerox ,since he can implement bone in smd
But MrAdults hasn't been here for a long time cause he is taking a vacation
You're awesome zerox

Well I had to do lots of fixing to it but yeah I'm able to get the models looking decent. I would love such a method but I guess since he's gone we'll have to wait. Premade bones would be easier than adding them myself.

The flipped faces are caused by the order of face indexes written in the obj file.
You can try playing with that order.
I wrote an exporter for kingdom hearts models some time ago, i had the exact same problem with the normals.
However i still haven't figured it out... My only guess is that the KH BBS game engine doesn't care about the normals at all...

I would try looking at the obj file to figure that out but I'll be honest, I currently have no idea where to even begin with that. But I wouldn't mind learning.

Is that an exporter for KH1 or KH2? I'd be interested in looking at it. Who knows maybe by comparing what you did there with what Falo has done here maybe everyone could work together to figure out a fix?

As for the BBS engine not caring about normals at all I hardly doubt that's true. It's probably just something with the way we (as in Falo) is reading the mesh. I'm sure there is some way to fix it we just haven't found it yet. If the BBS engine didn't care about normals they couldn't do lighting in the game without major issues.

I don't know how to implement the bones.txt files on the 3D models. Have you been able to get them to work?

I haven't but I'd love it if someone could figure it out.

-----------

So I'm just learning the basics of programming in C and such things at the moment so this may not even be possible. But is it possible for one of us to continue where Falo left off? I'm not sure what all went into his converter but if it's something someone could experiment with and continue that would be an worth while effort until Falo comes back I think. Course we may need his source code then I suppose.

[ultimaespio]

For the BAT File:

Code: Select all

kh_pmo.exe IN.pmo OUT.obj

Change IN to the PMO file you want, then change OUT into whatever you want to call the obj file.

I know absolutely nothing about programming, so I cant help :/ But maybe when Mr Adults comes back he might help. Unless theres someone else who knows how to do this sorta stuff that just isnt saying anything?

[Zerox]

Yeah that's what I figured it'd be like. Just wanted to make sure. Haha thanks. With luck someone can make more progress on this. Especially on the UV issues with some models like Terra.

[ChrisSquareFan]

Is there a post where i can see the pmo file format and what was found so far?

[ultimaespio]

Most of Falo's posts on the 1st page should help you. Are you planning on helping with the format?

[ChrisSquareFan]

Yes, i'm thinking of creating an exporter that supports .fbx file format.
FBX works for both maya and 3ds max.
Without fbx you'd have to import the obj file and create a script for creating bones (3ds max) / joints (maya) and for skinning.
With fbx you get everithing in one file: model mesh skinned to bones/joints and texture maps.

[Zerox]

I've been able to get the normals correct after the model is converted. I have found that importing the models into Blender (free 3D program) and going into Edit Mode, Go to Mesh > Normals > Recalculate Outside. Or you could press Ctrl+N and make sure you have all the faces selected. Doing such will fix most the normals making it a whole lot less to fix after the fact.

It by no means is a perfect method considering you still have to manually reflip some faces by hand. But it's a lot less work than it would have been before by about 100x.



Before this I would have said that the models initially looked like they went through a blender. But seeing as the blender is what is doing the fixing this time I'm not sure I can say that anymore.

Either way a real fix when we convert it straight from the pmo to the obj would be even better.

[ultimaespio]

Yes, i'm thinking of creating an exporter that supports .fbx file format.
FBX works for both maya and 3ds max.
Without fbx you'd have to import the obj file and create a script for creating bones (3ds max) / joints (maya) and for skinning.
With fbx you get everithing in one file: model mesh skinned to bones/joints and texture maps.

Yeah that would be better. Falo's posts should help you with that.

I've been able to get the normals correct after the model is converted. I have found that importing the models into Blender (free 3D program) and going into Edit Mode, Go to Mesh > Normals > Recalculate Outside. Or you could press Ctrl+N and make sure you have all the faces selected. Doing such will fix most the normals making it a whole lot less to fix after the fact.

It by no means is a perfect method considering you still have to manually reflip some faces by hand. But it's a lot less work than it would have been before by about 100x.

http://img440.imageshack.us/img440/2426 ... nanima.png

Before this I would have said that the models initially looked like they went through a blender. But seeing as the blender is what is doing the fixing this time I'm not sure I can say that anymore.

Either way a real fix when we convert it straight from the pmo to the obj would be even better.

I think that's what I did with my Aqua model. Just couldnt remember how I did it A proper fix would be really nice. Any way we could help ChrisSquareFan?

[revelation]

Figured i would chime in real quick.

Still working on confirming a lot of the findings, as i have not looked to deeply into getting a better method of extracting the PMO files from the main files yet. Since i have not coded anything up to actually convert the data, i figured hopefully this will be helpful for others to help verify until i can post a more complete description of what i have so far.

Code: Select all

		struct
		{
			uint32 texCoord : 2; // texture coordinate format: 0 - none, 1 - uint8, 2 - uint16, 3 - float
			uint32 unknown0 : 5; // unsure of bit size, but when this is not zero, diffuse color is present in vertex data
			uint32 position : 2; // position format: 0 - none, 2 - int16, 3 - float > Still look
			uint32 skinning : 1; // only seems to be set when there are joint weights present?
			uint32 unknown1 : 4;
			uint32 jointCnt : 4; // maximum joint index used? (index count = joint count + 1 - or just use (jointCnt + skinning)
			uint32 unknown2 : 6;
			uint32 diffuse  : 4; // seems to only be set when a diffuse color is present in header
			uint32 dataType : 4; // 0x30 - tri-list, 0x40 - tri-strip - ?
		} dataFlags;

So far this has allowed my 010 Editor template to successfully parse all the data i have found so far, but as i said i am still confirming some things against more files.

Code: Select all

			struct
			{
				local uint32 jointCount = dataFlags.skinning + dataFlags.jointCnt;
				if (jointCount > 0)
				{
					uint8  jointWeights[jointCount];
				}
				
				if (dataFlags.texCoord > 0)
				{
					switch (dataFlags.texCoord)
					{
					case 1:
						uint8  textureCoord[2];
						break;
					case 2:
						FSkip((0x02 - ((FTell() - startof(this)) & 0x01)) & 0x01);
						uint16 textureCoord[2];
						break;
					case 3:
						FSkip((0x04 - ((FTell() - startof(this)) & 0x03)) & 0x03);
						float  textureCoord[2];
						break;
					default:
						Printf("Unrecognized texture coordinate format! - 0x%08X\n", FTell());
						break;
					}
				}
				
				if (dataFlags.unknown0 != 0)
				{
					FSkip((0x04 - ((FTell() - startof(this)) & 0x03)) & 0x03);
					uint32 diffuseColor <format = hex>;
				}
				
				if (dataFlags.dataFlags.position != 0)
				{
					switch (dataFlags.position)
					{
					case 2:
						FSkip((0x02 - ((FTell() - startof(this)) & 0x01)) & 0x01);
						int16  position[3];
						break;
					case 3:
						FSkip((0x04 - ((FTell() - startof(this)) & 0x03)) & 0x03);
						float3 position;
						break;
					default:
						Printf("Unrecognized position format! - 0x%08X\n", FTell());
						break;
					}
				}
				
				local uint32 paddingSize = vertexSize - (FTell() - startof(this));
				if (paddingSize > 0)
				{
					uint8  padding[paddingSize];
				}
			} vertex;

The main things to note is the padding considerations necessary to ensure data type start on the correct byte. The most common padding byte value is 0xAB, so if you get a value containing that you are more than likely covering the wrong bytes for that data type. So for the moment i have just chosen alignments that work for the data i have come across so far.

If things work out, i will probably just go ahead and thrown from output statements in the template to convert to obj and see what happens. In the meantime i guess we can working on vofirming or denying these things and see what else there is.

Let me know if something doesn't makes sense or i have made a silly mistake somewhere, heh.

Hope that helps.

What else are others working on deciphering?


EDIT: Update for float position information....still looking for whether or not positions can be 8-bit values...

[Zerox]

revelation I wish I knew how to use that information you posted but I am not sure where to start as I'm inexperienced with information like that. Any advice on where to learn what it all means would be something I would look into for sure.

Anyway I was curious is there an easy way to convert a big batch of .pmo models using Kh_pmo.exe? The .bat method works great but it only works for one at a time. I was considering trying just dragging and dropping a bunch on at once. But I was wondering if there was a way to get the ones within folders by just selecting one big folder overall that contains everything.

As it stands right now I think that we essentially have two major problems. The normals being flipped upon conversion. And some models not retaining UV mapping data. There are other things like bones and animations but I think the other two are the more critical ones at this point in time.

Personally I would really like the problems with messed up UV data fixed. I'm willing to try to help fix it if anyone can at least give me a starting point on what we know already and how I might proceed.

[revelation]

I am not sure how the current converter in this thread is handling the faces. But the face ordering should just be a matter of handling the change between each face when converting tri-strips, versus not having to with tri-lists. So far, unless there is something i have not seen, i have not found any normal data in the files, and more than likely all lighting is baked directly into the textures. The UV information should also just be a matter of handling the correct alignment of the data in the vertex information, which is mainly what i posted above covers. But i will have to see once i actually attempt converting some of the data given what i have found out so far. Probably going to try that here in a sec since i have tested against a good deal of the files i have extracted so far. Still looking for any more inconsistencies in the current way i am handling things so that all cases are covered. Will have to see i guess.

[Zerox]

Ah well alright. It may very well be that's how they did the lighting it just seems odd to do it that way though. If you think you have a fix for the UV data when converting I recommend you try these files:

p03ex00.pmo (Terra Low Poly) and p01ex00.pmo (Ventus Low Poly)

Both have UV issues. Ventus has less issues but there definitely is missing UV data.



But the low poly Terra is worse. He has absolutely no UV data retained when converting him with Falo's converter. I could post both the files if you want. I'm happy to help where I can.