Source Image Suffixes

[Gildoran]

I'm thinking of using a different standard from D3 for source image suffix meanings...

 

Here's the default D3 suffixes and what they mean:

 

(no suffix) = editor image or diffuse map

_d = diffuse map

_s = specular map

_local = (local-space) normal map

 

I'm thinking of going with the following:

 

_editor = editor image

_diffuse = diffuse map

_specular = specular map

_normal = normal map

 

Or maybe:

 

_e = editor image

_d = diffuse map

_s = specular map

_n = normal map

 

Would anybody object to that?

[sparhawk]

Would this mean, yet another reorg?

[Gildoran]

Nope. Source images are sort of "under the hood", so things will appear entirely the same to mappers. It would just mean that any new materials I add or old materials that I fix will have their source images renamed to follow that standard. It will make no difference to texture department productivity; it's just a design/style thing.

 

Edit: To assuage your fears, I've underlined part of the post.

[sparhawk]

I was less worried about the texture department, as for the mappers.

[OrbWeaver]

I wouldn't want to see _diffuse and _specular, that is just making the names too long and harder to read.

 

_n instead of _local sounds fine, although I don't think there's much in it either way (Doom 3 mappers will be used to _local even though its meaning is not obvious).

[Gildoran]

I didn't like how the suffix styles were inconsistant... having _s for specularmaps, but _local for normalmaps seems wrong to me. (I figure they should either all use full words or all use abbreviations) I guess I'll advocate the single-character one. Another possibility is using a period instead of an underscore... For example:

mywall.n.tga

Any idea if there could be any problems with that on specific operating systems? (I figure most OSes today can handle arbitrary strings, right?)

[sparhawk]

It would be nicer to have underscore, though. If you write scripts to handle a big amount of files based on their extension, then it's easier to do it this way.

[OrbWeaver]

Don't count on Doom 3 being able to handle dots in filenames, in all cases I have tried it has stripped or ignored them.

[Gildoran]

Ok, scratch that then... So is everybody ok with the _n style suffixes?

[sparhawk]

Yup. I am.

[BlackThief]

honestly what's the point except a lot of additional work?

 

as orb said d3 mappers are used to these suffixes, what's the point of changing a proven system?

[Gildoran]

It's just something that's always bugged me, and since I'm eventually going to be going through and renaming the old source images to match the names of the materials that are using them, I figured I'd do this at the same time.

[PinkDot]

If _s stands for specular, then what stands for "selfillumination"?

 

I don't see any particular reason for changing this although I'm still new to D3 standards so I can quickly learn new suffixes. But it might be annoying for many other Doom 3 mappers, texturers and model makers who are used to D3 suffixes and would like to create for Dark Mod some maps in the future...

 

If you find it's necessary to change than it should be announced in the public section before release, I think...

[New Horizon]

I don't see any problem with it personally. Our target audience would be Thief FM makers and we're likely going to get people crossing over from T3Ed, and they are used to _n, _s. It just makes more sense to me to use those suffixes.

[OrbWeaver]

If _s stands for specular, then what stands for "selfillumination"?

 

 

_s has always stood for specular, there is no change proposed in this regard. I suppose for self-illumination an additive stage could be named _a

[gleeful]

honestly what's the point except a lot of additional work?

 

as orb said d3 mappers are used to these suffixes, what's the point of changing a proven system?

 

Sorry, but I have to second that. Seems like an unnecessary nuisance.

[Springheel]

Seems like unnecessary work, to me. And the textures for the models won't be changed, since that would require changing all the material entries again. So we'd have one set of textures with _n and one with _local, which doesn't make much sense.

[sparhawk]

It does make sense to name them consistently. If that is the case, we can stay as it is. If not then we could just use the new naming conventions and see that they are adhered to.

[_Atti_]

i dont think its that important..i for one find it good that the normal map stands out a bit from the filelist..the longer name kinda divides textures for different models..

[Dram]

It does'nt matter to me much, but yeah, there's no gain gotten from renaming them all. Plus _local is still much better then _n imo.