as some are aware.. ive started modelling in truespace... and all i made is a simple blocked plane thingy...
which is all great but i cant get the damn models to convert in .x to .xsi properly so that it opens in threed
i have a list of options when exporting the object.. which ones should i use? also is there anyway im supposed to create the model specifically?
these are the options i can check:
ASCII []
store the object as a single mesh []
triangulate all faces []
feature edges []
center and normalize object []
thats it...
X2XSI relies on the .X file being an older version of the ascii .X format. Try checking the ascii format box and seeing if that works.
You should be able to open the .X version in Notepad when done... then run it through X2XSI and see if you can also open the .XSI version. Both should be readable in Notepad.
-Av-
(who still can't believe X2XSI keeps coming up around here... )
the x2xsi program I use has no such options. What are you converting them with?
ASCII [] xsi is in ascii as far as I know
store the object as a single mesh [] No.
triangulate all faces [] You should have done this already.So no.
feature edges []Eh?
center and normalize object []No
Who made X2XSI?
I thought I heard that you did, Avatar.
Why don't you dig up that old source code and get a version out that works better since everybody seems to always want to use it in it's present form. :)
noooo!
its truespace that has thsoe options! but bleh!
The options are Truespace, use the Ascii output option.
X2XSI may not handle multiple objects, so I can't advise there but one object should be safe.
Yes, I made it, and with it converted the first actual BZ2 craft over (the sparrow), which I used to demonstrate the unfinished aircraftclass physics Ken disclosed.
There are much better ways to make XSI files now, many tutorials written and many paths to getting them into the game. You can even do animated objects, which X2XSI can't do. OM has a fantastic converter for a free 3D program... why would you want to keep using a hack like X2XSI?
-Av-
QuoteX2XSI may not handle multiple objects,
It does!
It does not handle hierarchys.
and you always have to paste a dummy frame at the top so threed can see them all.
why would you want to keep using a hack like X2XSI?
because I have learnt how to use it, its free and does not stop working just because someone wants me to give them some money.
QuoteOM has a fantastic converter for a free 3D program...
Does it work yet? if were talking milkshape, mine stopped working....tools that fail because they are designed to fail are of no use.
This is a serious problem with software, built in redundancy has no place in my tool kit soft or not.
well thats why it doesnt work then haha...
i havent pasted a dummy root object none of it...
i did however open the XSI in 3d object converter and the pieces are flaming all over the place! they are all present but not in the places i put them when i finished the model! its insane?!?!
even the .X file which came straight out of truespace didnt go in proeprly... damn BZII why is it such a pain in he backside for models!
once you have the xsi file just open in notepad, find the first frame
SI_Light light1 {
0;
1.000000; 1.000000; 1.000000;;
0.000000; 5.966998; 0.000000;;
}
Frame frm-body {
FrameTransformMatrix {
1,0,0,0,
0,1,0,0,
0,0,1,0,
-0.015553,-3.86313e-06,0,1;;
}
Mesh body {
-----------------------------------
copy this bit
Frame frm-body {
FrameTransformMatrix {
1,0,0,0,
0,1,0,0,
0,0,1,0,
0,0,0,1;;
}
paste it above itself and rename it
Frame frm-dummy {
FrameTransformMatrix {
1,0,0,0,
0,1,0,0,
0,0,1,0,
0,0,0,1;;
}
save.
Quotethey are all present but not in the places i put them when i finished the model! its insane?!?!
In the above example it is this line
-0.015553,-3.86313e-06,0,1;; (i moved it a bit in threed.)
that determines the offset from xyz 0,0,0
after conversion it will be 0,0,0,1;;
the values in the mesh will be relative to this.
If the hierarchy is no more, they will all have moved.
Build without hierarchy. Create hierarchy in the resulting xsi
right...
gah why is it always so much more difficult?!!
@Avatar,
Exactly! Why continue using an old hack like that? It's a great question, but how many times has it been coming up. :D :D
@mrtwosheds,
Both OM's Milkshape Exporter and Blender 3d Exporter work. They just don't have animations as he hasn't had anyone to help in that area. My whole Shree race was exported with Milkshape to XSI and it works beautifully.
when you say tirangulate all faces... does that mean that every flat plane has to be a triangle...?
if so how on earth do you do it?
Truespace, no idea, never used it.
Lithunwrap has a triangulate option.
As I recall both 3DEX and BZ2ME need the objects to be triangulated otherwise both either yield an error message or downright freeze up. In TS this pops up when you save as X. Don't know about the other settings though.
its not 3dex im using it 3D object converter, another one that does something like 450 formats... well not in unregistered mode :@
I may actually be getting a little time soon, so I was planning to go through some more B3D tutorials (mostly animations and such) and work on my exporter some more.
Hey Jam, the X format saved by TS 3.2 sucks for BZ2ME. Save your models as either COB or ASC and try using 3DEX 1.5; it's free and I have the download link if you need it. I started using TS myself and the results are pretty good so far. PS: in case you haven't already read one of my previous posts about resetting the pivots to 0 it will prevent your models from appearing wrongly in BZII.
To reset it to 0 on the main toobar on the bottom of the main viewport hover your mouse over the icons showing the 3 axes. If you click it it will expand to show the other icons associated with it.
One is for moving the axes to the center of the object and the other is for actually resetting the pivots to zero and is labeled, normalize rotation.
A handy little helper to keep displayed in the workspace is the object info window; right click the big white arrow and it'll popup in the main viewport. The popup window is useful for entering in values for the XYZ coordinates of the selected object including object rotation information.
A simple test can be done by creating a cube object, rotating the X axes to say 90 degrees, then using the above steps to reset the X axes back to 0 again; basically, you'll see the value change from 90 to 0 in the X value box of the object info window.
Resetting the pivots to 0 is needed otherwise your models and props may not not appear correctly in BZII. As soon as I have time I'll put together a simple TS tutorial for you to make a simple Sabre Tank. Their really fairly simple to make and the exercise will help you get familiar with the editing controls of TS.
ar har... sorry i havent been around for a while... real life is being a little cruel...
i shall look into thees :D
TS, is proving to be somewhat of a pain in the you know what, but I do have something interesting to report about saving models created in TS 3.2 as ASC (3d Studio). At first in 3DEX 1.5 the model appeared sitting on it's tail pointing straight up. When I converted it to X the same orientation was repeated in the resulting X file. Strangely, in TS the model appears parallel with the grid as I originally constructed it. What I did to correct the ASC file to make it appear the same way in 3DEX was to to rotate the model in TS 90 degrees so that it now appeared on it's tail in TS. Then I moved the axes to the center of the model; basically 2 objects glued together one as a child to the other. Then I used the normalize rotation tool to reset the pivots again, and saved as ASC. To my surprise the model now appeared correctly, and the same applied to he ASC to X converted file too. Then I opened the X file in BZ2ME to check the axes orientation and sure enough everything checked out okay.
Hey JAM, saving as ASC in TS and following the steps described above appears to be the best way to use TS to make models and props for the game. I'll do some more tests to see how good the conversion from X to XSI in BZ2ME works in game.
Here's a screeny of my test model in both TS and 3DEX showing the results
(http://static1.filefront.com/images/personal/l/lppena/106799/ttkbrdubgb.thumb500.jpg)
So you could make the model, attach everything, texture it, then afterwards rotate it 90 degrees, move the axes to the center of the model, normalize the rotation, and then save the model as ASC. Then in 3DEX convert it to X, and open it in BZ2ME add the HP's if you didn't do it in TS and save it as XSI. Edit the ODF file you want to use and try it out in the BZII map editor. Sounds reasonable enough I guess. I'll have to try it out to see if their are any apparent bugs, but what the heck at least I'd be able to make a higher poly model then with GSL. Here goes nothing! LOL
How many network cards do you have attached to your machine?
I have only an ethernet hub and a USB file transfer cable that simulates a network card primarily for getting files from my old laptop to my desktop.
I create models on their tail pointing up. when I first save my models as .3ds, they appear pointing up in 3dex, but once converted to .x or .xsi they appear orientated the correct way in both 3dex and bz2.
I wonder if this is the way 3DS files are saved by default? I see the same results in 3DEX when saving as ASC out of TS 3.2. Which is good as both TheJamsh and myself are currently using TS to make models for BZII. I'm also using GSL still as it saves directly to X for easy opening into BZ2ME and out to XSI for the game. Both GSL and TS work together almost seamlessly as both support COB and SCN files interchangeably. GSL, appears to be a newer version then TS 3.2 with dates of 1997 and 1999. I'm going to more or less switch to TS for most future models and props and still use GSL for UV mapping and unwrapping as it has a simple to use UVW utility that exports to BMP format for making nice custom skins both from and to model texture maps. It supports face painting which are useful for color outlining poly sections that can be easily broken into simple shapes for exporting to a paint program. Separating the map and positioning it for the model painter much like the maps I've seen in common use already by other modelers creating skins for their ships. Hopefully, OM or some other person will get a decent XSI modeling utility working so that we can all start making some cool animated models too.
Apparently, X2XSI does write a readable animationset entry that 3DEX doesn't flag as an unsupported like the one added by BZ2ME with the edit frame thingy in it's options dialog. I wonder if it could be used to convert an animated X file to XSI, or has this already been attempted with negative results? I may try it just to see for myself.
PS: It also seems to handle the textures better too as in bz2me I seem to always have to go in to the edit material thingy and check the texture box to get it to appear on my model. x2xsi, already has the box checked when the file is loaded.
I'll try a simple animation in GSL, save as X, and convert it with x2xsi to see what happens. BNG crosses his fingers and says a wee prayer for the gods to be kind to him.
Even if it gets it wrong , see if the data is there.
*slap*
About all that X2XSI does is write a new header... it'll have the same info as the .X file...
-Av-
X2XSI also behaves differently between win xp and win me as does GSL between the 2 different os's. On win me the X files from GSL animate in 3DEX just fine, but on win xp there's no animation visible even though the play controls in 3DEX appear to function without error. What's even stranger yet is that X2XSI yields a runtime 53 file not found error under win me, but none when run under win xp. Why?
QuoteAbout all that X2XSI does is write a new header... it'll have the same info as the .X file...
so which modeling programs can animate in .x?
GSL 1.5, 3DEX 1.5, and X2XSI, are the same under both OS's. How they are handled by each OS is the difference. I accessed the same models across my LAN (USB file transfer cable) and the non animated x files apparently are the ones that were generated by GSL on the XP OS. However, on the ME OS installed GSL animate just fine when saved the same exact way as X files. I double checked the GSL settings under both installs and they are the same, so it does not make any sense to me other then perhaps the operating differences between the older ME verses the newer XP. Sorry to confuse anyone but I don't how else to put it. Anyways, X2XSI converts fine to XSI from X under XP, but yields an error under ME. It makes me wonder if X2XSI came out after ME, or maybe my ME install lacks some dependency that XP has for which X2XSI needs to perform it's task of converting X fies to XSI? Don't really know for sure. So any animation testing that I do will have to use the XP installed X2XSI. However, I can still access the animated X files on my ME system and convert them to XSI to see how they fare in terms of what you ask about the data thing.
I converted an animated X file to XSI with X2XSI, and the data under the Animationset appears identical numerically. How would I test it in the map editor? Should I use a generic terrain ODF file? I more or less just want to check this out first before attempting to make an actual animated unit with an appropriate ODF for something more complex.
Generally I find 3dex gives a very good indication of what it will do in bz2. what is it? a power gen loop sounds easy to me.
Quote from: BNG Da BZ Fool on January 03, 2008, 07:10:03 PM
X2XSI also behaves differently between win xp and win me as does GSL between the 2 different os's. On win me the X files from GSL animate in 3DEX just fine, but on win xp there's no animation visible even though the play controls in 3DEX appear to function without error. What's even stranger yet is that X2XSI yields a runtime 53 file not found error under win me, but none when run under win xp. Why?
My guess is that it's the VB runtime... XP's is more modern... X2XSI was created in Visual Basic 5 so, by current standards, it's ancient.
-Av-
I knew there was a difference just by the way each handled the 3 different utilities. The ME created files must get handled better then the way the XP versions are handled by their respective OS's. I suspect that the ME handled GSL does the same thing in terms of creating the right X file for 3DEX to manipulate their animation information as well. On the other hand, X2XSI appears to be adversely affect by the influences of ME's OS; yielding a runtime error when X files are processed for conversion to XSI. The workaround for me has been to create X to XSI files using X2XSI under the XP OS from animated X files created with GSL under the ME OS. Basically, I think that X2XSI is a fine utility and can be used to convert static X files to XSI better then BZ2ME. Has anyone ever looked at the source code for X2XSI? It does a good job of reformatting the file contents from one format to the other and even seems to do a fair job of preserving the animationset info, or is that just added by X2XSI to X converted files by default? If it isn't then that would translate in to something like X2XSI does attempt to convert that info too when it converts the files to XSI. One note that I might add also is that 3DEX does attempt to play the XSI files as I do notice them flickering when the play button is activated but no animation is visually present. I still need to compare the converted XSI files with the known working XS I's in the XSI data pack and try to discern any apparent difference in the layout of 2 XSI files compared side by side in notepad.
PS: I've decided to learn python in an effort to use it to create some XSI file conversion scripts and other BZII related goodies. Although, I don't expect any break th roughs for quite some time as from what I've read about python; it can be learned over time. I'm also searching the web for existing scripts. I found a few for Truespace developed as plug ins which I already installed and have been playing around with in TS. I understand OM's B3d script for XSI is a python script as well. My objective for 2008 is to develop an export script for TS that can export the XSI animation format that BZII uses. No easy task but well worth the effort if something useful results. EOM
Under XP you can create a shortcut to a program, and then call up the properties sheet to access a 'compatability' tab. On that tab you can tell XP to run the program as if it were Windows 95, 98, etc., along with setting a few other choices like system colors, etc..
This will often make an older program work a little more like it should, although in the case of X2XSI I doubt it'll do much.
-Av-
Whoops! Apparently I made a boo-boo on ME by not copying all the files in the zip and once I downloaded X2XSI from BZSCRAP again and unzipped to my Gamespace directory it started to work again. OBTW, the animation data was also added to the X file converted to XSI exactly as that from the the original X file. Unfortunately, there's no actual animation motion present in the XSI version, but 3DEX still goes through the motions of trying to play it, but to no avail. Still, it's a good alternative to using only BZ2ME; which is still somewhat useful as well.
Quotethe animation data was also added to the X file converted to XSI exactly as that from the the original X file. Unfortunately, there's no actual animation motion present in the XSI version,
Could you paste a sample of the xsi anim here?
Here's the original animated X section
AnimationSet NoName {
Animation Animation0 {
{CubeMesh-0}
AnimationKey {
2;
2;
0; 3; 0.000000, 0.000000, 0.000000;;,
10; 3; -2.877881, 0.000000, 0.000000;;;
}
AnimationKey {
0;
2;
0; 4; 1.000000, 0.000000, 0.000000, 0.000000;;,
10; 4; 1.000000, 0.000000, 0.000000, 0.000000;;;
}
AnimationOptions {
0;
0;
}
}
}
Here's the animated section from the X2XSI created XSI version
AnimationSet NoName {
Animation Animation0 {
{CubeMesh-0}
AnimationKey {
2;
2;
0; 3; 0.000000, 0.000000, 0.000000;;,
10; 3; -2.877881, 0.000000, 0.000000;;;
}
AnimationKey {
0;
2;
0; 4; 1.000000, 0.000000, 0.000000, 0.000000;;,
10; 4; 1.000000, 0.000000, 0.000000, 0.000000;;;
}
AnimationOptions {
0;
0;
}
}
}
It's somewhat astounding how much the GSL created X version resembles to that of the XSI format that BZII supports. BNG.
Um...not really.
'X' is direct x.
'XSI' is direct x "Soft Image" style... see? XSI = "X, Soft Image"
The formats are the same if you take into account the extra things that Soft Image added to support their own items.
That's why X2XSI works, because at the time it was made the text version of a regular .X file was virtually identical to the text version of a .XSI file.
X2XSI was created before Pandemic released the exporter for Max, so doing animations was still a far off dream...
-Av-
AnimationSet NoName { // NoName not required, may not be a problem.
Animation Animation0 { // wrong name should be// Animation Anim-CubeMesh-0
{CubeMesh-0}
AnimationKey {
2;
2;
0; 3; 0.000000, 0.000000, 0.000000;;,
10; 3; -2.877881, 0.000000, 0.000000;;;
}
AnimationKey {
0;
2;
0; 4; 1.000000, 0.000000, 0.000000, 0.000000;;,
10; 4; 1.000000, 0.000000, 0.000000, 0.000000;;;
}
AnimationOptions { //unknown delete
0;
0;
}
}
}
---------------------------------------
This should work, maybe the second animation key (rotation) might misbehave, I allways try to do one or the other t keep it simple. Its not doing anything here.
AnimationSet {
Animation Anim-CubeMesh-0
{CubeMesh-0}
AnimationKey {
2;
2;
0; 3; 0.000000, 0.000000, 0.000000;;,
10; 3; -2.877881, 0.000000, 0.000000;;;
}
AnimationKey {
0;
2;
0; 4; 1.000000, 0.000000, 0.000000, 0.000000;;,
10; 4; 1.000000, 0.000000, 0.000000, 0.000000;;;
}
}
}
--------------------------------------
AnimationSet {
Animation Anim-CubeMesh-0
{CubeMesh-0}
AnimationKey {
2;
2;
0; 3; 0.000000, 0.000000, 0.000000;;,
10; 3; -2.877881, 0.000000, 0.000000;;;
}
}
}
this will do the same as above.//you cannot put comments like this in .xsi :-D
Tanks MTS I'll try to edit the changes and see what results in 3DEX. I'm doing my best to get a better understanding of the way data things are entered and formatted as I realize that it makes a significant difference and problems result when data is not assembled the way another application expects to see the data and act on it. It seems like my thoughts lately are focused on the mechanics of data sets and how they are put together especially in regards to learning to script with python as it seems like a logical tool to create a file conversion utility. Does anyone know where I might obtain a copy of the original SDK for the BZII version of Softimage XSI. That would assist me in defining the proper format parameters for a python based conversion script. Python, sounds more or less like a utility where the script maker defines things beforehand and then adds how the things are acted upon in subsequent entries leading to a final result and output afterwords to some other thing like say a converted file. BZII, or some processes it uses also seems to use python as well as I've noticed several .PY files in the root directory. I would imagine that it could be useful for creating mission files for the game, but I don't really understand it yet; just seems logical that it might be useful for BZII.
I can give pretty detailed information on reading xsi 1.0/1.1 files, including a few off things BZ2 does different from the actual specifications. Get me on IM if you need anything, even if I am marked as 'Away', I may still be here, just send a message, I will message back when I get around, or get on my TeamSpeak server.
I have also already made a BZ2 mission scriptor using Python that fully supports multiplayer. It is a slightly different python dialect, well, same language, just with a few additions, it uses a concept of micro-tasklets so you can write things kinda like this pseudo-code:
from BZ2 import *
def victoryCondition(recy):
teamNum = recy.GetTeamNum()
while recy:
Sleep(10) # Sleeping for ten ticks, which in BZ2 is 1 second
SetWinningTeam(teamNum) # SetWinningTeam is not something I made, but something you should make to define the winning team, you know, setting end-game message, saying they one, slaughering the loser, etc...
class MyMission(Mission):
def AddObject(self, o):
if o.GetOBJInfo(Get_GOClass) == "CLASS_RECYCLER":
self.new(victoryCondition, o)
This is just a simple example. Essentially, as soon as any recycler type object is created then a new little tasklet will be created that will test, once a second, if that recycler object is still alive, as soon as any of them die then the function SetWinningTeam (which you would define as stated) is called with the team number of the recycler that died. Your mission script, instead of being one massive chunk of code where you have to remember to call checks and other such thing, just make tiny little one-off tasklets that only do a specified purpose, like the above (or you could do what you do in C++ or BSer's scriptor and just make one massive chunk of everything, the nice thing about this is you can package up common functions into your own little libraries and let different scripts use those so things like, in BZC where it has DLL specific functions that are the same on all missions, but each mission could be made with only the mission stuff where all the BZC stuff could be in its own library shared by all).
I've also intended to make a decorator so you could get rid of the New line and put it in the function declaration itself, to make the above this:
from BZ2 import *
@AlwaysNewTasklet
def victoryCondition(recy):
teamNum = recy.GetTeamNum()
while recy:
Sleep(10) # Sleeping for ten ticks, which in BZ2 is 1 second
SetWinningTeam(teamNum) # SetWinningTeam is not something I made, but something you should make to define the winning team, you know, setting end-game message, saying they one, slaughering the loser, etc...
class MyMission(Mission):
def AddObject(self, o):
if o.GetOBJInfo(Get_GOClass) == "CLASS_RECYCLER":
victoryCondition(o)
Good if a function should always only be called as a new tasklet, to help make sure you will not forget, and it is still okay to new it with no adverse effects as originally, just means that it will *always* be a new tasklet, no matter how it is called.
Tanks OM, as I get more of a handle on how python works and start to experiment with some test scripts I appreciate your willingness to answer questions as I learn more about scripting with python. I'm scouring the web for info relating to writing conversion scripts and studying the contents of those I find to get a clue on what I'm attempting to learn/do...BNG
*slap*
There's the guy to ask, straight out...
OM, any chance you could do a new converter that does what X2XSI tried to do? Convert .x to .xsi with the animations intact?
-Av-
What exactly needs to be converted (and what else needs to be converted that yours does not do)?
QuoteConvert .x to .xsi with the animations intact?
As far as I can see "the Animation" is intact, it is simply not applied to anything in the resulting .xsi model due to it being called
AnimationSet NoName {
Animation Animation0 {
Of course more complex animations may come out with more differences.
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-
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?
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?
I don't think BZ2 can use an animated .X file... never had any luck with that, anyway.
-Av-
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.
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.
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-
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.
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-
Neither option produces a file that x2xsi can convert successfully.
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.
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
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-
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
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...).
Looking through these formats and how BZ2 follows through them, as far as I can tell, BZ2 should be able to read them just fine. The only issue I might see is some things not getting set due to a missing SI_CoordinateSystem section. Have you'll just changing the .x header, something like this (everything before the first Frame word):
xof 0302txt 0064
# This DirectX file was written by a Caligari (tm) product
Header {
1;
0;
1;
}
And replace it with something like this:
xsi 0101txt 0032
SI_CoordinateSystem coord {
1;
0;
1;
0;
2;
5;
}
I looks like this little change alone should get it readable just fine by BZ2, without renaming the other sections. Can someone test that, and if it works fine then I could just make a quick app to do that, else I can make one to make the normal changes too, but from everything I see that is unnecessary.
Tanks OM, I'll test it and report back...BNG
With the changes made to the X file it caused 3DEX to display an error stating directx signature not found. Also displayed other message called bad file format. Could it have been the first line of numbers?> xof 0302txt 0064. Perhaps just adding
0;
2;
5;
after
1;
0;
1;
Considering it's still an X file of course only so many changes are probably tolerated before an exception is called or something like that. When I tried an X file in a modified ODF file where the XSI geom. name was changed to X instead the map editor didn't crash as I expected it to but there was no visible object; only the unit name and the green health bar appeared at the point where I placed the unit?
Here's the modified ODF I used and the only thing I modified was to change .xsi to .x.
Additionally, the resulting .msh file only had references to the hp triangles glued as children to the main object; no references were displayed in the mesh tree to other geom objects in model file.
I was pleased that the map editor didn't just crash altogether as it had done in the past when other things were attempted.
GSL, by default saves files as ASCII; do you think that unchecking that option and saving it as a binary would make any difference as I don't really know too much about what BZII can handle and what makes it crash?
[GameObjectClass]
classLabel = "aircraft"
geometryName = "gmaxdragon.x"
geometryScale = 3.0 //2.0
cockpitName = "ivstas_cockpit.xsi"
scrapCost = 35
scrapValue = 5
maxHealth = 1000
maxAmmo = 750
unitName = "Gmax Dragon"
heatSignature = 0.5
imageSignature = 2.0
radarSignature = 0.1
isAssault = 0
armorClass = L
//canCollide = 1
canDetect = 1
canInteract = 1
canSnipe = 1
needsPilot = 0
collisionRadius = 0.7
addAmmo = .3
ejectRatio = 0
boxCollide = 1
effectHard1 = "hp_emit_1"
effectName1 = "ivsgull1.tail"
weaponMask = 01111
weaponHard1 = "HP_GUN_1"
weaponName1 = "gairchn1"
weaponAssault1 = 0
weaponHard2 = "HP_GUN_2"
weaponName2 = "gairchn1"
weaponAssault2 = 0
weaponHard3 = "HP_CANNON_1"
visualHard3 = "HP_CANNON_1"
weaponName3 = "plasma_a"
weaponAssault3 = 0
weaponHard4 = "HP_ROCKET_1"
visualHard4 = "HP_ROCKET_1"
weaponName4 = "apgsquid"
weaponAssault4 = 0
weaponHard5 = "HP_SPECIAL_1"
visualHard5 = "HP_SPECIAL_1"
weaponName5 = ""
weaponAssault5 = 0
lightHard1 = "hp_light_1"
lightName1 = "spotblue2"
lightHard2 = "hp_light_2"
lightName2 = "spotblue2"
[CraftClass]
rangeScan = 450.0f
periodScan = 3.0f
velocJam = 5.0f
engageRange = 225
weaponPitch = .3
selectWaitMsg = "fvartl04.wav"
selectAttackMsg = "fvartl01.wav"
selectFollowMsg = "fvartl03.wav"
selectGoMsg = "fvartl02.wav"
selectOtherMsg = "fvartl04.wav"
holdMsg = "fvartl12.wav"
goMsg = "fvartl05.wav"
attackMsg = "fvartl06.wav"
followMeMsg = "fvartl08.wav"
followMsg = "fvartl03.wav"
rescueMsg = "fvartl10.wav"
otherMsg = "fvartl05.wav"
killedMsg = "bombgen02.wav"
[AirCraftClass]
velocSet(L) = 10.0 // minimum velocity
velocSet(M) = 20.0 // cruising velocity
velocSet(H) = 48.0 // maximum velocity
accelThrust = 6.5 // 7.0 // thrust acceleration
accelBrake = 10.0 // brake acceleration
accelDrag = 60.0 // drag acceleration -- affects sliding sideways
// mouse as rudder
omegaSteer(L) = 0.3 // steer turn rate at minimum
omegaSteer(M) = 0.9 // steer turn rate at cruising
omegaSteer(H) = 1.2 // steer turn rate at maximum
// strafe affecting rudder
omegaStrafe(L) = 0.1//0.6 // airbrake turn rate at minimum
omegaStrafe(M) = 0.3//0.9 // airbrake turn rate at cruising
omegaStrafe(H) = 0.9//1.1 // airbrake turn rate at maximum
//this affects steering but not sliding
alphaSteer = .8 // 0.7 // steering angular acceleration
alphaStrafe = 0.01 //0.5 // airbrake angular acceleration
minAltitude = 20.0 // minimum altitude - no effect?
maxAltitude = 150.0 // maximum altitude
alphaLevel = 10.0 // leveling angular acceleration
// this affects sliding sideways, 20 makes it jitter some tho
alphaDamp = 12 // 5.0 // damping angular acceleration
pitchPitch = 0.7 // 0.4 // maximum pitch angle
rollSteer = 0.5 // maximum roll angle from steering
rollStrafe = 0.5 // maximum roll angle from airbraking
timeDeploy = 1.0 // time to deploy
timeUndeploy = 1.0 // time to undeploy
soundThrust = "ienge.wav"
soundDeploy = "avapce2.wav"
soundUndeploy = "avapce0.wav" //"amb_fwd.wav"
soundBrake = "iengf.wav"
[Tail]
renderBase = "draw_trail"
textureName = "trail2.tga"
textureBlend = "one one modulate"
startColor = "20 50 90 150"
finishColor = "30 60 80 0"
startRadius = 0.7
finishRadius = 0.2
segmentTime = .6 // time each segment animates
segmentVariance = "0.1 0.1 0.1"
animateTime = 0.3
textureRate = 0.05
Like I said, X2XSI just puts an XSI header from a BZ2 XSI file onto a text formatted X file from the time...
It seems to me there was something else further in that had to change, also, maybe something with the normals... it's been so long... I wish I had the source still... I'm looking through my old backup CD's trying to find it...
Hell to get old. :)
-Av-
Something to do with the parenting of frames?
I think xsi will display all children of only one frame, just the one at the bottom of the xsi if none are children.
The only other stettings I can change are: store the object as a single mesh, feature edges, center and normalize object, loop animation, position quality line or spline; currently set to spline, keyframe step; currently set at 10, rescale factor currently set at 1, animation set name currently being un used, float size 32 bit or 64 bit; currently set to 64 bit, and lastly coordinate system left or right; currently set at left handed. Additionally, I can flip the normals, save normals, or select no frames in 3DEX.
Does anyone know what save templates does as it apears in the 3DEX X save options?
As stated, from digging into BZ2 it looks like a normal .x file should work, except just change the header into an SI_CoordinateSystem section, and change the top line from the xof thing into the xsi thing. I do not think any other changes need to be made, and no, that file will definitely not work in 3dex, try it in BZ2 only.
OM, I think if that were the case then X2XSI would be pumping out fully working files... because basically that's what it does.
Basically.
:)
-Av-
I think x2xsi also changes some other things which then changes how the file is read in BZ2. Notable normals and so forth.
Not unless the XSI I based it on had it that way... in which case I duplicated it.
I've said all along, it's a glorified text editor, just tacks on a header and makes an X look like an XSI as much as I could.
-Av-
AV's right X2XSI isn't well suited for getting XSI animations to work using X animation files; however, it's good for static non animated models and props. Our best bet for possible XSI animations is OM's B3d exporter. It would be the free equivalent of the XSI exporter for MAX 3d. Our best option would be to assist OM by offering him help in testing the exporter as much as possible and provide him with feedback on the outcome of learning to use Blender as applicable to creating animations in B3d and testing them out in the BZII map editor, and posting info for OM to tweak the exporter to explore what's possible. Tanks OM for taking time to work on the exporter...BNG PS: Tanks AV for X2XSI too.
Thing is that it looks like it should work if just the changes I mention are made...
From the perspective of my own construction methods, whatever you made those .x animations with BNG would be very useful. It can give the number sets for complicated movements that I cannot just type out, like a rotation on two axis or more. Pasting them into an xsi and typing out the right names would be much quicker than learning to use a new modeling program and figuring out how to convert its output to bz xsi :-)
I have been looking at morphing animations, the only thing stopping me creating one, is the si_envelope information that contains the vertex numbers to be attached to a bone. Bones are no more than meshless frame points that are rotated by a normal rotation animation and connected together via other meshless frames points
If I knew the numbers of the vertex in a leg I could morph it...
The envelope only links points to a frame (usually an empty frame that pretends to be a skeleton) with specific weights (and do note, BZ2 only supports two weights per point, in other words, a single point can only be moved be a max of two skeleton nodes, anything more and it ignores them). Thus far envelopes are the only part I cannot export from a .msh file (the format is completely different for those, a bit weird), but I can export everything else, including animations.
The GSL animation recorder was used to record the movements of my cube object after selecting the record keyframe icon and setting the time interval on the graphic display window it uses. Morphing can be done just as easily too by using the object deformation tool to pull and push the objects geometry around in the 3d workspace.
OBTW, in addition to working on this issue I'm also getting used to the B3D UI to do some additional testing on OM's XSI exporter and plan on mastering the basics of using it to create, texture, animate, and use the exporter to see what's possible with it too. Thank God, I'm used to multi-tasking as it's useful for working on multiple projects simultaneously. PS: I'll retry the renaming thing with the X file that was suggested by OM and the animationset rename thing by MTS as well. The X format that GSL saves is about the closed looking XSI format I've seen so far; all the other variants look totally different (more like something you'd see in a HTML page you know> <7EM4MFJ5J68FKDSKL97J>, etc.
Try the animation support in B3D, I have the basics of the exporting done (maybe complete), but it is still pretty untested as any files I have received as tests did not implement animation correctly to begin with. Also, I do not think I have bones complete, started yes, but not complete I think...
Will do OM. Compared with what I've modeling with Blender should equate to a nice free modeling upgrade over the seemingly endless gambit of so so 3d modelers presently on my system. The texturing method that B3D uses is quite extensive, but relatively easy to comprehend. The modeling controls are easy enough to make and transform simple premade geo. shapes, but I guess GSL spoiled my on making custom shapes using it's polyline and sweep (extrusion) tool. That'll be one of my priorities to master as I'm going to try to exclusively use Blender to make all future models and props with. It'll take a while to get the hang of Blenders UI, but once I do I'll also start importing existing models into B3D for eventual conversion to your XSI format. Blender, is well documented and I recently DL'ed a Wikibook titled, "Blender from noob to pro," and made it available offline on my system. It covers most topics from basic tutorials to advances ones as well. As I learn more about Blender then I'll start posting some simply tutorials for others to use as well.
Remember, if you find any bugs, poke me. :)
Will do OM, but first I need to make sure I understand things throughly before posting as I realize that the necessary steps must be done correctly per the way Blender needs things to be done in order for objective analysis to make any sense. Once I understand Blender better then I should be able to apply that knowledge towards producing some fully textured animated models. The nice thing too is that because the same modeler is being used the results can be tested/shared by other peeps to replicate/test the results, and spot problems fairly easy, i.e., via the blender file equivalent. What I'm going to do is save a blend file of my models for you and others to DL @ Filefront in addition to the XSI exported files. If you have any other feedback then feel free to PM me as needed...BNG.
Quote from: Avatar on January 06, 2008, 12:50:16 PM
Um...not really.
'X' is direct x.
'XSI' is direct x "Soft Image" style... see? XSI = "X, Soft Image"
The formats are the same if you take into account the extra things that Soft Image added to support their own items.
That's why X2XSI works, because at the time it was made the text version of a regular .X file was virtually identical to the text version of a .XSI file.
X2XSI was created before Pandemic released the exporter for Max, so doing animations was still a far off dream...
-Av-
Sorry to bring up an old post again AV, but when you refered to x and xsi files as being virtually indentical does that mean with some notepad editing as MTS suggests would make an x file compatible with BZII xsi?
Yes, and I have detailed the changes needed over a number of posts here. :)
Bah, freakin no posting within 30 seconds of last post freakin annoyance, hit that 4 times this session so far...
(http://www.overminddl1.com/image_scripts/image_sig.php?type=ODL1signitures&image/sig.gif)
Generated by OvermindDL1's Signature Auto-Add Script (http://overminddl1.com) via GreaseMonkey (http://greasemonkey.mozdev.org/)
Quote from: BNG Da BZ Fool on January 16, 2008, 06:04:30 PM
The X format that GSL saves is about the closed looking XSI format I've seen so far; all the other variants look totally different (more like something you'd see in a HTML page you know> <7EM4MFJ5J68FKDSKL97J>, etc.
Were you opening the files in Notepad or Wordpad? When I exported .x files from Cinema 4D I noticed that they open fine in a word processor like Wordpad or TextEdit(Mac) but, when opened in Notepad they appeared as mostly garbeled characters and random numbers. Not sure why.
There were/are two versions of Direct X files, one in plain text and one in compressed text.
X2XSI only worked with the plain text version of .X because at heart it's just a text editor.
-Av-
And BZ2 *only* supports the text format as well.
(http://www.overminddl1.com/image_scripts/image_sig.php?type=ODL1signitures&image/sig.gif)
Generated by OvermindDL1's Signature Auto-Add Script (http://overminddl1.com) via GreaseMonkey (http://greasemonkey.mozdev.org/)