[WMCoolmon]

I code and I still don't get how it's supposed to work.

MHO is that it should be set up so that the last - in a name is checked for a material name, then that material is applied to the texture. This way the ease of -glow -shine could be preserved.

Wait. Unless what you do is specify the material in POFCS, then list the textures you'd like to use with that material So for a "shinemap" material you'd specify your normal, glowmap, and shinemap. For a " colored envmap" material, you specify the same, plus an envmap.

In that case...ugh. Modding just got much more complex. What if you want to use a shinemap but not a glowmap? You have to create a new material (or code in to handle missing textures without losing the entire material).

It's adding great flexibility but at the cost of great unwieldy in texturing. If using -glow -shine is really possible, I don't have any objections - but I do have an idea how it could be made more user-friendly.

In the table, you specify a name for each texture associated with a material. "shine" or "glow" or whatever. Then in POFCS, you specify which material to use, for a base texture. The material data is stored in a special chunk.

Then to use multiple textures you just add the proper texture-name-suffix (which was specified in the tbl) to the end of the base texture name specified in POFCS. The default material would supply "-glow" and "-shine" tags, and "-bump" later on.

[Bobboau]

shinemap is the name of the material
fighter01-01a is the first texture wich in shinemappinf as I have it defined is the defuse map
fighter01-01a-glow is the second texture wich acts as the glow map in the material
fighter01-01a-shine is the third texture, in the material definition the third texture is the shine map

[WMCoolmon]

Yes, but you still end up specifying those in POFCS, just another step to forget once you've made a new texture and saved it. You also shouldn't be using different name patterns for textures anyway, it just makes things more messy.

Plus, there's no need for nasty hacks; if the MTRL chunk doesn't exist, then the default material is used; it doesn't have to spit out the old names, the material would define them along with any new ones that are added.

[Bobboau]

ok I am going to
A) make a material table that has all of the available material capablities
B) make a hack that handles the current pof data like it is currently handled

modding will get more complex only after I have gotten PCS and 3ds2pof updated with the new, it will only get more complex to the order of haveing to manualy specify wich material you want to use (ie you'll have to write specmap or somehithing to that effect) and the specific textures to use with it.

[Bobboau]

right now we have a rube goldberg machine loading textures and drawing ships.

[Taristin]

Hell, if it was as easy as having the max exporter keep all of the material settings from the Max material editor, it'd be easy as all hell.

[Bobboau]

yeah, that'd be about what you'd have, at worst you'd have to type wich material you wanted.

[Bobboau]

so then, everybody's all clear and convenced on how good an idea this is?

[WMCoolmon]

I still like my idea better.

But if it brings bump mapping, I suppose I can't complain. And the table seems flexible enough to add more material types, although what that exactly would bring (beyond bumpmapping) I'm not quite clear on yet.

[Bobboau]

anything, this gives almost infinite flexability to the artist.

[StratComm]

Actually there are other advantages to specifing additional maps explicitly; right now a lot of shinemapping uses the same shinemap for multiple files; if we could specify the same shinemap across multiple materials, it would help reduce the redundancy of maps and thus cut down on download sizes.

[Bobboau]

exactly.

[Flaser]

I don't think our aritsts have grasped the potential in this sysytem yet.

What Bobbau makes will a tons of things possible and open a myriad of tricks.

Examples:

-Homeworld-esque ships where you can set colors for specific parts of the texture (this may call for some further tweaks, but the material system would make it a lot more straightforward)
-Separate textures for parts of the ship (lining, edges, machinery) that's paintjob independent, enabling ships have a custom paintjob of their own
-Creating faction/squad/personal painjobs would be a breeze
-The decal system could be revived
-Custom damage textures

I hope Bobb had an object oriented approach in mind (his definition of multilevel rendering (complex-->simple) is pretty close) that would allow a flexible texture development.

(For example glass, metal, matt or scrathed surfaces could be a couple of base templates that any texturer may find handy to originate his materials from)

As I see it - BTW please clarify any orbital idiotism on my part Bobb - the material system would make it possible to have layers for texturing just like PSP or Photoshop has and any 2D artist knows with that the possibilities are endless.

[Turambar]

http://pcgamemods.com/11163/

we can use this, or the one that comes with Far Cry now!
w00t, normal maps

DaB was talking about animated Shinemaps sometime before, will this make that possible?

[DaBrain]

Animated shinemaps are already possible AFIAK.

It's just like about one mod that needs it. So I guess it's not really a top priority.

Still I hope we can use shader 'animations' instead of animated textures whenever it's possible.

Might save some memory. (Like the water shader.)

[WMCoolmon]

Originally posted by StratComm
Actually there are other advantages to specifing additional maps explicitly; right now a lot of shinemapping uses the same shinemap for multiple files; if we could specify the same shinemap across multiple materials, it would help reduce the redundancy of maps and thus cut down on download sizes.

Ahh, I didn't think of that. Kudos.