Texture Culling

[Springheel]

As Sneaksie suggested a while ago, there are lots of textures on SVN that are either below par (many were made very early on before we knew what we were doing), or just not necessary (like the 13 different versions of basic concrete).

 

I've found a few other places where we can cut down on unnecessary textures, however. There are a few duplicated normalmaps (different filenames but the same file). There are some specular maps that just aren't needed, and some flat ones (just a solid grey) which can be replaced by a material stage. Additionally, I know there are several diffusemaps that are just the same image but a different colour. I finally got playing around with the rgb keywords in shaders and realized they could save us a lot of space in those cases.

 

Instead of having three different versions of the same rock texture, one greenish, one bluish and one greyish, we could just pick one and then use the rgb shader in separate materials to modify the colour. We still wind up with three (or more) different textures, but only one file is needed. That's a big space saver.

 

I'm working on a bunch of weapon models at the moment, but I'd like to get started on this soon. If individual artists want to play around with this and find ways to cut down on their files, that's great too.

[greebo]

I somehow changed my mind about the concrete textures. They sure look inappropriate when used on large surfaces like walls or floors, but they do a good job when it comes to simulate mortar. For instance, I used one concrete texture for the window stones in the abandoned city shots I recently posted. These are just small brushes and it looks believable enough. What I'm trying to say is, that even textures that don't look useful at the first glance can still be a life saver.

 

That said, there might be some redundant concrete textures looking basically the same, which we can of course cut down.

[sparhawk]

As long as the concretes are not really duplicates, I don't see a reason why to remove them. If they are below par, it's ok, but removing them just because we have "enough" doesn't cut it IMO. After all, they can be also used to have similar surfaces without repetition.

[Springheel]

Yeah, I kept about five or six of the good ones, but there's still eleven or twelve other ones! If we're so concerned about space that we have to use .dds textures, then keeping that many marginally useful textures seems pretty pointless, especially when we're so concerned about download size. The five or six that I renamed should be more than enough for mortar.

[sparhawk]

I don't think we should be obsessed with downloadsize. And there is even less point to already have some textures, and remove them.

[SneaksieDave]

Yeah, I kept about five or six of the good ones...

Does this mean there's already stuff being removed? I think any removing of items should be a team decision (or at least among those in the department/doing the work, if for example, programmers don't want to waste time on it).

 

I mention this in part because there will no doubt be confusion around particular textures which are seen as duplicates but in fact are not (I'm thinking of what used to be a few of mine in the blocks* category - for example, one was a rough, weathered blocks, while another, for the same block layout, was a crisp new wall normal). Also, before differently colored diffuses get removed, note that a simple RGB shift is only used once so far (for a brick texture I made), as others involved more than just that shift (for instance, to preserve the mortar color, or have off-colored highlights or details). Finally note that RGB is a keypair for entities, so these walls would have to be func_statics, which quite limits and even interferes with normal brush usage.

[Springheel]

Does this mean there's already stuff being removed?

 

I didn't remove them; I just didn't rename them.

 

Finally note that RGB is a keypair for entities, so these walls would have to be func_statics, which quite limits and even interferes with normal brush usage.

 

Not quite sure what you mean here. It's a material shader keyword, and has no relation to entities that I know of.

 

I just tested it on brushes and it works fine. The wall on the right is the regular texture. The wall on the left is the same texture file, but with an rgb offset in the material.

 

 

So basically, the same three texture files can provide a myriad of different textures, all just by changing the rgb values. This will be a really useful way to both cut down on space and increase the value of our existing textures, since anyone with a text editor can make new versions this way.

[SneaksieDave]

I thought you were referring to the editor-assignable color keypair Gildoran set up on one of my bricks. Those have to be func_statics for it to work. Aside from that, the other limitation exists in that if a diffuse differs by more than just a color shift (e.g., the case of different colored stones with same colored mortar) then it wouldn't be usable, but this is definitely a useful 'when appropriate' method.

[Springheel]

Don't worry, I wasn't suggesting we go through the textures with a chainsaw.

 

I know there are definitely some textures that can be replaced in the models folders with this method, and probably some in the textures as well, but its real benefit is in making even more variations of existing textures.

[Komag]

I think priority should be placed on making things easy for users/mappers. Is adjusting RGB easy? Can it be done in DarkRadiant?

[Springheel]

It's as easy as copying the existing material file and replacing:

 

diffusemap textures/darkmod/metal/flat/steel_scratched01_nontiling

 

with,

 

{blend diffuseMap

map textures/darkmod/metal/flat/steel_scratched01_nontiling

color 1.5, 1, 0.5, 1 }

 

I don't know if DR can modify material files on the fly, but it would certainly be a powerful tool.

[Komag]

hmm, I found the mtr files I think, in darkmod/materials/, but I'm not sure what to do or what to touch. If it changes the texture's color, how did you have the original color in the same screen? I'm a little intimidated by all that code in the files, not my cup of tea.

[Springheel]

I found it intimidating too, at first, but it's really quite easy. All you do is take one of the original material entries and copy and paste it.

 

Change the material name.

 

Then you replace the "diffuse blah/blah/blah" line with the "blend diffusemap" lines I mentioned above.

 

{blend diffuseMap

map textures/darkmod/metal/flat/steel_scratched01_nontiling

color 1.5, 1, 0.5, 1 }

The numbers after "color" are <redvalue>, <greenvalue>, <blueval>, <alphaval>. The original texture is multiplied by those values (so to add more colour, put in a value higher than 1, to keep the same, use 1, and to make it darker, use a value lower than 1).

 

 

Here's an example with all the scary code.

 

The first one is the original. The second is a darker version. The bold parts are the things that were changed.

 

textures/darkmod/metal/flat/nontiling/steel_scratched01

{

metal

twosided

forceshadows

 

diffusemap textures/darkmod/metal/flat/steel_scratched01_nontiling

bumpmap textures/darkmod/metal/flat/steel_scratched01_nontiling_local

specularmap textures/darkmod/metal/flat/steel_scratched01_nontiling_s

{

if ( parm11 > 0 )

blend gl_dst_color, gl_one

map _white.tga

rgb 0.40 * parm11

}

{

if ( parm11 > 0 )

blend add

map textures/darkmod/metal/flat/steel_scratched01_nontiling

rgb 0.15 * parm11

}

}

 

textures/darkmod/metal/flat/nontiling/steel_scratched01_dark

{

metal

twosided

forceshadows

 

{blend diffuseMap

map textures/darkmod/metal/flat/steel_scratched01_nontiling

color .1, .1, .1, 1 //color <redval>, <greenval>, <blueval>, <alphaval>

}

bumpmap textures/darkmod/metal/flat/steel_scratched01_nontiling_local

specularmap textures/darkmod/metal/flat/steel_scratched01_nontiling_s

{

if ( parm11 > 0 )

blend gl_dst_color, gl_one

map _white.tga

rgb 0.40 * parm11

}

{

if ( parm11 > 0 )

blend add

map textures/darkmod/metal/flat/steel_scratched01_nontiling

rgb 0.15 * parm11

}

}

[OrbWeaver]

I don't know if DR can modify material files on the fly, but it would certainly be a powerful tool.

 

No it can't, and for my part I am opposed to this functionality for a couple of reasons.

 

1. It alters the DarkRadiant paradigm from a consumer of assets to a producer as well, which raises practical issues relating to the ability to edit resources within a PK4, the default location for autogenerated MTR files, the naming of new materials and so on. These are not insurmountable problems, but I am not sure there would be a clean or elegant solution to them.

2. Attempting to shoe-horn an inappropriate workflow onto an implementation that does not correspond to it is generally a recipe for unpleasantness. Just look at the HTML files generated by Microsoft Word for an example of what happens when you try to use a "clever" tool to autogenerate data which is intended to be written correctly by hand.

 

I would not be opposed to writing tools to assist with creating material definitions, either as a DarkRadiant plugin or a separate Python program, but I don't think we should try and hide the use of MTRs behind some kind of "fake" realtime editor.

[New Horizon]

I seem to remember someone having written an editor like this for Quake 3. Being able to do this with DR via a plugin would be especially nice. Anything that can allow users to see the result of their changes within the DR preview would be a welcome option.

[OrbWeaver]

I could imagine a tool which worked similar to the following:

 

1. User activates tool from menu or Plugins list.

2. Tool provides a dialog for editing the components of a material, e.g. with browsers for texture images, sliders or checkboxes for other parameters etc. This could be based on an existing material if required.

3. User adjusts dialog contents and then chooses an MTR file to save the definition to (either by creating a new MTR, or appending to an existing one).

4. Assuming the user saves to the correct directory, e.g. within the darkmod folder, DarkRadiant will reload the materials and make available the new definition.

 

I would almost be tempted to recommend writing this as a separate Python script rather than a DR plugin, since it might be useful for other Doom 3 mappers who don't want to download and switch to DarkRadiant but would still benefit from easy material editing.

[greebo]

The advantage of putting this into DarkRadiant would be to use all the existing utils (like checking for name conflicts of existing shaders, gtkutils, a possible render preview and of course me being familiar with the codebase).

[OrbWeaver]

Yes, there are of course advantages as well (integration with the VFS springs to mind, a separate script would need to build the VFS itself in order to browse for textures).

[greebo]

Actually, I'd be interested in doing that - I think this is could be a suitable project for two or three long winter nights.

[sparhawk]

Well, yes, this is definitely a nice feature to have, but I think it would be even better to push the main mod forward. Since you said you wanted to do the inventory, I think currently this helps more, because all mappers can wield a text editor, and there is not such a pressing need for this feature.

[greebo]

Yes, I started reading the existing inventory code yesterday evening, but didn't get very far. I expect to finish reading today, so that I can start working on it this evening or tomorrow.

[sparhawk]

Cool! You might talk also to joe (the new coder), as he is doing the purchase screen, and he needs to connect to the inventory as well.

[Springheel]

I don't see this as a big priority either, since it's quite easy to have a text editor open along with the map editor. You can adjust your values in the text editor, then "reloadsurface" in the map editor to immediately see your changes.

[bob_arctor]

Sounds good, if the technique is on the wiki you can just copy and paste, don't have to memorise the exact code.

[Fidcal]

Questions:

 

. Is alphaval a transparency value?

 

. If I copy and paste a material def in a material file, how does it get to the end user, the player? Do I have to keep a note to make sure that material file is included in my map archive? Won't it conflict with the other material defs? Should I not rather always save as a separate material file with a unique definition - that is, not used in the eventual DM resources?

 

. What does add more colour mean? Increase the colour saturation like when you turn up the colour control on the PC monitor or TV? Or does it mean brighten (ie, in contrast to darken)?

 

. I don't really understand this rgb 0.15 * parm11 or how it's used.