fun with .pso

@Shane:

Cool, I was thinking about the change to the CLIP chunks after I did it and wasn't sure that it would work.

Please try with a few of the "newer" .pso's - the Heavy Corvette is good and complicated.

@davel:

Glad to of helped, good luck!


---
If there is hope it lies with the demo scene.
PSO and FTEX tools: pointless.net/eoc/

Originally posted by Jasper
Please try with a few of the "newer" .pso's - the Heavy Corvette is good and complicated.

Ouch... evil man. Make me convert a model that has like 50 parts or something.



Rendered with a starfield just for kicks. Lord, am I gonna have some new wallpapers for my desktop.

You did it. Everything seems to work fine. Smoothing was turned off for each surface, which is something I hadn't seen before. But that's the work of 10 seconds to fix... I certainly won't complain.

A question: R2D2's FTU2PCX converter has a feature whereby a user can provide the argument *.ftu and the converter will convert all the ftu's in the folder. Would that be possible for yours? Would it be too difficult to integrate?

Either way, you've done an incredible job, Jasper. Just really amazing.

Looking good guys.

@davel, any chance we could get some more info on your script? I know that I'm not the only one here who uses Max for modeling, and a direct importer/exporter would be a godsend. Btw - do you already know that Max and Lightwave use different world axis alignments? Something pointing forward in Max will end up pointing upward and be flipped over in Lightwave and EoC.

@Jasper, I've run into an issue with your converter. I converted the planet PSO to LW and it showed a single surface named Planet. I then converted that object back into a PSO and used it to replace the game planet object. The new planets show up without textures. Which would indicate that the surface name was wrong. Are you sure your converter is reading the entire surface name correctly? So far, all the surfaces that have game specific functions generally have additional info added into the surface name to indicate that the surface is supposed to do something.

Here's the log from the PSO to LW planet conversion. I see it identifies that two textures are used to create the planet appearance (however, there should be three; 2 ground based and 1 cloud texture), but these textures are not indicated in the surface map properties in LW. Perhaps this is why, when converted back to PSO, that no textures showed up. Maybe there are supposed to be some kind of placeholder texture maps that go through the converter with the object. Could you check that out when you have a chance? Thanks.

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

Originally posted by Second Chance

Looking good guys.

@Jasper, I've run into an issue with your converter. I converted the planet PSO to LW and it showed a single surface named Planet. I then converted that object back into a PSO and used it to replace the game planet object. The new planets show up without textures. Which would indicate that the surface name was wrong. Are you sure your converter is reading the entire surface name correctly? So far, all the surfaces that have game specific functions generally have additional info added into the surface name to indicate that the surface is supposed to do something.

Here's the log from the PSO to LW planet conversion.

Code:

pso2lwo Planet_LOD0.PSO found a >PSO2< type: >OHDR< length: 31 31 ver: 1, surfs: 1, textures: 2 %%% (null) %%% %%% Planet_LOD0_0.LBM %%% type: >SHDR< length: 68 68 Surface name: Planet (0.78431379795074463, 0.78431379795074463, 0.78431379795074463, 1.0) base texture : 2 21 : 00100001 1.000000 gloss/spec map: 0 00 : 00000000 0.000000 glow map : 0 00 : 00000000 0.000000 Highlight texture: (null) last 2 ints: 598 1 type: >VERT< length: 19136 19136 type: >INDX< length: 6578 6578 tris: 1096 max points: 598, vert len: 598 :: 1 parse done. Planet

I see it identifies that two textures are used to create the planet appearance (however, there should be three; 2 ground based and 1 cloud texture), but these textures are not indicated in the surface map properties in LW. Perhaps this is why, when converted back to PSO, that no textures showed up. Maybe there are supposed to be some kind of placeholder texture maps that go through the converter with the object. Could you check that out when you have a chance? Thanks.

mailto:second_chance@cox.net

no, only one texture is used.

There are 3 texture 'slots' in each surface chunk, a base/colour texture, a specularity texture, and a luminosity texture.

in the SHDR output you've inserted above:

there are 5 columns, the texture type, an index into the list of textures in the OHDR chunk (in this case (null), and Planet_LOD0_0.LBM), the flags associated with the texture, in hex, and the flags again, in binary. The 5th entry is also not quite well known, for the base texture i think it's diffuse (effects the surface lighting), for the spec map it's the degree of shinyness, and for the lumi map its the degree of luminosity.

In this case the base texture has an index of 2, so it uses the Planet_LOD0_0.LBM texture, the other two texture slots are 0, so they don't use any texture.

The base texture has bits 1 and 32 set in the texture flags, i don't know what these do (I've mostly been playing with the lwo2 converter, i need to go back and work out the last few details of the .pso format).

This is why i wrote the psoinfo tool, so i can dig around a bit more with the files.

(Having the 2st texture in the list in the OHDR be a null string is a bit odd, but some .pso files have that...)

I think flux just handles planets as a special case for the clouds etc.


---
If there is hope it lies with the demo scene.
PSO and FTEX tools: pointless.net/eoc/

Ok, wow. There's a lot of numbery stuff in what you just said that I don't understand. But I did see the miscommunication we're having.

Perhaps I should have said diffuse texture maps. The bit I was refering to is: It says there's one surface and two texture maps. But the thing is, planets are mapped procedurally in flux. There are no planet .lbm files associated with the planet object. Flux assigns 3 grayscale texture maps to each planet based on the .map file. Two ground textures (which are mixed to provide more variety) are colored according to the planet spec in the .map file, and a cloud texture is added on top of that. We currently have no idea what method flux is using to map these textures onto the planets. So maybe two textures is right, and refers to the two ground textures. Maybe after those are mixed and colored the clouds are added over them. One thing we do know is that all the planet object texture files are located in the <font face="Arial">resource\images\planets\</font id="Arial"> folder.

Whatever the case, these are all mixed into a single texture map and contained within the diffuse color map slot of the surface. The planet surface (LW surface not ground surface) also appears to use only a diffuse texture. No shininess or luminosity maps appear to be used.

This is why I believe the surface name is the only important part of the planet object surface. Because it must signal flux to apply the procedural textures. That's why I wanted to make sure that your converter was extracting the whole correct surface name. If it is, and Planet is definitely the whole name of the surface, then there must be another factor in planet texturing that I haven't figured out yet.

Where did you get the Planet_LOD0_0.LBM filename from? Perhaps this is, as I suggested earlier, a placeholder for conversion. Because there is no file called Planet_LOD0_0.PSO, only Planet_LOD0.PSO

*edit*
Hmm. I just converted a nebula skybox PSO and noticed that your converter doesn't extract texture map names, only surface names. (I forgot that the texture maps get reassigned when they're placed into the texture sheets. So the actual names no longer exist.) That's why no texture map was indicated in the planet object surface. I thought that meant there was no map used. My bad on that.

I also noticed that your converter lists the compressed texture files for the skybox with an .lbm extension, but they're actually .ftc and .ftu extensions. Does it always assume .lbm's? I guess it doesn't matter what they are if you have to decompress and reapply the textures yourself anyway, right? I assume the listing is just to let the user know what the texture file names are.

Is it possible to have the converter assign generic map names to the appropriate maps slots in the surface where they're supposed to be? Maybe using names like diffuse_map.IFF, shininess_map.IFF and luminosity_map.IFF? Of course, those maps won't really exist. So then, when you load the object it'll say "diffuse_map.IFF not found. Would you like to specify a different map?" Then you can say Yes and select the actual correct texture map that you've extracted seperately. That would be handy. It's nitpicky I know. But hey, you don't get stuff unless you ask.

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

just a quick note, i'm off net for the next week and a bit, i'll relpy the the vairous q's here when i get back.


---
If there is hope it lies with the demo scene.
PSO and FTEX tools: pointless.net/eoc/