XeNTaX

im not really sure though I don't think the end result would be different.

Also they say I have nice models because I am an actual 3d modeler, check out some of my work

oh lol I thought they were referring to some model viewer you wrote for the det files.

That's really detailed. Can you animate it as well?

Anyways I'm looking at the client and there are some DET files for "map" objects. Any clue on the compress there?

The contents of this post was deleted because of possible forum rules violation.

finale00 wrote:oh lol I thought they were referring to some model viewer you wrote for the det files.

That's really detailed. Can you animate it as well?

Anyways I'm looking at the client and there are some DET files for "map" objects. Any clue on the compress there?

as far as map files go they are completely different. I wouldn't be able to figure those out. Its a shame too they have vehicles that arent available such as the core booster.

Found another pattern, and I can use it to parse the model correctly, but it's sort of hack-ish.

Basically, I mentioned there was some seemingly random number at the end of each chunk. Instead of interpreting it as a long, I interpreted as two shorts, and this was the result:
Take a look at the last tuple of numbers.

The second element is always the same (except for the last face section).

The first element for corresponding chunks has an absolute difference of 52.
I refer to it as the "Key" just for sake of reference.

Object0: vert key: 576, face key: 628. Difference of 52
Object1: vert: 368, face: 420. Difference of 52
Object2: vert: 784, face: 732. Difference of 52
Object3: vert: 836, face: 940. Difference isn't 52.

But look at object5: vert key: 992, and object3's face key is 940, difference of 52.

If we read it in order from 0 to n - 1, then we can effectively skip the vertex chunks we don't need.
Object n just corresponds with the last vertex chunk.

Well, I implemented the hack-ish method I described and processed the Magellan model...maybe correctly I don't know.



But it didn't work for the gundam you sent.

The keys don't match up as I had previously claimed, so perhaps that's not what it should be based on.

EDIT: just thought of another hack-ish method knowing that they should be parsed in the order that they appear, with some possible extra vert chunks. Use the max referenced index as the comparison value and create faces only when the max index == numVerts + 1

Here's the gundam, though transformations would probably still need to be applied. Or at least some method to...position the meshes properly.



"zaku tank"

Looks like you are getting very close. As far as the model goes, you aren't gonna actually get things to load in their correct positions because from what I can see they just get relocated in game. The admin can relocate parts on the models without actually loading them up in 3ds.

From what I can see if any part of that mesh was modified it will still be in the same spot in game.
Just an idea but are you able to get just one object to load at a time instead of them all loading at the same time?
Beautiful work on that zaku tank BTW.

Yes, you can store each mesh separately and then choose to output them as separate files.
Just group the corresponding vertex chunks with the face chunks and you're all set.

Some of the images I included the mesh list so you can see object[0], object[1], ... Those are all separate meshes.

Once the format has been formalized, it should be easier to write import scripts for any 3D software. Of course, all we have right now are vertices and faces; I just stop parsing the file once I reach a non-face chunk.

EDIT: gundam head (all other meshes hidden)

dude you are pouring gravy in my eyes right now. Awesome job and thanks for the hard work you are doing.

Everything after makes no sense to me. I can't find any pattern without brute forcing it (ie: keep reading bytes until you see a huge number that marks the end of the chunk).

This applies to "script data" chunks, "shader" chunks, and whatever else after.

finale00 wrote:Everything after makes no sense to me. I can't find any pattern without brute forcing it (ie: keep reading bytes until you see a huge number that marks the end of the chunk).

This applies to "script data" chunks, "shader" chunks, and whatever else after.

I guess that's not good. Hopefully you can find that pattern. I am curious and I hope this isnt the case but do you think some .DET files may be built differently?

Some of the files start with 02. The majority start with 04. There is some slight differences there.
Other than that, the format is pretty much the same.

A bunch of script data, then a bunch of references to some shader files, and then some materials, and then what appears to be bones.

finale00 wrote:Some of the files start with 02. The majority start with 04. There is some slight differences there.
Other than that, the format is pretty much the same.

A bunch of script data, then a bunch of references to some shader files, and then some materials, and then what appears to be bones.

that is something that really interests me, I been trying to add a cubemap to the files so they can have a shiny effect. If you notice the taxi is glossy but the MS are matte. I was trying to see if I could add that gloss effect to them.

Wow!
I read the post with interest.
How to import .DET files into metasequoia?

Parse the file and then write out the contents in MQO format.
Here's a Sanae plugin that I use.

Troopermanaic wrote: that is something that really interests me, I been trying to add a cubemap to the files so they can have a shiny effect. If you notice the taxi is glossy but the MS are matte. I was trying to see if I could add that gloss effect to them.

I don't know much about material properties and hence don't know much about how or where they might be stored.