kW X-port: new X file exporter for 3dsMax 8
The DWORD part is just raw memory data (similar to how memcpy() just treats blocks of data). After unpacking, the mesh will use the vertex data declaration to
Anyway, I've exported tangents and binormals, and loaded them into the DirectX Viewer, and they came out OK (without the viewer having to re-calculate them) so there is an existence proof, if you don't believe me.
Oh, another thing my exporter does which Panda doesn't: it rotates the geometry to put Y up, out of the Max Z up coordinate space. Most people prefer this; some possibly don't, so at some point I might make that optional, too...
When it comes to .X file support, it's always been a stepchild within Microsoft AFAICT -- the exporters have been going on and off for a long time. Given that they're working on XNA as an actual platform now, I'm assuming they have to address geometry export and animation; it'll be interesting to see what they do with that.
Of course, in the latest SDK, they now have a proprietary, undocumented, binary "SDKMesh" format -- why they couldn't stick with .X, I have no idea. If you think the mesh/meshnormals/texcoords are too verbose (which they are), you can just export everything to DeclData, and be happy that way. In fact, that's another option I'd love to add at some point (although you'd need custom .X file loading to recognize it).
This is really great Jon, thanks for making this exporter. We've been using the panda one in our art pipeline for a while now, and having occasional problems with it. I'll be sure to try this one out.
Quote:Original post by hplus0603
When it comes to .X file support, it's always been a stepchild within Microsoft AFAICT -- the exporters have been going on and off for a long time. Given that they're working on XNA as an actual platform now, I'm assuming they have to address geometry export and animation; it'll be interesting to see what they do with that.
A few years ago, there was talk of scrapping .X and creating a new format that would have solid animation (ie both changing the file format itself and the D3DX interfaces). The idea was to get something out there that developers could actually use. I think it died pretty quickly though, since devs already have their own in-house format or some licensed SDK. However, it seems they didn't forget about the 'scrapping .X' part [wink]
Sorry, but I just don't get it. I looked at the DXViewer code, and it will call the D3DX functions to create normals, tangents, and binormals if needed. So, it may not use what is in the .x file.
Here is the decldata I get when I create and save a mesh with them:
DeclData {
2;
2;0;6;0;,
2;0;7;0;;
762;
1044957488, <---- Take this "float"
3211805320,
3197205575,
1064742840,
1047777084,
3187194272,
1055321086,
3210300676,
3196925422,
I saved it in text format. So, you are saying that there is a standard way to convert 1044957488 to a DWORD or directly to a float from a char string? How would it know where the decimal goes? I cannot see this, given the various functions available in the C++ standard libraries.
All of the other data in the .x file saved as a float looks like a floating point number. This doesn't look at all like one. For one thing it has 10 digits in each number, so you couldn't even try to fill the nibbles of a 4 byte float with them: 0x1044957488 is 5 bytes.
Thanks.
Here is the decldata I get when I create and save a mesh with them:
DeclData {
2;
2;0;6;0;,
2;0;7;0;;
762;
1044957488, <---- Take this "float"
3211805320,
3197205575,
1064742840,
1047777084,
3187194272,
1055321086,
3210300676,
3196925422,
I saved it in text format. So, you are saying that there is a standard way to convert 1044957488 to a DWORD or directly to a float from a char string? How would it know where the decimal goes? I cannot see this, given the various functions available in the C++ standard libraries.
All of the other data in the .x file saved as a float looks like a floating point number. This doesn't look at all like one. For one thing it has 10 digits in each number, so you couldn't even try to fill the nibbles of a 4 byte float with them: 0x1044957488 is 5 bytes.
Thanks.
Quote:Original post by DXnut
Sorry, but I just don't get it. I looked at the DXViewer code, and it will call the D3DX functions to create normals, tangents, and binormals if needed. So, it may not use what is in the .x file.
Here is the decldata I get when I create and save a mesh with them:
DeclData {
2;
2;0;6;0;,
2;0;7;0;;
762;
1044957488, <---- Take this "float"
3211805320,
3197205575,
1064742840,
1047777084,
3187194272,
1055321086,
3210300676,
3196925422,
I saved it in text format. So, you are saying that there is a standard way to convert 1044957488 to a DWORD or directly to a float from a char string? How would it know where the decimal goes? I cannot see this, given the various functions available in the C++ standard libraries.
All of the other data in the .x file saved as a float looks like a floating point number. This doesn't look at all like one. For one thing it has 10 digits in each number, so you couldn't even try to fill the nibbles of a 4 byte float with them: 0x1044957488 is 5 bytes.
Thanks.
Sorry to revive this thread, but I was figuring this out as I was writing my Maya exporter. You can convert between the original floats we need to and from the DWORDs stored in this template as follows:
DWORD d = 1044957488;float * fd = (float*)(&d);float f = *fd;DWORD * df = (DWORD*)(&f);cout << "DWORD d = " << d << endl;cout << "float d = " << *fd << endl;cout << "float f = " << f << endl;cout << "DWORD f = " << *df << endl;This will output:
DWORD d = 1044957488
float d = 0.19608
float f = 0.19608
DWORD f = 1044957488
Thanks! I think I get it now.
1044957488 is 3E48C930 in hex. So it is saved as a decimal value (when the text format is used), you can use one of the string functions to convert it to a DWORD and then treat it like a float.
Your post made me realize that the xfile loader does the same thing the compiler would do when converting a literal in a program.
1044957488 is 3E48C930 in hex. So it is saved as a decimal value (when the text format is used), you can use one of the string functions to convert it to a DWORD and then treat it like a float.
Your post made me realize that the xfile loader does the same thing the compiler would do when converting a literal in a program.
I can't wait to try it tonight. I've been using Panda, but have had issues from time to time.
How does the exporter deal with texture types, does it know a base texture from an alpha from a bump, etc, so they can be dealt with correclty once loaded?
An alpha for example you'll want to render last, and maybe even after not just the model is rendered but all other opaque models. I'm just thinking of a building with windows, and you're looking in the front window, through the room and out the back window. Most model exporters I've seen don't provide anything to handle this well.
Thanks
How does the exporter deal with texture types, does it know a base texture from an alpha from a bump, etc, so they can be dealt with correclty once loaded?
An alpha for example you'll want to render last, and maybe even after not just the model is rendered but all other opaque models. I'm just thinking of a building with windows, and you're looking in the front window, through the room and out the back window. Most model exporters I've seen don't provide anything to handle this well.
Thanks
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement