Log in

View Full Version : Dat and obj question.


Madox58
01-29-07, 08:07 PM
When I do a conversion from standard obj file to import to a dat
9/1 13/2 12/3 converts to hex = 8 12 11 0 1 2
Haveing not looked at all dats, is this standard game wide?
The fact that it drops a full point?

Then the other 2 conversions.
Standard game wide?
Or do I need to dig a bit deeper?

Don't want how to do it, just a pointer.
I learn better that way.

DivingDuck
01-29-07, 09:32 PM
Moin,

can you be a bit more precise?

Regards,
DD

Madox58
01-29-07, 09:44 PM
OK, I'll start with the first question I asked.

f 13/12 26/25 14/13

The above, when imported with Pack 3d, is converted to hex.
You get 13 26 14 then 12 25 13
But the file I'm look at is comeing out
12 25 13 11 24 12

The coords to the left of / are first then the coords to the right of / come next.
Notice they are -1

Is this game wide?

By the way, DD, I have eveything you've posted saved to my HD!
You are the Hex Master!!!

DivingDuck
01-29-07, 09:55 PM
Hi privateer,

where do you have these coords from???

As for coordinates I can tell you that X/Y/Z are not carried straight forward from your 3d program to the *.dat.
X remains X
Y becomes -Z
Z becomes YCoordinates are stored as float32 data type. Means that each value (X/Y/Z) is represented by 4 bytes in the *.dat.

Hope that´s the info your looking for. Go ahead with your next question!

Regards,
DD

Madox58
01-29-07, 10:10 PM
Yes Sir, I understand all this. (Thanks to you!)
The files I'm looking at are my K-Ship files.
As I said, I have not looked farther yet.
Does this area, infact, drop a full point in all dat files?

I can now "read" objects inside of the dats but I haven't looked at any but
my K-ship dat.

If it's game wide, no reason to.
If not, back to work!!

Thanks again DD!!! :up:

DivingDuck
01-29-07, 10:27 PM
Hi again,

By the way, DD, I have eveything you've posted saved to my HD!
You are the Hex Master!!! Thanks, I feel dignified. But I think I´m not. There are others who deserve this title more than me. I´ve no experience in programming, I´m just analyzing and editing.

As far as I know there´s no "standard" drop. I´ve never heard of one nor did I encounter a problem like that. So, what are these values for and what are you planning to do? Maybe we can isolate the problem by another approach.

Regards,
DD

Madox58
01-29-07, 10:35 PM
OK. I've got the files taken down and seperated so I can identify each area.
I'll go back through them and TRY to mark them as well as you have in past posts.
I'll also check a few random dats to see if the patterns I spotted are persistent
game wide.
Forgive me if I'm a bit slow on posting them cause if I don't finish the remodel of
the wifes room, I'm, GULP, a DEAD DUCK!!!:o

Madox58
01-29-07, 11:07 PM
OK, Here is one on verts.

http://i108.photobucket.com/albums/n12/privateer_2006/Sub/Image1.jpg

Notice the IEEE single compaired to the object file itself.

DivingDuck
01-29-07, 11:11 PM
Hi,
Forgive me if I'm a bit slow on posting them cause if I don't finish the remodel of the wifes room, I'm, GULP, a DEAD DUCK!!!:o :rotfl:
I'll go back through them and TRY to mark them as well as you have in past posts. Take your time. And, btw, can you tell what area these data belong to?

Although I´ve no time to play SHIII since I´ve started modding, I´d like to have a closer look at your K-Ship. I don´t get the point how you managed to let them bob as you/they say. Is it available for download already?

Regards,
DD

Madox58
01-29-07, 11:23 PM
The bobbing and stuff is set on the barrage balloons.
Still very early tests so far but they are helpful for the K-Ship
Mod and proved some very interesting concepts!!

Send me a PM with a place to send and we can go from there.
:up:

Oh, the image above is a standard Navalmine.dat tore apart!

Madox58
01-29-07, 11:39 PM
Now, look at this capture. Notice the differences?
http://i108.photobucket.com/albums/n12/privateer_2006/Sub/Image2.jpg

In this case, if we subtract the IEEE single from 1, we get the factor from the obj file.

ref
01-30-07, 07:04 AM
Block 01 (3d object ) structure

01000000 block type dword
00000000 block subtype dword
00000000 block size dword
XXXXXXXXXXXXXXXX ID int64
XX unknown 1 Byte
number of vertex dword
then cames vertex data: 3 floats (x,y,z) repeats number of vertex times
number of faces dword
faces data : vertices (3 x word) ;texture coords 3x word; face material byte
The above values references index from the vertex/texture coords arrays.
number of texture coordinates dword
texture coordinates u,v float repeats number of texture coordinates
sometimes here cames a TMAP chunk (don't know what it is) I just skip it.

Ref

Madox58
01-30-07, 11:58 AM
@Ref, Yes, I understand the structure of the dat file.

What I'm looking at is the conversion from .obj to hex used in the .dat
Here's a better image to explain one part of the conversion.

http://i108.photobucket.com/albums/n12/privateer_2006/Sub/Hex1.jpg

ref
01-30-07, 12:42 PM
what version of pack3d did you use to import the data?
the red column (v coordinate) is all wrong :hmm:

Ref

Madox58
01-30-07, 01:10 PM
This is the NavalMine.obj
I extracted using all 5 versions, all match.
To be sure it is not corrupt, I copied NavalMine.dat from
My GWX install. I don't mess around in there.

DivingDuck
01-30-07, 01:49 PM
Hello privateer,

I did not dig deep into the texture coords issue til now, but maybe this can bring some light to you:

This i how the uvw mapping tool desktop should look like in any 3dprogramme

http://img444.imageshack.us/img444/4788/vt001tg2.jpg

As the SHIII engine turns Y to -Z in vertex position it might be, that there´s a similar turnover in vertex texture coordinates. Just imagine Y becomes -Y and is counted from the top left corner. Would that match your data?

I´ve reached a point where my English isn´t good enough to explain what I mean. Hope you understand it anyway.

Regards,
DD

Madox58
01-30-07, 04:04 PM
@DD, that could be. I've looked at several different files now.
the subtraction from 1 holds true in all the dats I've looked at
so I'll use that as a rule till proven wrong in testing. :yep:

Going back to the other section:
9/2 8/3 7/1

I've got an idea what is going on here but I need to look at the dats some
more.

We take the left numbers first 9 8 7
then the right numbers 2 3 1

In the NavalMines.dat these numbers are reduced by 1
We read 8 7 6 1 2 0

Not sure if this is game wide yet.

ref
01-30-07, 04:31 PM
@DD, that could be. I've looked at several different files now.
the subtraction from 1 holds true in all the dats I've looked at
so I'll use that as a rule till proven wrong in testing. :yep:

Going back to the other section:
9/2 8/3 7/1

I've got an idea what is going on here but I need to look at the dats some
more.

We take the left numbers first 9 8 7
then the right numbers 2 3 1

In the NavalMines.dat these numbers are reduced by 1
We read 8 7 6 1 2 0

Not sure if this is game wide yet.

That's because the dat files use 0 based arrays.
ie. face 1 is stored in facearray[0]

Ref

Madox58
01-30-07, 04:38 PM
Doh! :oops:
:rotfl: