fun with .pso

Good point, Shane. Sounds like you guys are into an area I don't know much about. Is it possible that the resource files contain the setups for the original rendered animations as extraneous files that were never removed before shipping? That kind of thing has been known to happen.

And fiddling with the converter.exe file selection dialoge box shows that it can read MorphGizmo files.

Cool.

BTW, the "Tutorial On Managing Odd-Shaped Open Polys" looks like it's a workaround for converter.exe not converting concave polys to triangles properly - the "Triple function" in lw converts everything to triangles and so converter.exe dosn't have to.

(.pso's only contain triangles)

Interesting. This is something I'd like to hear more about. Analysis of the conversion process on my models has shown pso's that contain the same number of polygons as the original optimized model. Indicating that the converter did not convert all polys to triangles. It's possible that all the original EoC pso models contain only triangle polygons because that's how the designers built them. They are extremely low poly models and optimization may not have been necessary (or possible in earlier versions of Lightwave. Shane, does version 5 have a poly optimization tool?). My models are much more complex and higher in polygon count than the originals. They require optimized polygons to keep the count from getting excessive. Some of my models would nearly double in poly count if converted to all triangles. They conversion log shows that they retain their optimized polys.

But yes, it is a workaround. It seems that flux just doesn't like concave polys.

If you happen to discover any additional info on exactly how the conversion process works, please post. I'd be very inetrested.

. . .then i can very probably make a script to patch the .pso's to add back the glow and spec maps - which would remove the requirement for lightwave 5.6.

That would be fantastic! I would be very thankful. Would you like some info on some of the wierd changes that happen to exported 5.6 files?

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

BTW, the "Tutorial On Managing Odd-Shaped Open Polys" looks like it's a workaround for converter.exe not converting concave polys to triangles properly - the "Triple function" in lw converts everything to triangles and so converter.exe dosn't have to.

(.pso's only contain triangles)

Interesting. This is something I'd like to hear more about. Analysis of the conversion process on my models has shown pso's that contain the same number of polygons as the original optimized model. Indicating that the converter did not convert all polys to triangles. It's possible that all the original EoC pso models contain only triangle polygons because that's how the designers built them. They are extremely low poly models and optimization may not have been necessary (or possible in earlier versions of Lightwave. Shane, does version 5 have a poly optimization tool?). My models are much more complex and higher in polygon count than the originals. They require optimized polygons to keep the count from getting excessive. Some of my models would nearly double in poly count if converted to all triangles. They conversion log shows that they retain their optimized polys.

Could you send me one of the .pso's? (or point me to where i can find one), my pso parsing code assumes triangles, and so far thats held up, it would be good to double check.

But yes, it is a workaround. It seems that flux just doesn't like concave polys.

If you happen to discover any additional info on exactly how the conversion process works, please post. I'd be very inetrested.

The only thing i've seen is from running a few of the collision hull .lwo's through converter.exe with the debugging tuned all the way up.

AFAICT it converts all the poly to triangles, turns the projected textures into texture co-ords, and calculates surface normals.

. . .then i can very probably make a script to patch the .pso's to add back the glow and spec maps - which would remove the requirement for lightwave 5.6.

That would be fantastic! I would be very thankful. Would you like some info on some of the wierd changes that happen to exported 5.6 files?

mailto:second_chance@cox.net

yes! if you could send me a "wierd" .lwo that would be best (and some description).

Don't know if you've got time, but creating a cube with one face a plain diffuse map, one a diffuse + spec map, and one diffuse + spec + glow, (leave the other 3 blank), and then send it to me as a .lwo, i can then see what converter.exe does to it.

Would be nice to have a know-good version to compare against - Shane - has your dongle appeared?

Originally posted by Second Chance
Interesting. This is something I'd like to hear more about. Analysis of the conversion process on my models has shown pso's that contain the same number of polygons as the original optimized model. Indicating that the converter did not convert all polys to triangles. It's possible that all the original EoC pso models contain only triangle polygons because that's how the designers built them. They are extremely low poly models and optimization may not have been necessary (or possible in earlier versions of Lightwave. Shane, does version 5 have a poly optimization tool?). My models are much more complex and higher in polygon count than the originals. They require optimized polygons to keep the count from getting excessive. Some of my models would nearly double in poly count if converted to all triangles. They conversion log shows that they retain their optimized polys.

Tested this by creating a box in LW7.5 composed of quads and exporting it to LW5.6 format (which loses the texture info but that shouldn't affect this particular test). Then translated to PSO object, then back to LW object. When opened in LW, the box was composed of tri's.

This seems to indicate that the converter automatically splits quad polys.

Would be nice to have a know-good version to compare against - Shane - has your dongle appeared?

It has not but I'll give Newtek a call tomorrow morning and see what's up. I'd forgotten about it; been playing with the converted models.

In the meantime:

@Cambragol: If I created the box and textures Japser needs, and sent them to you, could you apply the textures with LW5.6 and send them to him?

Originally posted by Shane


@Cambragol: If I created the box and textures Japser needs, and sent them to you, could you apply the textures with LW5.6 and send them to him?

Can you do me a box in LWO2 format and send it? (using uv mapping for the textures).

I've got pso -> lwo2 conversion working, but i'm not sure what the best way of matching the uv co-ords to a texture and a surface is.

The only thing i've got that makes lwo2 files is wings3d, it exports the uvmap, but not the stuff to link it with a surface and a texture.

Jasper, I'll send you a few files. My Tie Bomber (nice and simple 1-piece mesh) with textures; as the original LW 6.5 object, exported as a 5.6 object and the resulting pso. Then you can play around with and dissect all versions any way that works for you. Sadly, the converter does not allow copy/paste from the log. So you'll have to do your own conversion to actually see the results. Let me know if you still want a cube anyway.

The main bit of weirdness when exporting a newer LW object as a 5.6 object is that in the surface editor, when you open the texture editor for the color channel, it shows the original texture map and it seems to add a new texture layer with no map specified and the blending mode set to alpha. If you don't have Lightwave, I can take a screenshot so you can see what I'm talking about. This happens on every single lwo object exported to 5.6. I suspect it may have something to do with the fact that newer versions of Lightwave allow you to texture objects in Modeler, while 5.6 and older required you to texture them in Layout (along with everything else). Maybe this is somehow interfering with the other map channels and prevents working conversion.

Tested this by creating a box in LW7.5 composed of quads and exporting it to LW5.6 format (which loses the texture info but that shouldn't affect this particular test). Then translated to PSO object, then back to LW object. When opened in LW, the box was composed of tri's.

This seems to indicate that the converter automatically splits quad polys.

That would probably be Jaspers pso to lwo converter doing that. He said that his parsing code assumes triangles, and so that should be what it's building. Check the number of polys the cube has (six, I assume) versus the number of tris (12?), then see what the pso converter output says the number of polygons is (with debugging set to maximum). It should say the resultant pso object has the same number of polys that the original lwo cube had.

*edit*
Jasper, reguarding your last post: You do know that Lightwave 5.6 (and by extension EoC) doesn't use UV mapping, right? Lightwave 5.6 and lower used a custom projection mapping method peculiar to Lightwave only. That's why no one has ever made a sucessful Lightwave converter that keeps textures intact. Apparently the LW projection mapping doesn't correspond to the regular planar UV mapping methods other packages use as standard.

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

Originally posted by Second Chance

Jasper, I'll send you a few files. My Tie Bomber (nice and simple 1-piece mesh) with textures; as the original LW 6.5 object, exported as a 5.6 object and the resulting pso. Then you can play around with and dissect all versions any way that works for you. Sadly, the converter does not allow copy/paste from the log. So you'll have to do your own conversion to actually see the results. Let me know if you still want a cube anyway.

Cool! does the 6.5 .lwo use uv mapping?

The main bit of weirdness when exporting a newer LW object as a 5.6 object is that in the surface editor, when you open the texture editor for the color channel, it shows the original texture map and it seems to add a new texture layer with no map specified and the blending mode set to alpha. If you don't have Lightwave, I can take a screenshot so you can see what I'm talking about. This happens on every single lwo object exported to 5.6. I suspect it may have something to do with the fact that newer versions of Lightwave allow you to texture objects in Modeler, while 5.6 and older required you to texture them in Layout (along with everything else). Maybe this is somehow interfering with the other map channels and prevents working conversion.

Tested this by creating a box in LW7.5 composed of quads and exporting it to LW5.6 format (which loses the texture info but that shouldn't affect this particular test). Then translated to PSO object, then back to LW object. When opened in LW, the box was composed of tri's.

This seems to indicate that the converter automatically splits quad polys.

That would probably be Jaspers pso to lwo converter doing that. He said that his parsing code assumes triangles, and so that should be what it's building. Check the number of polys the cube has (six, I assume) versus the number of tris (12?), then see what the pso converter output says the number of polygons is (with debugging set to maximum). It should say the resultant pso object has the same number of polys that the original lwo cube had.

I don't manipulate the polys data, just shuffle it about a bit, in all the .pso's i've looked at the number of verts has been divisible by 3, now there is some wierdness in the INDX chunk in .pso files, it could be that the first 2 bytes somehow encode a count of how many triangles, and how many quads (or other poly's) are in the rest of the chunk, but so far assuming it's all triangles has worked.

*edit*
Jasper, reguarding your last post: You do know that Lightwave 5.6 (and by extension EoC) doesn't use UV mapping, right? Lightwave 5.6 and lower used a custom projection mapping method peculiar to Lightwave only. That's why no one has ever made a sucessful Lightwave converter that keeps textures intact. Apparently the LW projection mapping doesn't correspond to the regular planar UV mapping methods other packages use as standard.

mailto:second_chance@cox.net

Yes, one of the things converter.exe does is to convert the LW style projection stuff to per-vertex texture co-ords - which as far as i can tell is the same thing as uvmapping.

The OpenGL viewer thing I wrote just takes the uv co-ords in the .pso and uses then to do the texture mapping.

My email is jasper _at_ pointless.net, or if you pefer ftp://thingy.pointless.net/incoming/ allows uploads.