ok, first off as others have said, taking our existing texture loading systems and predefined effects is a pointless endeavor, to that extent having things like $Glow_Map: is pointless. the whole idea of the materials system is to get away from predefined effects what if the modeler wants something that doesn't have a defuse map or they want the defuse map and the shine map to be the same thing or a million other ideas that would be awkward to handle with named textures. materials should be purpose agnostic, the artist should not be constrained by the preconceived notions of whoever designed the system initially.
Thank you for your input. Can you try it again, but this time, read what I said
here? Those options are meant to be shortcuts for existing functionality. All in the name of making this stuff easier to use.
second putting this in the ships table is a bad idea, multiple ships are going to want to use the same effect, and a single ship will want to use more than one material.
This should work in the same way as tbl-level texture replacement. And since I'm hooking into the texture loading mechanisms, the ability to use more than one material is on the same level as using multiple textures is now.
Of course, this is where having multiple UV channels will come in.
materials should be defined in their own table and referenced in the pof on the polygon level. it may sound like this would be a lot of work, but polygon already have an int for defining how they are drawn, and this int would not be needed anymore after the materials system, I am speaking of course of the texture id.
So instead of making this system so that it can be used without having to alter the pof file format, or without altering pof data
at all, you'd want to change pofs as well? I realize that there are advantages to doing it this way, but seriously? I find that trying to change too much stuff at once will only result in failure and misery.
but it will require the addition of a material chunk to the pof to define what textures are given to the material. in order to know how to draw a poly the game needs to know what textures to use, this is where that choice would be made, the material [MTRL] chunk, would be an array that has for each element the name of the material (defined in the material table) and an array of ints that would be the textures defined in the texture [TXTR] chunk. additionally there might be a list of floats or ints to be used as constants in the material, but that's an advanced feature that can be added on later.
See above. I have an intense dislike for squirreling stuff like this away in the pof, when I can just as easily define it in a text file somewhere.
now the real meat of the material system would be the material definition as defined in the material table. a material would be a way of using zero to many textures in one to many passes (each consisting of one to eight stages). to further complicate the matter graphics hardware can only handle so many lights at a time (8 last I checked) and so many textures at a time (which is why there needs to be multiple passes). each pass you would set poly wide values like alpha blending zbuffering ect and in each stage you would set stage settings like setting the first and second texture passed to the material as the input or the result of the last stage and a third texture for the second, blending options, ect. you would need a way of defining what happens on the first lighting pass vs subsequent ones
Again, feel free to break the engine in any way as you please. Me, I'm going to try and make this work within the existing framework first. Because I know what I am capable of (and, more importantly, what I am capable of
testing).