Tutorial on how to clone objects by Chris aka Orzel

[iambecomelife]

Orzel, if you're still here I'd really really like to learn how to move and add objects on the ships. Perhaps another tutorial...?

[Shadow9216]

I'm almost done changing all the tags for the B-24...all 103!!!
Once that's done I'll see if it creates a new instance of the model. If THAT works, I'll see about changing the name to something else.

If all of THAT works, I'm going to start experimenting with different layouts. It's a very hit or miss procedure right now, and coming up with the ids is only half the problem.

[lurbz]

Ok some stuff about DAT files and my tool.

-AFAIK, all chunk IDs should show up in the chunk list, but maybe some models have chunk types that I didn't decode, the tree is just to see the 3d part hierarchy.

-I'd try cloning starting with a simpler model: Headgear (helmets, caps). A nice project: a separate white officers' cap to have one officer pose as kaleun.

-I have received some requests for the source code of my tool. I don't particularly like releasing it, because it is extremely crappy, just a testbed while I was decoding the file, quick, dirty, ugly... you name it. On top of that it's C#, and I was learning the language as I was typing. All said... here you are, a full copy of my VS project, the meaty bits are in Form1.cs...

Consider it all public domain.

http://cursos.usal.es/~felipe/dc/datconvertsrc.zip

-About moving ship parts: this is quite easy, just locate the desired chunk using my tool, hex edit the x,y,z coordinates, and you're set (look at type 4 chunks in the notes below).

-Finally, here are the notes I took about the file format, they are not complete, but can help anyone who whishes to keep at it:

SH III DAT FILE FORMAT

Skip the first 20 bytes they seem to be always the same.
Next 4 bytes are a long with the header string lenght.
Next is the author name and the "using Kashmir" stuff, total lenght as read above.

Next, file is made of "chunks". All chunks are like this:
ChunkType 4 bytes
Chunk Subtype/Version 4 bytes
chunk_size long (4 bytes)
Data (chunk_size bytes)


Chunk types and internal structure of each one:

type 0: EMPTY chunk
it's just 12 "00" bytes, so type, subtype and size are 0

type 1: 3D chunk
after the Chunk type, subtype/ver and size, format of the data part is like follows:
chunk_id: 8 bytes //this is used to reference this part inside the file. References usually found inside NODE (type 4) chunks
???????: 1 byte //don't know about this one
nverts: 4 byte long //number of vertices
vertex data: nverts * 3 floats// these are vertices, 3 floats per vertex
ntri: 4 byte long //number of triangles;
triangle data: there are ntri triangles and their texture mapping, each one is as follows
    vertex1: unsigned 2-byte int
    vertex2: unsigned 2-byte int
    vertex3: unsigned 2-byte int
    texture coord1: unsigned 2-byte int
    texture coord2: unsigned 2-byte int
    texture coord3: unsigned 2-byte int
    ????????????: one byte
ntxcoords: 4 byte long //number of texture coordinates
texture coords data: ntxcoords * 2 floats // texture coordinates are 2D

some objects end here, but some have "TMAP" and a bunch of floats after this, dunno what is that yet so I skip it

type 2: TEXTURE REFERENCE?
after the Chunk type, subtype/ver and size, format of the data part is like follows:
chunk_id: 8 bytes //this is used to reference this part inside the file. References usually found inside NODE (type 4) chunks
then a bunch of bytes that I haven't figured yet, usually ending with a texture filename.

type 3: TGA FILE
these are the TGA files, just packed after the type, subtype and chunk size.

type 4: NODE (these tell us how parts are related to each other, in a tree-like hierarchy)
after the Chunk type, subtype/ver and size, format of the data part is like follows:
chunk_id: 8 bytes //this is used to reference this node inside the file. References usually found inside NODE (type 4) chunks
parent_id: 8 bytes //reference to the "parent" node. root nodes have 00 00 00 00 00 00 00 00 as parent
3dpart_id: 8 bytes //reference to the 3d part managed by this node, 00 00 00 00 00 00 00 00 if this is a "dummy" node with no visible 3d part
????????: 1 byte, seems to be always 00.
????????: 1 byte, seems to be related to the number of different type 2 nodes referenced from this one.
x offset: 4 bytes float //x offset from parent node
y offset: 4 bytes float //y offset from parent node
z offset: 4 bytes float //z offset from parent node

then comes the type 2 chunk references and some stuff I don't yet understand

type 6: DATA?
these are children of type 10 chunks, they seem to hold effects, commands, interactions, etc...
first 8 bytes are the reference to the type 10 parent. rest is strings and numerical values.

type 8: LABEL
these are used to label other nodes
format is:
8 byte parent chunk reference
string with label

type 10: DATA?
these seem to group type 6 chunks and attach them to type 4 nodes
first 8 bytes: id of this chunk
second 8 bytes: id of parent node
then comes some data, usually strings and numbers.

type 102: SCALE?
these come usually near the end of the files, they are a bunch of floats, probably some global scaling, have to test it

type 1001: INDEX
this one seems to be an index, there are chunk ID's and the corresponding file postition, might have to update this if some chunk has its size altered, but some tries suggest this doesnñr affect loading.



There are more chunk types, haven't had time to check them

[Seeadler]

Originally Posted by lurbz

On top of that it's C#, and I was learning the language as I was typing.

I'm with you, I had to learn the basics of C# in the last weeks also, because this is demanded in my current real life project

[Shadow9216]

@Orzel- can you identify which strings need to be changed in zon, sim and dsd? REALLY appreciate it if you can.

[Jace11]

Thanks Lurbz, maybe one of the resident programmers here will pick up on it.

[Canaris]

Hm, that is known and i'm working as quick as i can.



But their are some problems concerning the second and maybe third texturstage.



Detailmaps aren't be shown correct while lightmaps seem to be right.



But like the "Kaiser" said: "Schaun mir mal."


MfG
Canaris

[Jace11]

Er, hello there...

Wir haben ein miracle worker...

I recognise the name from somewhere..

German forum or 9th Flotilla?

[lurbz]

I surrender

[Canaris]

Jace11, maybe german ubi-forum, but 9th flotilla is very chilly.

lurbz, no way! Keep up the good work, because i will do this tool in first to be used by 3DArtists. These people don't need to know everything like these damn 64 bit ID.
In germany, we would say "the sparrow in your hand is better than a pigeon on the roof".

The problems concerning the textures is only the first part, the next are the datanodes(6 and 11) and the 3ds fileformat.

[Shadow9216]

Hey, multiple-skin creators...how do I create files to support the multiple skin format? I presume it's the dat file, do I just repack it with a new tga (the desired skin)? Do I make any other changes to the dat file? Or is it more than that.

I could compare the multiple skin warship mod against the stock files, but I'm afraid I might overlook a small detail. If you could shed some light it would help me greatly.

[iambecomelife]

Bump

[Shadow9216]

Orzel, can you help me identify the files in zon/sim/dsd for the liberator? In case I miss one?

[Jace11]

Originally Posted by Canaris

Jace11, maybe german ubi-forum, but 9th flotilla is very chilly.

lurbz, no way! Keep up the good work, because i will do this tool in first to be used by 3DArtists. These people don't need to know everything like these damn 64 bit ID.
In germany, we would say "the sparrow in your hand is better than a pigeon on the roof".

The problems concerning the textures is only the first part, the next are the datanodes(6 and 11) and the 3ds fileformat.

How are you getting on with your editing program?

[Canaris]

Hm, i see you are in hurry.
I wil do a little description what i have done last week.
To export and import models correctly, you have to understand how SH3 uses the data from dat files.
Simpler things like vertexformat, indexformat and texturecoordinatsformat are known, but how puts SH3 all these individually saved modelparts together?
First step: lets simply render the entire tree.



That looks like crap.
But vertices can be moved forth and back along 3 axis. Hm that should be easy. :hmm:
added translation:



No! That isn't right!
But if there are axis, there have to be something rotated. Hm takes me a smile. :hmm:
added rotation:



No! That was the next shot!
After some coffee and a little bit later...
I've read somewhere that in 3ds files, there is the manipulation from parentmodelnode is taken over to childnode. Let's have a look. :hmm:
added values from parent:



NO! NO! NO!
Lets play a little. Rotation away, rotation added....
That ****ty litle plane rotates in wrong direction!
Lets rotate the entire **** to the other direction.



Ahhhhh!
But what's this?



What does this little stupid chap there!
...

Long baba, short sense: That isn't finished today and not tomorrow.
Maybe one day...

MfG
Canaris