fun with .pso

Quick Update.
I'm about done making the script import UVs. I'll post a screenshot later on.

I've created a quick and dirty website to host some documentation and versions of my script while it's in development. When it's finished I may let someone else host it. I've also made myself a sig that should take people to my site.

Good God Davel, I do admire you're effrontery . . . but only because my Lee-enfield's range is less than the width of the Atlantic Ocean. I just might make this news . . .

I'm working on the automatic conversion now.
I've posted a .doc that details what I know/suspect about the .pso format. It's incomplete, so if anyone can fill in the blanks, I'd apreciate it. Mainly, there's 20 bytes in SHDR that I just don't know what to do with yet.

Click my sig to get the document.

I'm trying your importer right now, davel. I can't wait.

I noticed on your site that you only cover the lwo2 format. What about the original lwo (pre-lightwave 6.0) format. Two large differences I can list right away between the two are: lwo2 objects can store uv coordinates (5.6 and below objects apparently couldn't, and used only a proprietary projection mapping method). Post 5.6 objects can now have texture mapping and surface attributes defined in Modeler (probably more a function of the program than the object format itself).

I believe Jasper has considerable documentation for the old lwo format. It might be worthwhile combining your info with his. Then we'll get more info in one place. Just a thought.

mailto:second_chance@cox.net
The Ultimate Guide To Modding: I-War 2 - Edge Of Chaos
.

Wow! Very nice!

Beautifully designed interface, imports both meshes and FTU's flawlessly. Nice job.



I assume the import of meshes is by surface name, correct? I can't wait to see some imported mapping coordinates.

Any chance of being able to import a Lightwave scene as well, to get everything together the way it's set up to be in the avatar scenes (let me know if you'd like a pic of what this looks like)? It would be nice for future modelers to be able to look at how an avatar scene is supposed to be setup. Perhaps a better way to import would be for the script to look at the Lightwave setup scene and then collect all the necessary meshes, textures, light, position and animation info from there. Then reproduce the scene in Max. Because there's a whole lot more that goes into EoC avatars than just the pso meshes (animation and visible light lens flares, for example). Check page 2 of this thread for more info on this.

And you're also going to need some way to export entire Max scenes to Lightwave scenes. Otherwise you'll still need Lightwave to setup avatar models. Because EoC reads Lightwave scenes directly. Only the mesh objects and textures are converted for flux. But that really shouldn't present a problem, especially if you already understand how Lightwave splits it's software into Modeler and Layout.

How are you planning to handle the uv mapping? Since the FTU texture sheet is a compilation of several seperate texture files (one for each surface on a mesh), and you're importing each surface as a seperate mesh, it would seem logical to extract each mesh's surface texture map back into it's own image file and apply them to the separate meshes. Either that, or reattach all the separate meshes after import and texture map them with the existing DirectX uv mapping from the PSO file.

Whatever you do, fantastic job so far.

btw - your script does support polygons with more than 3 verts, right?

One bug and one annoyance to report:

• Hitting the cancel button in the file browser when selecting an FTU or mesh causes script to crash. But not the X (close window) button.
• After the script interface is closed the MAXScript Listener window is still open. When closed, it asks if you want to save before closing.

*edit*
Out of curiosity, am I right in guessing that SHDR stands for DirectX Shader?

mailto:second_chance@cox.net
The Ultimate Guide To Modding: I-War 2 - Edge Of Chaos
.

I assume the import of meshes is by surface name, correct? I can't wait to see some imported mapping coordinates.

Yes, currently I add some text to the name for debugging purposes, but I'm about to remove that. See below about mapping.

Any chance of being able to import a Lightwave scene as well, to get everything together the way it's set up to be in the avatar scenes (let me know if you'd like a pic of what this looks like)? It would be nice for future modelers to be able to look at how an avatar scene is supposed to be setup. Perhaps a better way to import would be for the script to look at the Lightwave setup scene and then collect all the necessary meshes, textures, light, position and animation info from there. Then reproduce the scene in Max. Because there's a whole lot more that goes into EoC avatars than just the pso meshes (animation and visible light lens flares, for example). Check page 2 of this thread for more info on this.

My plan now is to parse through the lws files and use them to gather all the mesh, maps, and setup parameters.

And you're also going to need some way to export entire Max scenes to Lightwave scenes. Otherwise you'll still need Lightwave to setup avatar models. Because EoC reads Lightwave scenes directly. Only the mesh objects and textures are converted for flux. But that really shouldn't present a problem, especially if you already understand how Lightwave splits it's software into Modeler and Layout.

If I'm the one to write an exporter, I'd do it as a seperate script and work at recreating the entire Flux compatible files. So it would create the .pso, .ftu, .ftc, and .lws files. The .lws is all text and I think I should be able to pull most of the needed values from a compatible place in 3DSMAX like lights, cameras, dummys, etc. I'm only just starting to look at this now.

How are you planning to handle the uv mapping? Since the FTU texture sheet is a compilation of several seperate texture files (one for each surface on a mesh), and you're importing each surface as a seperate mesh, it would seem logical to extract each mesh's surface texture map back into it's own image file and apply them to the separate meshes. Either that, or reattach all the separate meshes after import and texture map them with the existing DirectX uv mapping from the PSO file.

The mapping is pulled in already. In the file you already converted, all you have to do is create a material for each .ftu (load each .ftu and save it adding 1 to the number) and apply the material to the right surface. Look for "TEX = ?" in the mesh name, that's the material number you'd use. That should become automatic in the future.

Whatever you do, fantastic job so far.

btw - your script does support polygons with more than 3 verts, right?

Thanks for the compliment.
No, there does not appear to be anything in the .pso that indicates that FLUX uses it or could support it either. I'm pretty sure they get stripped out in the conversion. I could be wrong.

One bug and one annoyance to report:

• Hitting the cancel button in the file browser when selecting an FTU or mesh causes script to crash. But not the X (close window) button.
• After the script interface is closed the MAXScript Listener window is still open. When closed, it asks if you want to save before closing.

*edit*

I'll look into the FTU bug, the other sounds like something MAX 8 does. I'm actually writing my script in version 6, but I have used it in version 8 as well.

Out of curiosity, am I right in guessing that SHDR stands for DirectX Shader?

SHDR is the 4 character tag in the .pso that denotes the beginning of a surface chunk of data. Other tags are FORM, OHDR, VERT, INDX, DELT, FRAM. Check out the .pso file format documentation on my site.