Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

Jiia

X File Parsing Nightmare

This topic is 5243 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

I'm having serious problems. I can't seem to seperate x file parsing into individual cpp modules. I include this at the top of each file that needs to parse data: #include <rmxfguid.h> #include <rmxftmpl.h> And all hell breaks loose. I can only have one instance of it, or I get "already defined" crap. But if I don't include them in each cpp file, the template types are undefined. I even tried to create a File Parser object which was contained in one file and parsed things for everything else. This also didn't go well, because the D3DXLoadSkinMeshFromXof method returns that it has no bones. I'm assuming I must call D3DXLoadSkinMeshFromXof from within parsing blocks for it to work correctly, and can't just save a IDirectXFileData object to load it. So then I decided that my parser object could just go ahead and load each type of template, and let the objects grab it. But I cannot find a way to determine if a mesh (TID_D3DRMMesh) is a skinned mesh (to use D3DXLoadSkinMeshFromXof) or not (to use D3DXLoadMeshFromXof). What a headache. Can someone just shoot me? [edited by - Jiia on June 10, 2004 10:02:02 AM]

Share this post


Link to post
Share on other sites
Advertisement
You messed up big time!
First of all, try to load the Tiny.x file included with the SDK. Anyway - you only get number of bones, if you include the CAllocationContainer class that is included in the tiny.x (Skinned Mesh sample). There are tons of same samples of loading that stupid .X file. There is no other way arround with that function, except, you create your own scene graph file with the D3DXFRAME structure (which represents a node in a directx scene graph). If you consider to write your own skinned loader and you would like to use HARDWARE T&L SKINNING like in the Direct3D SDK, you will end up, that on the end, it has to be allways in memory like an .x file. That''s how it is.

Share this post


Link to post
Share on other sites
I can parse x files. I can load a skinned mesh in and animate it. I can also parse x files to load in standard meshes, or groups of standard meshes from a single file.

The problem is that I can't seperate the cpp files for each type of loader. For example, I can't have StandardMesh.cpp AND SkinMesh.cpp, with different parsers. The template includes seem to be defining inline data, so it gets included how many ever times I include the header.

Also, when I decided to make a XFileParser.cpp type module to be used by both StandardMesh.cpp and SkinMesh.cpp, I have no way of knowing if a mesh in an X file is skinned or not.

The only way I know around this is to load it in as a SkinMesh (using D3DXLoadSkinMeshFromXof) and just dump off the skinning info if it has no bones. I didn't know I could do this when I posted, but it still erks me that I can't know before I load.

No way of asking IDirectXFileData what type of information is included with the mesh?

Thanks for the reply, though.

EDIT: I'm not using CAllocationContainer or anything based on it. Just a recursive object oriented loader.

[edited by - Jiia on June 10, 2004 1:14:08 PM]

Share this post


Link to post
Share on other sites
Well, there''s a couple things you can do.

You can keep a separate list of which files contain what. Might not work if you''re making tools, but even a moddable game could have the modder specify the appropriate things.

Or, you could place an object at the top of each x file that specifies what kind of object it is, and hand off parsing after reading that first object.

Or, probably best, is to just not have separate loaders for each type. Design your data system to either include skinning information and bones or not, and your single loader can detect what''s in the file and fill it in. D3DXLoadMeshHierarchyFromX() works like this, in that the callback to create the mesh container will either contain a valid pSkinInfo or NULL, depending on whether there is skinning information available, but lets you create a mesh either way.

My spoon is too big.

Share this post


Link to post
Share on other sites
Welcome to the wonderful world of skinned meshes.
Firstly, your problem with the header files. The problem should only occur when you have multiple
#include <rmxftmpl.h>
in your project. My solution to this? Don''t use it. Header files should never contain data, otherwise linking becomes a problem (as you have found out).
So what to do instead? Well, I have a common include file in my project, but you could localise to just your skinned mesh .h file.
In it you need :
#define D3DRM_XTEMPLATE_BYTES 3278
extern unsigned char D3DRM_XTEMPLATES[];
Then cut and paste into the .h file''s .cpp partner the definition of D3DRM_XTEMPLATES[] from in the rmxftmpl.h.
Basically, in any header that requires this definition, then just use the extern. The linker should not complain.
If this hasn''t made sense, let me know.
As for your loading concerns, after using D3DXLoadSkinMeshFromXof, you can test against ->GetNumBones() for the resulting skinned mesh. If this value = 0, then just store the ->GetOriginalMesh(&mshPose) from the skinned mesh object.
Let me know how it goes.
Steele.

Share this post


Link to post
Share on other sites
quote:
Original post by RenderTarget
and your single loader can detect what''s in the file and fill it in

But that''s the problem. I don''t know how to detect what it is until I load it.

quote:
Original post by Crow-knee
As for your loading concerns, after using D3DXLoadSkinMeshFromXof, you can test against ->GetNumBones() for the resulting skinned mesh. If this value = 0, then just store the ->GetOriginalMesh(&mshPose) from the skinned mesh object.

Hmm. I''ve never seen that method. What interface? I''ve heard skinning objects were tied together with the mesh in D3D8. Is that what you mean?

My mesh comes completely seperate (from what I can tell) from the skinning attributes. But doesn''t it seem a little odd to use D3DXLoadSkinMeshFromXof for every type of mesh? I would love to have a D3DXWhatKindOfMesh method

Thanks for the help.

Share this post


Link to post
Share on other sites
quote:
WHy not just use headerguarding? That will get rid of the ''already included'' hell.

Example

#ifndef MY_FILE_BLA
#define MY_FILE_BLA

#include ..

..

#endif


That wont work in his situation unless he only includes rmxftmpl.h in one and only one cpp file.

The thing is that rmxftmpl.h has actual data defined and set in it (as Crown-Knee) said), and the data is not const. So for instance if you have file A.cpp and B.cpp, and C.h is included in both of them, and C.h has something like

int a = 0;

defined in it. You''ll get the problem he''s speaking of and header guards wont help you. Again what crown-knee suggested should work. (has it Jiia?)

Jiia:

Make a xinclfile.h and xinclfile.cpp and then add

#include <rmxftmpl.h>

to xinclfile.cpp, and add

#define D3DRM_XTEMPLATE_BYTES 3278
extern unsigned char D3DRM_XTEMPLATES[];

to xinclfile.h. Then instead of including rmxftmpl.h wherever you want to use xfile, include xinclfile.h instead.


| TripleBuffer Software |
| Plug-in Manager :: DX Utility Engine :: C++ Debug Kit :: DirectX Tutorials :: Awesome Books |

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Hi I haven''t got to this stage yet, I''m just working with static xfies/meshes, but I think this is something similar to what the guys are saying

http://www.etc.cmu.edu/panda3d/docs/PandaDox/PandaTool/html/xFileTemplates_8h-source.html

Share this post


Link to post
Share on other sites
It only works in Visual Studio...but if your using it which i assume you are..add

#if _MSC_VER > 1000
#pragma once
#endif

to the top of your header files..

Its what Microsoft does for their headers(stdio.h, etc) so that you can include them multiple times and not get that error.

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

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

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!