bdae to 3ds model

[lolbas]

I've tried to find any info about specified subject and the only cool thing I've been able to find can be seen here. The "import script", mentioned by GMMan, works for some GTR2 models which are also .bdae format. However this script doesn't work with any model from Order & Chaos Online.

I would be happy if I could manage conversion .bdae to .3ds by myself, however I have no idea on what model data to look for in .bdae file. Any suggestions that could point me in the right direction are highly welcomed!

In the attached archive you can find 3 models:
- staff_05 is a Staff weapon, looks more like a simple stick. Includes texture.
- 2 models for male elf body. No textures.

Thanks in advance!

[shakotay2]

The static meshes (FVFsize= 32) seem to be simple (though I found the staff to have a strange plane attached):

staff.JPG

For the elf (elf_m_h.bdae) use a FVFsize of 60.
H2O file:
0x2E02C 423
Vb1
60 24
0x2C8BA 100
020000
0x0 255

Where the uv pos (24) is unsure (uvs are just a square).
(hex2obj pproduces an obj file, which won't help you Iguess.)

[lolbas]

The static meshes (FVFsize= 32) seem to be simple (though I found the staff to have a strange plane attached):
...
Where the uv pos (24) is unsure (uvs are just a square).

Sorry for my pretty newbish question, but what does UV and FVFsize abbs stand for?

(hex2obj pproduces an obj file, which won't help you Iguess.)

My goal is to display models on a website using three.js. It supports .OBJ files so it seems like one of the possible ways i need

[shakotay2]

Google for UV mapping.
FVF is flexible vertex format. Its size is the offset from one vertex to the next one.

The parameter FVFsize helps to display the mesh. uv position (offset in FVF block) helps to display the uv map.

[lolbas]

staff.JPG

After a day of messing up with three.js and creating my very first simple model (manually adding vertices and faces) with the help of this doc, I think I am on the right way! So, as far as I understand, the .bdae model nested inside parent .bdae (which is actually a ZIP) contains vertices, faces and uvs for every face (sorry if terminology is used in wrong way). I noticed that FVFsize is 32 due to repeated "?" every 32 bytes in the middle of .bdae. So.. this 32 bytes contain all the nesessary information? By "all" I mean.. tbh I am not completly sure. My idea is that it might contain data like 3 vertices of triangle, a triangle sequence, maybe UV map and smth else... But this data starts at 0x8df and what are prior bytes for? It also leaves almost 700 bytes in the file end... Meh, could you please point whether I am in the right directions or not? Or explain what info to look within 32 FVFsize bytes . Grrr

[shakotay2]

... But this data starts at 0x8df and what are prior bytes for?

some strings, texture/material names, nodes - whatever, who knows

It also leaves almost 700 bytes in the file end...

Mostly face indices; the very last bytes look like a version.nfo file (if you decompress the bdae, which is not required)

Meh, could you please point whether I am in the right directions or not?

more or less, there are three floats (pos x,y,z) for the vertices and two floats for the uv coords (tx, ty), marked blue. (Maybe the remaining 12 bytes build a normal, didn't check it.)

I also marked the first two faces, which consist of 3 face indices each (where you have to add 1 to get the correct values for wavefront obj):

static_bdae.JPG

v -0.102100 -0.033354 -0.000709
vt 0.511508 0.932062
...

f 1/1 2/2 3/3
f 3/3 4/4 1/1
...

btw: the H2O file in my first post was intended to be used with hex2obj (view link in my sig)

[lolbas]

... the very last bytes look like a version.nfo file

Version data (the one contained in version.nfo within parent bdae) starts at 0x19c

(if you decompress the bdae, which is not required)

I don't get why! If I want to manually find out what does every byte means, shouldn't I first extract the model file itself?

there are three floats (pos x,y,z) for the vertices and two floats for the uv coords (tx, ty), marked blue.

This starts to make sense for me!

(Maybe the remaining 12 bytes build a normal, didn't check it.)

I tried playing around normals in three.js but I seem to not understand the purpose of it. If I have 3 vertices and connected them into triangle face, what would applied normal do?

v -0.102100 -0.033354 -0.000709
vt 0.511508 0.932062
...

f 1/1 2/2 3/3
f 3/3 4/4 1/1
...

And this makes not much sense right now... v stands for vertex, vt stand for ???, I also recall some blog mentioned vz or vy... F stands for face, but the following "1/1" etc give no idea what are they @-@

btw: the H2O file in my first post was intended to be used with hex2obj (view link in my sig)

Thought so. I downloaded this tool, yet I didn't get to try it out

[shakotay2]

(if you decompress the bdae, which is not required)

I don't get why! If I want to manually find out what does every byte means, shouldn't I first extract the model file itself?

This bdae is a zipped file without compression (at least the contained model doesn't seem to be compressed).

I tried playing around normals in three.js but I seem to not understand the purpose of it. If I have 3 vertices and connected them into triangle face, what would applied normal do?

"The normal is used by a shader when it's calculating the lighting."
(Most 3D applications are capable of recalculating normals from a given mesh - that's the reason why I didn't care for normals in hex2obj.)

You seem to understand/learn fast but we're going to hurry from one question to the other (next would be "what is a shader?", wouldn't it? ).

So you might google for normal mapping, wavefront object, 3D modeling to get more basic understanding.

And this makes not much sense right now... v stands for vertex, vt stand for ???, I also recall some blog mentioned vz or vy... F stands for face, but the following "1/1" etc give no idea what are they @-@

'vt' denotes the texture coordinates. vx, vy, vz are the components of a vertex v in 3D space.
f 1/1/1 2/2/2 3/3/3 is an abbreviation for three faces:
mesh face: v0,v1,v2
normal face: vn0,vn1,vn2
texture face: vt0,vt1,vt2
Since hex2obj ignores normals we've f 1/1 2/2 3/3 here.

(That's very simplified, though, but that's the way I explained it to myself. )
You could build a mesh of normals which would display as a sphere.
You can test this very easily in hex2obj by replacing the vertex start address by address +0x0C
(provided that the FVF looks kinda this: 3 floats vx,vy,vz, 3 floats vnx,vny,vnz, ...
so it doesn't work with the bdae files here.)


(For some practical exercise you could replace the first ten face lines in a wavefront obj file by
f 1/1/1 1/1/1 1/1/1 each then load the model to look how it's affected by this.)

[lolbas]

This bdae is a zipped file without compression (at least the contained model doesn't seem to be compressed)

I totally forgot about non-compressing methods.

next would be "what is a shader?"

Just a quick google search to make sure I knew it already!

'vt' denotes the texture coordinates. vx, vy, vz are the components of a vertex v in 3D space.

Why does vt requires 2 coord values: (I assume) x and y?

Well, I have a question I couldn't resolve by myself. Working with three.js to create a triangle we create 3 vertices, say A = (0,0,0), B = (0,0,1) and C = (1,0,1) and then a face data is supplied like: [0, A,B,C], where first 0 stands for "triangle" (1 for "quad"), and then our vertices. This will create a triangle visible from one side (oh, btw, how do I determine this? I seem to not understand how does order of connection affects figure visibility). But I don't see anything similar to this in FVF data!

[shakotay2]

Why does vt requires 2 coord values: (I assume) x and y?

yep - it's a 2-dimensional (texture) map

This will create a triangle visible from one side (oh, btw, how do I determine this? I seem to not understand how does order of connection affects figure visibility).

It's a matter of winding: you can define the order of the vertices clockwise or counter-clockwise. For example f 1 2 3 versa f 1 3 2.
Then it's a matter of your 3D app whether to draw or not to draw a face onto the screen.

[lolbas]

I also marked the first two faces, which consist of 3 face indices each (where you have to add 1 to get the correct values for wavefront obj):

static_bdae.JPG

How did hex2obj programmatically finds the first face? I tried to find some logic within first bytes but finished with no luck...

[shakotay2]

How did hex2obj programmatically finds the first face?

it does not - you may search for 000001000200 in a hex editor. Works in most cases; sometimes there a multiple finds in case the model has more than one submesh.

[lolbas]

How did hex2obj programmatically finds the first face?

it does not - you may search for 000001000200 in a hex editor. Works in most cases; sometimes there a multiple finds in case the model has more than one submesh.

Does hex2obj allows you to determine amount of vertices, faces and uvs? I am trying to find this data within .bdae file, the file contains odd 8-byte values starting at 0x50 and their amount varies from model to model, I have no idea what they might be, aside from my understanding that they are pointers to some specific data sections (actually, usually they point to 5-10 consequent 8-byte values stored in different parts of file).

Also, your first reply contains info about first FVF data. However bdae header has the closest pointer 40 bytes before it (5x 8-byte values), do you happen to know what they might be?

[shakotay2]

Does hex2obj allows you to determine amount of vertices, faces and uvs?

amout of vertices is (in most cases) equal to max face index which is provided by hex2obj provided that you give it the correct face index count (understand that there might be 336 face indices with a max face index of 197 only).

uv count is equal to vertex count in most cases, so you'll need to find the face index count, the 336 above.

Using the 'table' button might reveal helpful infos (or not):

Code: Select all

startaddress taken from go1 editbox
address 0x59a:
  197    40     1   152 be09a49c bfae2196 be09a49c 3e09a49c 
3f069b7c 3e09a49c     0    32     3    48     3    56 
    3    64     3    72     0  2240     0     0 
    0     0    12    24     0     6     6     6 
    0     3     3     2     0     0     0     0 
    0     0     0   428     0   112 ffff0100 ffffff02 
ffffffff ffffffff 65535     0   196   336     0  8552 

(197 vertices, 336 face indices)

Also, your first reply contains info about first FVF data. However bdae header has the closest pointer 40 bytes before it (5x 8-byte values), do you happen to know what they might be?

It would be helpful if you provided a picture from the values you're talking of.
But guess I can't tell it.

The way it goes (for me) is this: you find a data your sure of, for example the vertex count.
Then you search for the address value pointing to it. Sometimes these addresses are absolute offsets, in some cases they're relative.

This approach fails if the data is part of a table where you'll have to find the starting point of the table then.

[lolbas]

Also, your first reply contains info about first FVF data. However bdae header has the closest pointer 40 bytes before it (5x 8-byte values), do you happen to know what they might be?

It would be helpful if you provided a picture from the values you're talking of.

Here they are. The header field points to the start of selection. The first bytes after selection have been recognized by you as start of FVF data.

(197 vertices, 336 face indices)

FVF data is 6304 byte long (length does not specified by header info) and thats 197x32 byte (considering FVFsize = 32), just like you said. But I dont understand how could you say for sure that this value at this offset means amount of vertices! And also, why exactly this offset?