XeNTaX

Seems to be different vertex types, but not sure how.
It's possible that some of the values in the vertex change its size.

The header contains offsets to the vertex/face/material sections, and the vert count is there as well.
But I can't divide things evenly into the vert count.

Some of the files come out to 88 bytes per vertex, which is nice, but then some other files don't divide evenly at all (89.xxx, 92.xxx, etc)

Which files? can find one that differs, format type x18 and x19 is all I got.
The values:- 01000000 04000000 in the 88 bytes are always followed by 4 floats, is there an 01000000 03000000?? or other value followed by that many floats?

NVM - I see it now. 48 bytes + 00000000 + ???????? + 2 floats + long (num_of)
Then there are num_of fields
each field is long + 4 floats

Sounds about right but i'm tierd

Hmm ya, that makes sense. When it's just 1, then we have the 88 byte vertex. When it's 2, we have more. Similarly for 3....etc

I don't know what the vertex type is for then lol
But I think the struct is slightly different for the two, even though they follow the same idea.

Now that that's out of the way...
Those might be the bone references. bone ID + 4 weights maybe?
You see them referenced after the face section...though there may be multiple face sections.

EDIT:

There we go.
Anyone want to upload the skeleton files? They're located in the animation folder (don't have the files on me)

The .fscn files should be pretty simple now that we've identified a couple patterns that the devs used.
The .fak files are still a huge mystery though, and most of the weapons are fak



http://xtsukihime.webs.com/Noesis%20Plu ... g_fskin.py

Now I would've preferred female models...

well a girl... i put here model and animation coz i not see skeleton but i shure this its skeleton on animation folder.


http://www.4shared.com/rar/qU41b00V/AVATARGIRL.html

Yeah, upload the female parts CriticalError

4 weights per bone sounds good, looks like some vertex colors as well in all that data.
Anyway, those .fak files, looks like 8 shorts per vertex, dunno what the chunk after the vertices is, damned fixed point data.
Looks like icon data in a few files as well.
Think the 6th long from the start is number of objects, there seems to be that many chunks in the triangle lists.
260 0's instead of 320.
chunk for each objects triangle list seems to go:-
0000 + short(duno-might be 2 bytes) + 6 floats + num_of_tri (long) + triangles + 5 longs(all 0?) + long(with value)

They might be half-floats. I didn't try that. If it's your typical coords/normals/uv that would be great. But I don't have noesis on me right now

It sucks that 010 editor doesn't display half-floats as one of its inspection values.

If you go to the vertex section (assuming that's what it is), you'll see a bunch of FF's and then followed by an integer.

Then the following section is that integer * 2. Maybe a whole bunch of half-floats?
If you take that integer and divide it by numVerts, you'll always get 11. It might not mean anything of course, but always turning up as 11 is rather curious.

But ya, seriously, what could this be lol

Guess they're not half-floats.
Or at least, nothing nice came out.

It looks like a lot of the file is chunked, where you read an integer and then read that many bytes (or maybe twice that many bytes). This continues until you get to the material section, which is just a typical Loong material.

Header for FAK files
And then after that..

Someone post up fscn files.

FSCN

http://www.4shared.com/rar/TdP7YgfC/fscn.html

With half floats the scale will be off, ie really tiny, try scaling up?
11 shorts is 22 bytes, similar to the 44 byte format in the fsm, so it's either half floats or ints(signed).
Ints look similar in scale to the other files.

How come half-floats throw the scale off?

It's not 11 shorts, but literally 11 bytes assuming vertSize = chunkSize / numVerts lol
Anything bigger than that, and you'll be going past that particular section.

Of course there's a whole bunch of similar sections that observe the same pattern, but I don't know...

Anyways when I say "nothing looks good" it's really just a bunch of random points scattered all over the place. Nothing that resembles a weapon of sorts.

Rimbros wrote:FSCN

http://www.4shared.com/rar/TdP7YgfC/fscn.html

Ya the format was pretty much the same as fsm.
Except there is some odd struct at the very end of the file...

Some textures would be nice also.
Get the textures that are named like M01_01, M01_02, etc so I can post a screenshot that looks colorful.

The game's music is pretty nice: http://www.youtube.com/watch?v=tHn4xB_j4jo

Half floats don't, having your scale set to 100 does that, silly me.
No, it's 11 shorts, chunk size given is half the actual chunk size.

Using ints, I put that second set of data in, it's 6 bytes per vertex, I got very similar results, the corners of a cube distribution of points.
I noticed though that filename_a is an FSM and without the _a it's fak....
Some models like j06 use the same texture for a few of models.
Going to go through the files see if there is anything that suggests it's not actually a model format, or if it reuses verts from another file.

Oh. Ya, 11 shorts.

The bows are the g items.
the first couple g's are FSM, but then the rest are FAK's.

I guess it's possible they might design something like that...

I like how multiple models that use the same texture simple duplicate the texture in each folder.

Lol - i just tried it with half floats, came out very nice.
Guess you been doing the rapi.rpgBindPositionBufferOfs(vertBuff, noesis.RPGEODATA_FLOAT, 32, 0) type thing with 11 instead of 22.....
That'll make it read crap if you use 11.

So basically it's the same vertex format as the fsm files that uses 44 bytes per vertex, but using 16bit floats instead of 32bit floats.
Not sure if vertex data has multiple chunks if there is more than 1 'object' like in the triangle lists.

http://xtsukihime.webs.com/Noesis%20Plu ... ong_fak.py

That's it!
lol ya I was reading numVerts*11 as well

Some sexy bow...like things in those FAK files.



Well, there goes that mystery.
It never occurred to me that 11 bytes doesn't make too much sense lol

The integer before the vertOfs might be the number of vertex groups, but it's not obvious which faces reference which vertices.

Each face group has a short that indicates how many vertices are referenced.
They even throw in some ascii-encoded strings in there lol

Maybe it'll become clear once the entire file is parsed and all of the unknowns re-evaluated.

The face groups are definitely referencing different vertex groups. Some of them just happen to load up fine.

It seems like I'm assigning the faces in the wrong direction though...

EDIT:

here's something that I noticed, if you didn't notice this already.
As already known, in each face group, it starts with an integer, followed by 2 shorts. Then 6 floats, the numFaces, followed by the indices.

The first integer is useful because it gives us the vertex offset.

So the first face group references the first n vertices starting at vertex 0.
The second face group references the next m vertices starting at vertex n.
The third face group references the next i vertices starting at vertex n + m
etc

In simpler terms, supposing I have two face groups, a vert list = [0, 1, 2, 3, 4, 5, 6, 7, 8] and my first face group referenced the first 5 vertices [0, 1, 2, 3, 4], then the next face group would reference the remaining 4 vertices [5, 6, 7, 8], where the indices are relative to the subset of vertices.

With that said, here's G11.fak



Sadly, I'm still skipping a whole bunch of data. I'm basically reading the vertex data, and then seeking straight to the material section.

great news guys, really grateful working in this game, it have good potential 3d models, keep working guys.