• Welcome to Battlezone Universe.
 

News:

Welcome to the BZU Archive dated December 24, 2009. Topics and posts are in read-only mode. Those with accounts will be able to login and browse anything the account had access granted to at the time. No changes to permissions will be made to be given access to particular content. If you have any questions, please reach out to squirrelof09/Rapazzini.

Main Menu

X2XSI problems

Started by TheJamsh, December 04, 2007, 10:42:01 AM

Previous topic - Next topic

Avatar

Quote from: OvermindDL1 on January 08, 2008, 09:13:42 AM
What exactly needs to be converted (and what else needs to be converted that yours does not do)?

X2XSI basically takes an X file, adds an XSI style header, and I think it moves a few other entries around to make an X look like an XSI.  It's a glorified notepad app...  nothing fancy.

The goal at the time was to get static structures into BZ2, which it did so I was happy.  I knew nothing about animations at the time so I didn't address them.  It was meant to do single object static structures...  remember, this was before the Pandemic exporter or Threed were released and there was no other way to get an object into the game.

What's needed is going that extra step, taking an X file and making it look like an XSI by making whatever changes are needed between the two formats, for multi-obect animated X files.

-Av-

OvermindDL1

Out of curiosity anyway, BZ2 supports .x files, why not use them directly, is there some sort of issue with that I am unaware of?

mrtwosheds

Speaking for my own peculiar creation/construction process, I have found no workable way to construct a useful complex .x model to import into bz2, a cube maybe, a tank no.

I downloaded that truespace the other day, I have no idea how to use it at all....Why do I have to have pretty buttons, incomprehensible jargon, and tools with no numerical adjustment/measurements on them?



Avatar

I don't think BZ2 can use an animated .X file...  never had any luck with that, anyway. 

-Av-

mrtwosheds

Earlier in this thread we determined (I think) that the numerical data set it produced is fine for use in an xsi but that its naming convention causes it to not function, this can be easily rectified with a little typing.
This is actually really useful, the difficult things to make are the data sets, partial rotations and the like.

BNG Da BZ Fool

Does anyone know what specific X version that BZ2 supported? It seems like there are so many different versions that knowing what version did work would be a logical query for possibly finding an older 3d model making application to make models with. I must have at least a dozen or more free 3d modelers installed or residing on my system alone. Multiply that number by the number of other BZ2 3d modelers and that's potentially a whole plethora of 3d model making programs some of which may still exist somewhere in web land.

I never really gave much thought to it until OM a while back mentioned the issue, but didn't really elaborate on the version number or other related details. It seems to me that so much emphasis on XSI that the X thing was sort of put on a back burner, and eventually forgotten almost altogether.

I'm going to back and look into the issue and search for info on the history of the X format to see if potentially useful information can be gleaned from old archive sites. Clearly, there don't appear to be any viable free XSI animations tools available, or as yet undiscovered anyways. I'm guessing just off hand that searching Microsoft's site would be a good starting point.
When I'm not in hot water with the community I'm usually making models for BZII. I've made a few models for other peeps. BNG.

Avatar

The basic format of .X shouldn't have changed much over the years, but things kept getting added to it.  The early 3D modelling that programs did didn't have fog, lights, things like that.  They basically just 'lofted' a 2D shape as they were mostly intended for CAD work.

As to fixing X2XSI I long since lost the source, not to mention not even having Visual Studio 5 installed anymore.  Now that I'm getting more comfortable with the Express Edition of VC++ I might have a go at recreating X2XSI, but it seems like it'd be trivial for some of the lurkers around here...   :)

-Av-


mrtwosheds

There does seem to be differences in the .x that my applications create. you can save as .x in lithunwrap, feed that to x2xsi and you get just a header.
But if I save as .3ds and then convert to .x with 3dex155, x2xsi converts it fine.
I stopped investigating wtf was going on as soon as I found a way that worked for me.

Avatar

Quote from: mrtwosheds on January 09, 2008, 06:37:31 PM
There does seem to be differences in the .x that my applications create. you can save as .x in lithunwrap, feed that to x2xsi and you get just a header.
But if I save as .3ds and then convert to .x with 3dex155, x2xsi converts it fine.
I stopped investigating wtf was going on as soon as I found a way that worked for me.

When you just get a header it means the original .X file was saved as a BINARY file.  There's almost always the option to save as either plain text or binary with exporting to .X, and for X2XSI to work you have to choose the plain text version.

-Av-


mrtwosheds

Neither option produces a file that x2xsi can convert successfully.

OvermindDL1

Quote from: Avatar on January 09, 2008, 04:55:21 PM
The basic format of .X shouldn't have changed much over the years, but things kept getting added to it.  The early 3D modelling that programs did didn't have fog, lights, things like that.  They basically just 'lofted' a 2D shape as they were mostly intended for CAD work.

As to fixing X2XSI I long since lost the source, not to mention not even having Visual Studio 5 installed anymore.  Now that I'm getting more comfortable with the Express Edition of VC++ I might have a go at recreating X2XSI, but it seems like it'd be trivial for some of the lurkers around here...   :)

-Av-

Tell me *exactly* what the changes need to be and I'll whip it up.

BNG Da BZ Fool

As far as I can tell from the image that I posted earlier in the thread the major difference was the naming of the animationset heading noted by MTS. 3DEX, attempts to use it's animation feature to manipulate the X2XSI converted X to XSI file object; a simple cube sliding along a straight path. I could send you the files OM so you could compare them side by side to determine if simple changes could be made to X2XSI to get the XSI files formatted correctly. From my observations in 3DEX using it's animation controls the major difference between the original X animated file and the X2XSI file are that the X file visually shows the animation, but the XSI version doesn't show visual movement but it's animation controls are actively trying to animate the XSI file with no apparent visual motion. However, it's gives no indications of errors (typically a yellow triangle with an exclamation point that can be clicked on to indicate the error type). PS: Here's a link to filefront to download the 2 zipped files> http://files.filefront.com/2x2xcubezip/;9412201;/fileinfo.html
When I'm not in hot water with the community I'm usually making models for BZII. I've made a few models for other peeps. BNG.

Avatar

Quote from: OMTell me *exactly* what the changes need to be and I'll whip it up.

Um... hmmm...

I basically just grabbed an XSI and an X of a cube and compared them in Notepad...  which, of course, is why nothing at all was done with animations.

I would have thought OM of all people would have the X and XSI SDK's...    :)

-Av-

BNG Da BZ Fool

What I'd like to know is how the early X format is somehow compatible with BZII. I tried a simple experiment with the X format that GSL produces and reused an ODF that I previously used with another model that I successfully converted from X to XSI with BZ2ME. Only in this ODF I changed the geometry name from gmaxdragon.xsi to gmaxdragon.x and saved the file to try out in the map editor. The only I could see was the unit name and the green health bar, but no actual geometry at all. It even created a .msh file and without an AV error when the model was placed in the map editor; although in OM's mesh viewer no visual geometry was present. It did show the hp's though.

I have a gut feeling that a web search for an older 3d modeler (released around the same time as BZII) that supports the X format then in use would probably support the X version compatible with BZII and might yield a better alternative then trying to adapt a current XSI animation conversion utility; one wouldn't be needed at all. The question is, are any of them still available for download? The oldest I've come across so far far is TS 1.0, but is doesn't support saving files as X; it's copyright date is 1994 I think. TS 3.2's date is 1997, and GSL is 2004, but it's X format closely resembles the older BZII XSI format, and works good with X2XSI, BZ2ME, and 3DEX 1.5.

I also discovered that the original directx was created using DOS as it was better suited then Windows 95 due to something having to do with Win 95's protected driver mode. DOS, apparently was well suited to configuring video drivers, and other related stuff. I used to use DOS back in the late 80's when Windows 3.1 was still being used by die hards and DOS was still in common use. So I guess the search goes on for some better alternatives then those currently available for working with animation files whether it be X or XSI...BNG     
When I'm not in hot water with the community I'm usually making models for BZII. I've made a few models for other peeps. BNG.

OvermindDL1

I have the xsi sdk for 3.0+.  And the .X format is so inconsistent there is no single reliable way to use it.  And changing the filename should not do anything, BZ2 identifies the filetype based on the first line (which is different for .x and .xsi files).

DOS is still technically far faster for games, and DOS (even the open source and fast FreeDOS) will fit in the level 2 cache of most cpu's nowadays (yes, the entire DOS runtime).  If video/sound/networking/etc... drivers were still made for it, and if a unified interface (akin to DX) came out for DOS, there would definitely be a noticeable speed difference and it would be easy to program for.  No OS threading to deal with, no worrying about conflicts with other open programs, a perfect setup, very consolish.

There is a version of *nix built to be like that, specific for games, a very basic gui only to get things launched (although you could install more of course), but even the original DOS would be faster on single-core things since it did not worry about multi-users, security contexts, etc... that *nix/windows still deals with.

And yes, I've been on the PC since before Windows, I still have my 5" floppies to install DOS 2, 3, 4, 5, 6, 6.22, and 7 (although 6+ are on 3.5" floppies).  Although I also have floppies with Windows 2, 3, 3.11.  And CD's with NT 3.5, 4, 5 (2000), 5.1 (XP), 5.2?(2003), 95 (original, B, and C), 98 (first and second editions), ME (Yes I have it, it actually ran well on my systems, more stable then 98 was unlike what other people experience), and so forth.  Also have very old versions of Red Hat, Mandrake (now Mandriva), and a few others around as well (by old I mean like 1994 kind of old).  A few other things as well, and sans the *nix things, all of them are the official distributed retail disks (although who knows of some of those old floppies work anymore...).