7 replies to this topic

[BradP]

I'm trying to work with the .X File format and it seems to cause more headaches for me than I was hoping.

I am trying to setup my data structures in my new engine to do a lot of resource sharing to save memory, time, ect. I'm tired of loading 5 copies of a mesh to satisfy 5 texturally different copies of the same object.

For example: One player mesh with alternate textures like in the good old Quake days. I would rather not lose the ability to define subsets of meshes with various textures and materials. I also want to be able to load this into a progressive mesh so I can wasily take advantage of Hoppes built in LOD algorithms.

My only idea so far was to load the mesh as normal and search the directory for any texture that uses the referenced texture filename as a prefix. tiger.bmp = tiger_v2.bmp, tiger_v3.bmp, ect. This gets complicated and confusing when dealing with meshes with multiple materials and subsets.

Does anyone have any advice they would like to share? I'm feeling constrained by the file format. Thanks.

[Bob2u]

You can have your resource sharing and management separate from your model loading. The idea is simple, when you load a new .x mesh you will break up into its component information (mesh, texture, effects, etc) and just save an Id/smart_pointer to the data.

The .x file format can just be treated as a container for batches of information coming in at once (mesh, texture, effect, etc), and your objects in your engine can mix and match these loaded information independent of each other.

Here is an example of what i mean:

- load Model.x (contains ship verts, indx, TextureA, ...)
- Save mesh and index info in a global asset manager as mesh id 1 (just an example)
- Save TextureA as texture id 1 in a global asset manager.
- Load another texture, TextureB, as texture id 2 in a global asset manager.
- Create a game object that references mesh id 1 and texture 1 for original model loaded.
- Create a game object that references mesh id 1 and texture 2 for same model different texture. (assuming your texcoords map correctly)

Hope this gives you an idea and let me know if you need more info.

[Alerion]

I think there is another question here more basic than the specific issues regarding the .X file format. Are there any inherent drawbacks or benefits to using any particular file format? Would any particular game be crippled due to using .X? I have to admit using it, especially for the beginner, is extremely tempt[ing], but I got a bad taste in my mouth from looking at other peoples projects. Maybe I'm wrong, but .mds (or is it md5 or something?) models and Quake .BSP files for architecture are wildly popular. Even in the DirectX community I haven't seen many people drawn to the .x file format. I know using .BSP gives the added bonus of allowing for ellipsoid v brush collision detection ( I only know this from reading I've done not from actual experiance lol) or some such.

Basically the question is, is there a good reason to abandon the eas[e] of use [provided by] .x files for something other formats might bring to the table (what they bring I do not know, and is part of the question I suppose haha)

Just curious
-Ally

edit: fixed some grammar. wow I must've been drinking.

[Mattias Gustavsson]

Regardless of which file format is used, it is important to make a clear distinction between the source data as read from the file, and your internal representation of this data as used by your engine at runtime. This enables you to change file formats or add support for additional ones, without affecting your render code.

When using .X files, this means converting the data to your own structures (either at load time or as an offline conversion step) and then creating the index/vertexbuffers yourself. It might seem like a lot of extra steps, but the advantage of having your models behave exactly how you want them to, without caring what file format the data originated from makes it well worth it.

Personally, I use .X, .obj and .fbx (which I quite recently discovered, it's worth checking it out), for the simple reason that I already have objects in all those formats which I want to use. I convert them to my own file format as a separate conversion step (except for models I export from Milkshape, for them I have a custom exporter for my engines internal file format). But if you're worried about the extra step, you could always build support for converting the data directly into your engines model loading code.

[rouncer]

Converting to your own format is a good method of doing it, its not too hard
to write a converter program, i say thats the best way to go about it then
you have everything where you want it.

[monjardin]

Isn't FBX a closed/proprietary file format?

[Mattias Gustavsson]

http://usa.autodesk....3112&id=6839916

[monjardin]

I just see an SDK. Is the actual file format specification available?

It really doesn't matter if it is just an intermediate file that you are converting to a custom format to load into your game, but you are locked into the converter from Kaydara/Alias/Autodesk. I just wanted to point out the differences between the X and OBJ formats where you can parse the file directly. Of course, simply using the FBX SDK probably saves a lot of time. ;)