[Research/Tool] The .XAC to .DAE Converter Project (and .xmf to .obj/.dae)

[Lc4Hunter]

@hhr: Is there any chance to make the tool able to read the scene-files and import all necessary parts and the textures?

it is likely that someone else will do it, but i'm not interested.

Thanks for the info. Of course it´s your decission and i respect that

as it seems there are no mapping-coordinates on the mesh

no UV is only in *-collision.xmf, in all other models it is.
open the .obj and look for the lines starting with "vt ", this is the texture coordinates.

Ok, but shouldn´t it be also imported into Max when loading the obj-File?

[Staberind]

"(.xmf is probabily used simple as a short for xml mesh format)"

Yeah, I have ascertained that XR seems to use the same formatting and extensions as cal3d, however, I am a little out of my depth here, as all of my work regarding mesh & texture creating/modding is based on .nif/.obj and dds, with mesh work done in something like zbrush, I am still learning 3ds max and or blender.
while .DDS is what XR uses, .obj, .3ds or blender stuff is what I'd like to be working with, thus paying great attention to this thread, as that B.9 model is awesome, I wish to make a shedload of Xenon, Split, Kha'ak Boron et centera, M5 to M0 to that level of detail, but after 30 years of A. being cut off, and B. less drive to advance in competition, I am wondering what kind of hulls and weapon evolution would happen aside from below:
If the Split are competing with Xenon, and the B.9 is the Xenon result, the split must have some heavy tech to resist being obliterated.

[ThalonMook]

Hi All,

I have made some little changes to the xfm2obj.lua so that it will write the right textures and path to the mtl file.

After importing to Max they are now found but not right mapped.


Before:

Code: Select all

newmtl generic_generic_tech_01

Ka 0.00 0.00 0.00
Kd 1.00 1.00 1.00
Ks 1.00 1.00 1.00
Ns 4.0
illum 2
map_Kd tex\generic_generic_tech_01_diff.tga
map_Ks tex\generic_generic_tech_01_spec.tga
map_bump tex\generic_generic_tech_01_bump.tga

After:

Code: Select all

newmtl generic_tech_01

Ka 0.00 0.00 0.00
Kd 1.00 1.00 1.00
Ks 1.00 1.00 1.00
Ns 4.0
illum 2
map_Kd textures\generic\generic_tech_01_diff.dds
map_Ks textures\generic\generic_tech_01_spec.dds
map_bump textures\generic\generic_tech_01_bump.dds

Here the file:

http://www.tzd-online.de/XRB/xmf2obj.7z

Cu Thalon

[hhr]

it will write the right textures and path to the mtl file.

it does not help, since the name of the material and textures do not always same. example: collection "generic", material "generic_tanks_01", but texture path "assets\textures\Argon\ar_hulls_02_diff".

After importing to Max they are now found but not right mapped.

UV-map of "assets\units\size_xs\units_size_xs_albion_mining_data\part_main-lod0.xmf":

[ external image ]

compare with what you got

[Lc4Hunter]

I tried the same with the Xenon-destroyer lod0-mesh, but i also have no mapping coordinates, no Material IDs or something else.
I´m sure there must be a solution because i know Egosoft is using a max-import/exporttool for that.

What program did you use for the small masstraffic-ship? I see the mapping-coordinates are correct on your ship...

[hhr]

there are many free editors and tools that I use:

• AssimpView for fast viewing
• LithUnwrap (google for links) for UV-editing
• Sketchup (free version) with OBJ-importer
• Anim8or also can import OBJ with materials

[ external image ] . [ external image ] . [ external image ] . [ external image ]

so I'm surprised that 3DSMax can not work with a simple OBJ-format.

[Staberind]

there are many free editors and tools that I use:
*Snip*
Goodies
*/Snip*

so I'm surprised that 3DSMax can not work with a simple OBJ-format.

There are a few other uv mappers as well, you can even hand map uv's yourselves although its a pain,
If I modify something beyond a certain point, I have to re-uv something, or set up a seperate texture path, then develop a new tex, then map that, basically, I have a lot of bad habits formed from botching something.

also, HHR, Спасибо за сюрприз подарунки .., I will yoink those as well.

[TargetLost]

you can try to convert the .obj file with noesis into any format that the 3d max likes better.

I just googled it again and it seems that this is the link of the noesis tool.
http://oasis.xentax.com/index.php?content=downloads

(can't remember anymore where I downloaded my one from so be a bit carefully)

[ThalonMook]

Hi All,

so now I tested it with Assimp View. Thx to hhr for the link to the tool.

I used my changed xfm2obj.lua and coverted a ship, then I opened it with AssimpView.
The textures where not shown. Normal cause the viewer don't know the right place where the textures are.

Then I exported it as Wavefront OBJ now I was able to import the ship in Max with all textures shown right.

2nd test with the original xfm2obj.lua no textures cause the names and the path where wrong for Max.

[ external image ]



*edit*
Ok it's a little more tricky to geht the model right into Max.
I converted it with the lua script then I opened it with AssimpView.
There I changed the textures with 'replace texture' form the textures I extracted form XRB in the same folder structure. Some times the names are wrong so I had to find the right one.
After this when the model was right in the viewer I exported it as OBJ and opened it in notepad++ there I changed the one wrong texture name, same in the MTL.
Now I opened it again in AssimpView and saved it as Collada.
Now I was able to import it to Max with all parts and right textues.

Here the Xenon K a sample:

[ external image ]

I hope I can find out a better way

CU Thalon

[Lc4Hunter]

well, usually Rebirth can handel obj-files but there seems to be something with the generated files Max has a problem with.
Will see if i find some advanced Obj-Importer for Max and test it again.

[Scrappy Coco]

Hey Guys,

how are you doing ? I still am very interested in this threat so I just like to *bump* it. My project is trying to biuld a import export in maxScript with the specs of arc_. MaxScript is very anoying. And everything is so time consuming. Ok enough from me. Have a nice X-MAS !

Cheers Scrappy Coco

[ external image ]

[Lc4Hunter]

Hy Scrappy,

i like your idea very much because i´m also a Max-User
I would like to help you with that but i´m not really good in programming and/or MAX-Script
But i hope you will continue your work.

Is that screenshot below your progress with that? If yes: wow!

[TargetLost]

Sry my Job keept me busy last week and I had hardly time for this project.

I am still trying to find motivation by playing the game but it let's me down big way to the point to drop it completly. Also after the plot it turns out to be most time unplayable and therefore not enjoyable. I get more and more doubts that mods can change this.
The question for me is..shall I really invest in something I can't enjoy?

I will code as much as I still feel confortable with but I worry that I might not make it to a functional tool but just a base framework.

@arc_

a small thing:
chunk B: node hierarchy (v1)
...

NodeData[numNodes]
...
int32 unused[3]
...

this int32 unused[3] seems to be 3 floats and not int32 and with the values -1.0

[arc_]

Changed. Though it doesn't really matter since the fields are unused anyway (the game code just reads them from the file and throws them away).

I also don't enjoy the game itself at all - getting the stuck drones bug in 1.17 was the last drop for me, I haven't played it since then. But I enjoy reverse engineering and programming, so now I do that instead. Also there are people on this forum who do want to invest in the game, and they are waiting for conversion tools.

I updated the XMF spec with details about the material assignment (formerly "attribute ranges"). There are now no unknowns left about this format; I'm currently working on a "proper" .xmf <-> .dae converter that handles all of the format's oddities (multiple vertex buffers, multiple materials, different types of vertex declarations etc) that hhr's script doesn't yet support.

[hhr]

(multiple vertex buffers, multiple materials, different types of vertex declarations etc) that hhr's script doesn't yet support.

OBJ format doesn't support these features, not script ;)

I updated the XMF spec with details about the material assignment (formerly "attribute ranges"). There are now no unknowns left about this format;

updated where?

[arc_]

If there are multiple vertex buffers in an .xmf file, each buffer just contains different attributes for the same vertices. i.e. instead of having a single vertex buffer layouted as (v0.pos, v0.normal, v0.texcoord, v1.pos, ...) you have one buffer containing (v0.pos, v1.pos, ...), a second buffer containing (v0.normal, v1.normal, ...) etc.

If there are multiple materials in the .xmf, each material applies to a different section of the mesh (each polygon still only has one material assigned). So this is a matter of splitting up the mesh into parts, one part per used material. I'm using the assimp library to read and write .dae files, which has the same "one material per mesh" restriction

Spec is at the same location as before: https://dl.dropboxusercontent.com/u/60681258/xmf.txt

[hhr]

but it is not a complete format:
VertexDeclElement[16] may also be VertexDeclElement[148]
your D3DDECLUSAGE is different from Microsoft D3DDECLUSAGE

[arc_]

A DataBufferDesc could never contain 148 vertex declaration elements. The size of a single DataBufferDesc is stored as a byte in the header, and if you had 148 VertexDeclElements, you would need 1184 bytes for those alone... That number doesn't fit in a byte.

The table with the "type" and "D3DDECLUSAGE" columns in the spec is a mapping table. So if a DataBufferDesc has numVertexElements = 0 and type = 8, this means it actually has 1 vertex element of type D3DDECLUSAGE_COLOR (value 10). For VertexDeclElement, no such mapping is needed (the type there is already a D3DDECLUSAGE).

[hhr]

look at this simple cube - \assets\units\size_xs\unit_size_xs_escapepod_data\assets_units_size_xs_unit_size_xs_escapepod-collision.xmf

[arc_]

That file has numVertexElements = 0, so a single vertex element of type = 0 -> D3DDECLUSAGE_POSITION and format = 2 -> D3DDECLTYPE_FLOAT3 (which matches itemSize = 12).

The dataBufferDescSize is 0xBC as always, and so the index buffer (which follows the single vertex buffer) starts at 0x40 + 0xBC as usual. In fact the entire file is only 536 bytes long.

I should add though that in some cases, dataBufferDescSize may be *less* than 0xBC. In this case, all the DataBufferDesc fields that are not in the file should be implicitly set to 0.