I didn't make it!
I was thinking about modeling some in 3D Studio Max for SWBF, but I don't know how to extract the required data from the game. Does anyone know something of interest?
Actually, it's going to be Softimage|XSI, I believe. We have sporadic input from a dev, and several people working on getting models. Let me give you some snippets from gametoast:
luck3y Hey, it sort of works a bit! [/QUOTE]luck3y Yeah that was it. Nice one riley No materials / textures / skeletons yet, so models all dark.[/QUOTE][QUOTE="psych0fred (a developer)"]The models were created using the professional version of XSI but there is no reason you can't use XSI EXP to create the models. They are exported with a custom Add On for XSI created by Pandemic that saves files in a .msh format. These models are then compiled into LVL files that are then wrapped up inside other LVLs which are all wrapped up inside the side.lvls and world.lvls. The .msh files contain all data about the model and animations such as hardpoints, collision, and firepoints, and also reference the textures. The animation and model properties are defined by Object Definition Files (ODFs) which are also wrapped up in the lvls. The ODF names typically correspond to a msh file but often, as in the case with units, they share a base geometry across a class.luck3y Not terrains exactly, I meant the modls referenced by them ... The map 'floor' is a modl, looks like, as is the horizon and the skydome, I've got those too, but they make boring screenshots (dome == hemispehere, horizon == cylindrical section, floor == disc).[QUOTE=Riley75]Yeah, try it with .0 appended to the end. Maybe Mesh Viewer doesn't recognize them if they don't look like floats. I'm just looking back at something I posted early on in this thread: Two VBUFs from a terrain These are a different pair of vertex data types, but here's some observations about them: 1) The float version has X,Y,Z values between 0 and 64; whereas the short version spans the entire range (-32768 to 32767). 2) The X,Y,Z values are otherwise comparable -- notice they increase / decrease in the same pattern. 3) At first glance, the u,v,w normal vector might look different (u is always 0 for the short version). But the short version might just be a "best approximation". 4) The RGB values are identical. 5) The alpha channel looks like it's reversed. Where it's 0xFF in the first VBUF, it's 0x00 in the second. 6) The sign is reversed on the normal vectors. Points #5 and #6 above might suggest that I'm wrong that it's "just a copy"; whereas the rest of these observations - in my mind - support the notion it might just be a copy. Right now, I suspect that the short version is calculated by whatever proprietary software they used to export the models. So, they'd work with the float version during the design process, and calculate this second short version when they put it into the game. The big thing that's leaning me this way is points 1 & 2 above. The fact that the short version spans the entire range suggests they are trying to provide as much precision as possible. To calculate the actual X,Y,Z values for the short version, they'd simply find the min & max values of all the floats, and then scale them into the -32768 through 32767 range. Point #6 above is an oddity though. It almost makes me wonder if the short version is actually the same model, but looking at it from the inside-out.
so we're working on a mesh extractor (try http://www.zaptillion.net/sqbf/extract.zip), that is (i think) our beta .lvl extraction tool, but it cant compile yet, so its not as much of a help, and it cant read most chunks, just the lua binaries, .dds files, and maybe mesh files.
Nice, thanks. Maybe there will be some converter out on the net so I can play around with the models. Isn't Source the only engine that uses SoftIMG?