.bdae models from Order & Chaos 1/2

[moonpaladin]

Hello! I have searching for some days a script to open this kind of models and finally got one that suit with this kind of version of this game, and it worked really well in many models, but when I unpacked the order & chaos 1, the script doesn't open it, seems that is different version. I was trying to modify it according of what I thinking it make script fails, but seems that I'm adding bad values into the script, because it thrown vertices calculation error. Hope someone can take a look !please! I will attach the script with some models (one that work and the others that didn't). Thanks for read!


https://www.mediafire.com/file/r5gy1vcy ... e.zip/file

[shakotay2]

Revising this bdae format gives me a headache so I decided to create a tool for getting some H2O params to use with hex2obj.
Find the Make_bdaeParams.exe file in Rel_FH\bin\release.

It creates a Make_H2O.log like such (from 228.584 bytes bdae):

Code: Select all

start of FIs at 0x1948c, FIcount= 4066

1562 max face index (= vertex count)

startof vertices approx. at 0x3ed4

(No H2O file created! Function SM_of_bdaePar_loop() not included in source, maybe later.)

Tested with 2 of those error bdae files only. So don't blame me if the tools fails on others.
.

Make_H2O-bdaeParams.zip

[moonpaladin]

Revising this bdae format gives me a headache so I decided to create a tool for getting some H2O params to use with hex2obj.
Find the Make_bdaeParams.exe file in Rel_FH\bin\release.

It creates a Make_H2O.log like such (from 228.584 bytes bdae):

Code: Select all

start of FIs at 0x1948c, FIcount= 4066

1562 max face index (= vertex count)

startof vertices approx. at 0x3ed4

(No H2O file created! Function SM_of_bdaePar_loop() not included in source, maybe later.)

Tested with 2 of those error bdae files only. So don't blame me if the tools fails on others.
.
Make_H2O-bdaeParams.zip

Thanks Shakotay, I were able to get the meshes with hex2obj, but I'm not sure about the FVFsize value yet, at least for the little_endian_not_quantized_error.bdae.

little_endian_not_quantized_error.png

Here is another weird .bdae model that I found, it should have the form of a bear, I were trying to get the model and his uv with hex2obj but had no success.
https://www.mediafire.com/file/6cdsx6s5 ... .bdae/file

[moonpaladin]

@Shakotay! I were checking the models and are some that seems really weird, could be that they have submeshes with different textures, I will attacht two more samples, I was able to get the main body of the horse but without front legs xD.

https://www.mediafire.com/file/z0lcoaq4 ... 2.zip/file

[shakotay2]

(well, forgot to mention the FVFsize, which was 56 for the first tested 2 models)

Thanks Shakotay, I were able to get the meshes with hex2obj, but I'm not sure about the FVFsize value yet, at least for the little_endian_not_quantized_error.bdae.
little_endian_not_quantized_error.png

I have no idea WHY you used 19486 (the h is superfluous, btw, 0x is used internally to assure hex)
and 4074 as a count while the log is like such:

Code: Select all

start of FIs at 0x1948c, FIcount= 4066

1562 max face index (= vertex count)

startof vertices approx. at 0x3ed4

.

Warg_whatever.png

Here is another weird .bdae model that I found, it should have the form of a bear, I were trying to get the model and his uv with hex2obj but had no success.

mechanical_bear_03 is too hard atm.

[shakotay2]

(Assumed vertex start address for models with more than one submesh is wrong so far.)

@Shakotay! I were checking the models and are some that seems really weird, could be that they have submeshes with different textures,

Complex models not handled by the app!
Plus, the assumed vertex start address is false then (that's why it's named "approx." but in fact, it's pretty wrong often )

(The horse is harder, unhandled so far.)

The magpie's assumed vertex start (1st sub mesh, 0xb2e4) is logged wrong, correct is (0x) 5BD4,
the second submesh gettable with some basic understanding:
.

magpie_mount.png

************
(For those who try the bdae samples: some of them require the header to be deleted so that the files start with "BRES".)
************

[moonpaladin]

(Assumed vertex start address for models with more than one submesh is wrong so far.)

@Shakotay! I were checking the models and are some that seems really weird, could be that they have submeshes with different textures,

Complex models not handled by the app!
Plus, the assumed vertex start address is false then (that's why it's named "approx." but in fact, it's pretty wrong often )

(The horse is harder, unhandled so far.)

The magpie's assumed vertex start (1st sub mesh, 0xb2e4) is logged wrong, correct is (0x) 5BD4,
the second submesh gettable with some basic understanding:
.
magpie_mount.png

************
(For those who try the bdae samples: some of them require the header to be deleted so that the files start with "BRES".)
************

Cool! you got the second submesh! I'm gonna be trying today! thanks Shakotay!

************
(For those who try the bdae samples: some of them require the header to be deleted so that the files start with "BRES".)
************

Yep! just unzip the model!

[moonpaladin]

Got the magpie first submesh! next is the horse and for last the bear that seems harder .

success58.png

thank you Shakotay, you increase my thoughts haha

[moonpaladin]

(The horse is harder, unhandled so far.)

First Submesh of Horse

[moonpaladin]

@Shakotay, maybe could you take a look at this model, it seems like the halloween_horse model , but is really weird the values seems correct, but could be that this big mesh contain the submesh, thats why that submesh looks really bad. Could be that submesh had a different FVF size? cool to learn how to handle this models.

error32.png

https://www.mediafire.com/file/3vyn4llm ... .bdae/file

[shakotay2]

For the addresses:

the h is superfluous, btw, 0x is used internally to assure hex

the h is superfluous, the h is superfluous, the h is superfluous, ... because
###################################
0x is used internally to assure hex
###################################

First Submesh of Horse

You know that it's not the first sub mesh which is the problem, do you?

This is the H2O file in question, (same proceeding as for buck_elf) but the resulting mesh is partially wrong, dunno why:

0x2477C 6970
Vb1
56 24
0x4D44 2244
020000
0x0 255

--------------------------------------------------------
Good find: 60 as the FVFsize for the buck_elf! (Seems you're making progress. )

But start of vertices is (0x) 450C, plain to see with some experience because there's the starting marker 01000000 in front of that address.

edit: ok, the tool's info refers to header less bdae files, so do my pictures, while moonpaladin uses "raw" bdae files (with a PK header of 0x3F bytes size) ------------------------------------------------------------

Second sub mesh of the buckelf is simple, why didn't you find the start address of the 2nd face indices block?
.

buck_elf.png

.
btw, the log

Code: Select all

1 start of FIs at 0x1ec6a (unsupported)

is a fake find, it's 0000 0100 0200, but nothing more, so not a start of another face indices block.

[moonpaladin]

For the addresses:

the h is superfluous, btw, 0x is used internally to assure hex

the h is superfluous, the h is superfluous, the h is superfluous, ... because
###################################
0x is used internally to assure hex
###################################

First Submesh of Horse

You know that it's not the first sub mesh which is the problem, do you?

This is the H2O file in question, (same proceeding as for buck_elf) but the resulting mesh is partially wrong, dunno why:

0x2477C 6970
Vb1
56 24
0x4D44 2244
020000
0x0 255

--------------------------------------------------------
Good find: 60 as the FVFsize for the buck_elf! (Seems you're making progress. )

But start of vertices is (0x) 450C, plain to see with some experience because there's the starting marker 01000000 in front of that address.
(Will take some time till you get such things, I guess?)

Second sub mesh of the buckelf is simple, why didn't you find the start address of the 2nd face indices block?
.
buck_elf.png
.
btw, the log

Code: Select all

1 start of FIs at 0x1ec6a (unsupported)

is a fake find, it's 0000 0100 0200, but nothing more, so not a start of another face indices block.

Cool! gonna check it today! the mechanical_bear is left, that one is different than all those models

Good find: 60 as the FVFsize for the buck_elf! (Seems you're making progress. )

But start of vertices is (0x) 450C, plain to see with some experience because there's the starting marker 01000000 in front of that address.
(Will take some time till you get such things, I guess?)

I was working with the .bdae without unzip it xD

[shakotay2]

I was working with the .bdae without unzip it xD

Ah, well, ok. Most important information! You should have mentioned it to not confuse people!

Or I could include some info into the tool (while with 2 downloads only seems not too many users are affected ).

[moonpaladin]

lmao I'm retarded, it was there the whole time! thankssss @Shakotay!. Found the Halloween horse meshes.

halloween_horsefull.jpg

[shakotay2]

cool! (Obviously I was too lazy to do a decent search ):
.

horses_submesh.png

.
(The tool starts its search after the first 00 00 and stops after the next one, so it misses the following face indices block.)
I really should have searched for 01000000 but there's a small risk that it's face indices, not a startOfBlock signature.