fun with .pso

yup, but .lwo's don't store surface normals, ...

Not arguing this (I am aware you're far more knowledgable about LWO format than I ) ... but curious. If the normal isn't stored then how would any program (including LW) know how to open a model and not have some of the polys flipped in the wrong directions? Even direct caculation using the points of the poly would only be correct 50% of the time.

... SMoothing ANgle, this isn't stored in the .pso's

Again, I can't understand how Flux would do it then. I've tested smoothing before and determined that Flux does pick up the exact smoothing angles set in the LW model. In my experiment I'd built a cube and given different smoothing values to each surface. The original purpose was to determine if Flux used the same 'average value' approach to adjoining surfaces that LW does (it did).

Jasper, you are the MAN!



All textures applied perfectly.

I am awed. [8D]

That looks awsome! Very, very cool. Shane, did you have to do any fixing at all?

That might present a problem. The identical vertices are there on purpose to break up the Phong shading (smoothing process).

Agreed. This is pretty important. Without UV mapping, Lightwave objects are not so much a single continuous mesh as they are a collection of separate mesh patches that happen to be touching each other. Because there needs to be a physical break between adjacent surfaces.

Not arguing this (I am aware you're far more knowledgable about LWO format than I ) ... but curious. If the normal isn't stored then how would any program (including LW) know how to open a model and not have some of the polys flipped in the wrong directions?

I believe the normal is determined by the vertex order. It always goes one way. If you flip a poly, it reverses the vertex order. So by counting out the vertices, the machine always knows what side the normal falls on. I believe that this is how 3D engines generally work.

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

That looks awsome! Very, very cool. Shane, did you have to do any fixing at all?

Not a bit. Just converted the textures and the PSO. LW did the rest. Is not the great and powerful Jasper wonderous? :D

I believe the normal is determined by the vertex order. It always goes one way. If you flip a poly, it reverses the vertex order. So by counting out the vertices, the machine always knows what side the normal falls on. I believe that this is how 3D engines generally work.

That makes sense... Thanks.

Reflection: I've gotten some strange results when cranking up the reflective properties of a surface.

A note on reflection maps: You can't just make a surface generally reflective in a real-time environment. This kind of pure reflection is designed to be used in slow rendering 3D packages, where the actual environment can be traced to the reflective source and rendered correctly. For real-time applications you must use reflection mapping, which is merely a fast simulation of reflection of an ambiguous pattern (the reflection map). Cranking up the reflection value alone (with no ref map) will likely result in weird behavior because the game engine is looking for a reflection map to use, but there isn't one.

In Lightwave, reflection mapping is added to a surface by either increasing the reflection value of a surface or placing a grayscale alpha mask in the reflection texture slot. An image alpha mask both overrides the reflection value (with the gray to white levels) and limits the parts of a surface that are reflective (with the black areas). Then, in the Environment tab, you simply select a reflection map to act as the image to be reflected in the refective parts of the surface.

Now, I know EoC uses reflection mapping because; I've seen them, there are environmental reflection maps included in the resource file, and the converter instructions talk about switching them off for mip-map generation. (It's also quite common for 3D games in general.) But has anyone ever sucessfully added reflection maps to any models?

*edit*
Jasper. I don't want to take away any of your time from writing code. . . but is there any chance of getting some documentation with the tools? Thanks.

Trivia: PSO stands for Particle Systems Object. I thought that would be fun to mention.

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

A note on reflection maps: You can't just make a surface generally reflective in a real-time environment.

Yes... I'm well versed in the use of reflection maps. I was only speaking of Flux's handling of the reflection surface property.

Now, I know EoC uses reflection mapping because; I've seen them, there are environmental reflection maps included in the resource file, and the converter instructions talk about switching them off for mip-map generation.

The files located in images/envmaps are reflective 'highlight' maps. It was my assumption that these were directly linked to the shader material functions; the modeler names the surface the proper name to invoke the shader function and these maps will be used when the material is displayed to give added reflective highlights. (All just personal assumption; grain-of-salt rule in effect. )

As far as creating a 'real' reflection map in-game... I don't see how it could be done. The engine would have to ray-trace the environment at least 30 times per second. Maybe someday... but not yet. And definately not on my rig.

Given the relative uselessness of reflection maps, I doubt they would be implemented by just throwing a map in the LW surface reflection slot. But again... I've never made any tests in this area. Perhaps you should give it a try.