[Request] DragonBall Online Mesh Viewer

[shakotay2]

I uploaded an improved version some posts above.

Is your software open source or are you willing to share it?

My coding style is too sloppy as to reveal it to the (sometimes very harsh) criticism of the public.
So sry: no.

If not, can you more or less sum up the the format?

The above crash course is containing 90% of the info you need, imho.
The format itself being relative simple:

Be informed that it doesn't start from file offset 0x0.
The beginning of the data and addr of face count is determined by a pattern search.
(to clearify this due to r3d's hint. Thx for it.)

Code: Select all

face count DWORD
vertex count DWORD
unknown DWORD  (01 000000?)

start of tex coords block
tex 2 floats

tri faces, indices f1, f2, 00, f3 unsigned ints	// 00 00 to be skipped
gap of 24 bytes
vertices 3 floats
normals 3 floats

For buildings there's some kind of 2nd texture coords block to be skipped ( verts count * 8 )

The main job is to find the offsets of the different blocks (texture coords, face indices, vertices).

Often pattern search is very helpful. I used "paint name" for the 1st button (in the 1st version)
and 01000000.

You'll experience many findings for the 01000000 pattern in ud6_c_f3_001.dff
so the trick is - as always - to determine the right ones.

Here's an example how to get them:

Code: Select all

for (l=1;l<=lastSM;l++) {
         //if (cnt==18)		// Achtung! Wird VOR Ausgabe incr.
         //    l=l;          // debug point
         offs= dwSM_offsaddr[l] ; if (offs<offs2) goto _next ;
         if ( (*(pFBuf+offs+8)==0)&&(*(pFBuf+offs+9)==0)) goto _next ;
         if ( (*(pFBuf+offs+6)==0)&&(*(pFBuf+offs+7)==0)&&(*(pFBuf+offs+8)==0)) goto _next ;
         if ( (*(pFBuf+offs-4)==0)&&(*(pFBuf+offs-3)==0)) {		// dort face index 2, imma 00 00
            cnt++ ; fprintf( stream, "g submesh_%d_3\n", cnt) ;    
            offs -= 6 ;			                                // algo=1 statt 3
            FindStringInBuf_DragonBall_onl(offs, dwFileSize, nValue, 1, lastFaceNo) ;	// &offs in fct def.
            offs2= offs ;
         }
_next: ;
}

I won't bother to explain this because it was just some "trial and error".

[LinkvsSangoku]

Wow, nice update, i found other meshes who doesen't work with one of the three buttons
http://www.mediafire.com/download/b4sdi ... 001_02.dff and http://www.mediafire.com/download/b4jbx ... gku_b2.dff

I have one other question, can you try to conserve material list for the mapping ?

[shakotay2]

Wow, nice update, i found other meshes who doesen't work with one of the three buttons [...]dwc_temple_001_02.dff and [...]n_gku_b2.dff

well, the fst one is weird. Don't know how to handle. The 2nd one has an invalid texture block (18 x FFFFFFFF FFFFFFFF at 0x394D0) which I skipped manually. I won't handle every single irregular dff but here's the obj: http://www.uploadmb.com/dw.php?id=1377891048

I have one other question, can you try to conserve material list for the mapping ?

Still don't understand. Same goes with

i mean textures files are "automatly" positionned in-game

You are talking about texture coords in the dffs?

I don't have a texture to test but the UV maps seem to be o.k. in blender.
So maybe you can explain what you want to do or what exactly the problem is.

[r3d]

Just a slow poke reaction from me but is the data little endian? I am a bit confused here

[shakotay2]

yep, little endian. (You can't use hex2obj for the n_hmy_m_b2.dff (see previous crash course)
because there is an uncommon 4th face index 00 00.)

[r3d]

Thx

Some new questions have arisen in my head.

1) Do the meshes always use 1 texture?
2) Is the amount of tex-coords equal #faces *3 ?
3) In case of buildings why do we skip verts count*8 ? Where does the 8 come from?

[shakotay2]

Thx

Some new questions have arisen in my head.

1) Do the meshes always use 1 texture?
2) Is the amount of tex-coords equal #faces *3 ?
3) In case of buildings why do we skip verts count*8 ? Where does the 8 come from?

1) afair I had no texture files so I don't know. Search for the texture files of a sample
(see my post of Aug. 29th about the B_Kinto_x strings in a dff) and you'll know it.

2)afair after 3 months is vertextcount==normalscount==texcount

3) did we skip? You really could help my if you gave me a quotation

(I'll go to sleep now...)

[r3d]

Thx

Some new questions have arisen in my head.

1) Do the meshes always use 1 texture?
2) Is the amount of tex-coords equal #faces *3 ?
3) In case of buildings why do we skip verts count*8 ? Where does the 8 come from?

1) afair I had no texture files so I don't know. Search for the texture files of a sample
(see my post of Aug. 29th about the B_Kinto_x strings in a dff) and you'll know it.

2)afair after 3 months is vertextcount==normalscount==texcount

3) did we skip? You really could help my if you gave me a quotation

(I'll go to sleep now...)

At 2) It is perfectcly fine for a vertex to have as many normals as the faces that vertex builds (preserve edges etc). Sake for tex coords, 1 vertx - many faces
At 3) You said : "For buildings there's some kind of 2nd texture coords block to be skipped ( verts count * 8 )". Where does the 8 come from?

[shakotay2]

At 3) You said : "For buildings there's some kind of 2nd texture coords block to be skipped ( verts count * 8 )". Where does the 8 come from?

Ok, texture coords block (must have overread this yesterday ).

2D texture coords x and y as floats, each float consisting of 4 bytes

[r3d]

Quite frankly I am a bit confused.

These are the first bytes of w_axe_01b.dff :

10 00 00 00 E7 6A 00 00 65 00 02 1C

The 10 00 00 00 pattern occurs in every file. I assumed it it to be skipped.
E7 6A 00 00 is the face count - 27367 I'm ok with that
but

65 00 02 1C in little endian is 469893221 . I mean THIS many vertices? Sth's gotta be wrong here.

[chrrox]

it might be 2 short values.

[r3d]

He said those are DWORDS

[chrrox]

he was just looking at the format quickly with a few samples.
online games tend to change model formats alot in the same games.
he most likely always saw the 2nd short value as 00 so amused it was a long.
did you look at the vertex section?
how much data is there i am willing to bet it matches the first short.

[shakotay2]

he was just looking at the format quickly with a few samples.
online games tend to change model formats alot in the same games.

Yep, that's correct. Thx, chrrox, for the clearing.

He said those are DWORDS

Atm I'm unsure about your intention.

If you read the thread carefuly you'll see that not all models are handled by the Mesh Viewer.
The crash course was about n_hmy_m_b2.dff
iirc I never saw this axe. Did the Mesh viewer extract w_axe_01b.dff correctly?

Guess no. So if you'll find that there are dozens of similar models I could have a look at them.
And maybe bug fix the viewer if required.
But as I stated somewhere above I won't handle every single dff separately.

Why do you think "65 00 02 1C" being the vertices count?
Did I post this? Then a quotation please.

For n_hmy_m_b2.dff it looks like this

050890 02 1C 01 00 00 00 48 0D 00 00 65 00 02 1C 37 00
0508A0 01 00 74 00 00 00 4C 00 00 00 01 00 00 00 6F ED

The bold bytes being the vertex count - 65 00 02 1C only being a pattern helping to find the start of the vertices block.

[r3d]

My I've never had such problem when the other person would just forget his quotes

face count DWORD
vertex count DWORD
unknown DWORD (01 000000?)

start of tex coords block
tex 2 floats

tri faces, indices f1, f2, 00, f3 unsigned ints // 00 00 to be skipped
gap of 24 bytes
vertices 3 floats
normals 3 floats

You described it as the file structre. The way people usually do it is that they just iterate through the structure. And if you mention first thing as DWORD I assume you stick to the way people usually do it and actualy mean the first 4 bytes as a DWORD face count. Well obviously it isn't as the first 4 bytes are 00 00 00 01. Though the next sequence might be