Hi,

Long story short wasted looooaaaaddddssss of time trying to get any one of a number of graphics programs to properly export a .x file. Gone right into the file format myself even produced code tools to strip them so I could read them more easily on and on and on. I am absolutely sick to death of this method. None of the available converters do a proper job nor do the export functions from any major 3d modelling programs.

So it's time I think to bite the bullet. I'm going to have to learn how to render stuff myself which gives ME control of what's going not hoping someone else wrote decent exporting code (which they didn't).

But I don't know where to start. I'm quite familiar with DX9 and all that stuff but I haven't got a clue how to render something without the handy draw functions from DirectX.

All I need is a small bit of info, even a book to buy that would be enough. Seriously help! Where do I start?

Thanks ;o)

have you looked into using collada?

I'm thinking that if I make my own format or use a well known existing one would it run something along the lines of writing my own functions that extract mesh and texture co-ordinate data which I then load into the graphics API?

Is that how everyone else does it? If so what is the most reliable format that Blender exports? 3DS Max maybe?

Trying to get .x files out of modelling programs and into direct X reliable is a waste of time it appears.

Someone must know surely, until I know the right path to walk down I can't get started ;o)

Thanks for the reply mate I really do not want to go the route of conversion software anymore. I'm told the proper way to do it is do it yourself anyway. Thanks tho.

If you want to use a custom format for mesh data, you need to first decide what that format will be. Then you need to be able to produce instances of data in that format -- this will involve either:
1) hand-generating the data
2) writing custom exporters from your modelling tools
3) writing conversion tools to transform data from an existing model format to your own.

(1) is generally intractable for nontrivial data. The complexity of (2) is largely determined by the quality of the extensibility interface to your modeling tool and how well you understand the tools conventions (you will soon see why it's very difficult to get an .X exporter to export data in exactly the format you might expect if you take this approach). Option (3) is probably not interesting to you since it doesn't solve your problem, which appears to be with the source of the model data and not the format itself.

That makes writing an exporter the only real option if you really want a custom format. It's probably easier to simply load a format the modeller exports well and reliably -- and do note that just because the data exports slightly differently than you might expect does not mean the exporter is broken. Formats like .X are pretty general by design.

Thanks for the reply. So if I've got this right, a .x file is not simply a collection of data written under specific string headers such as MeshNormals or MeshTextureCoords or whatever.

The way the actual data is/can be written is variant regardless of the order of headers of each data block.

This would mean I assume that the actual data that ends up in a .x file can be quite varied.

Solution then as you say if I've got it right - find a file that the modelling program (Blender in this case *might* upgrade to 3ds max) exports safely that isn't vary variant such as 3DS max and convert it piece by piece with code into a .x file.

It would mean I can still use all the animation and draw functions I know well in DirectX.

Have I got the right idea? I would appreciate it if someone could confirm if I have or tell me if I'm wrong. Thanks :)

Hi,

Some very good replies there thanks I'll vote you all up after I've typed this out.

Dear Buckeye,

That's very interesting indeed. I don't want to write off anything just yet and I know the .x format rather well now(although I could/will learn more). Can I ask this. I noticed in the exported .x file from the modelling program that it does not order the datablock headers the same way tiny.x (Microsofts demo .x file) does. Tiny arranges hers along the lines of:

Mesh{
MeshNormals {}
MeshTexture Coords {}
VertexDuplication Indices {}
MeshMaterialList {
Material {
(texture file name)
}
}
XSkinMeshHeader {}
Skinweights {}
}

Whereas the exported .x file from blender has them in a totally different order. The materials come before the normals. It is interesting to note that the big problem I've had so far is related to materials being screwed up. Could it be a bad ordering of datablocks in the file which is responsible for this?

With regarda animation I was hoping (perhaps rather naively) that all that was exported were joint-offset matrices and keyframe matrices.

I'm still not sure what to do here to be honest. Is it possible the .x file I have is fine just the datablocks aren't ordered correctly? Or do I really have to start looking to the safest format to start converting to my own .x file? This would be no doubt .3DS format.

Dear Anddos

Thanks I have now found that website and he gives a very good tutorial for loading data into a .x file. Should come in very handy if/when I come to convert a .3DS into it ;o)

Quote:
Whereas the exported .x file from blender has them in a totally different order. The materials come before the normals. It is interesting to note that the big problem I've had so far is related to materials being screwed up. Could it be a bad ordering of datablocks in the file which is responsible for this?

The ordering of templates in the file is not strictly defined; your code needs to account for this in order to properly load all X files. The only time order matters is if a template refers to a data type/template defined elsewhere, in that case you are only allowed to reference templates defined previously.