Jump to content
  • Advertisement
Sign in to follow this  
adder_noir

Had it with .x files! How can I render my own formats?

This topic is 2913 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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)

Share this post


Link to post
Share on other sites
Advertisement
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)

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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 :)

Share this post


Link to post
Share on other sites
Quote:
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.

Actually, the x file format is pretty well-defined and is, in fact, an ordered collection of data (vertices, normals, tex coords, etc.) which when put together (properly) comprise a DirectX mesh (either static or animated).
Quote:
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.

In general, you have the right idea. If you can't find a modeling program that exports x files to your satisfaction, use a format that the modeling program exports "safely" and use that data in some way.

Suggestion: thoroughly search this site and the web for discussions on importing/converting various formats. You will hopefully find stories of success and failure on various formats (such as collada which is suggested above) that will help you along.

You mention animation in your last post. If you want to use the DX animation functions for importing and animating (which I find convenient), I'd suggest first starting with static vertex buffers or meshes for conversion. Animation data is a whole different part of the file structure and differs significantly from mesh data. Search this site and the web for discussions about converting various animation formats.

Share this post


Link to post
Share on other sites
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)

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!