Texture Culling

[Fidcal]

angua: Have you got this to actually work? I've just tried it on a section of wall which is func_static and can see no difference.

 

Pinkdot: Thanks again. I'll try that tomorrow.

[Crispy]

angua: Have you got this to actually work? I've just tried it on a section of wall which is func_static and can see no difference.

Does the material on the wall contain the colored keyword in its definition (in the .mtr file)?

 

Re: console commands reference, Google turned up a few (e.g. http://www.doomwadstation.com/doom3/console/ ), but I can't find any that are particularly good.

 

If you type the beginning of a console command in D3 and press Tab, you'll get a list of commands and cvars that begin with that string, which is quite useful. Also, just typing the name of a cvar will give you its current value and a brief description of the cvar.

 

There are also some useful cvars that we've added in TDM. I don't have a list, but some of them start with "tdm_", so you can use the tab trick to find them.

[Fidcal]

So it needs 'colored' in the material file and 'color' in the property in Dark Radiant? It might be more trouble than the other method which only requires the material file to be changed.

[angua]

Yes, the material needs "colored" in the shader to make this work. (Sorry if I wasn't clear enough.) I've found one brick texture which has that (stone/brick/sloppymortar_colored) and it definitly works with this one (You can see an ugly green and an ugly pink version of the same stone texture)

[Crispy]

So it needs 'colored' in the material file and 'color' in the property in Dark Radiant? It might be more trouble than the other method which only requires the material file to be changed.

Ah, but it's easy to change things in DarkRadiant. Changing materials is a bit more involved since it means you have to start managing assets separate from your map file. So if the material already has "colored" as standard then it makes recolouring materials easier. Might come in handy at some point.

[Fidcal]

Yes, this might be useful for entities with multiple textures to change them all with one color property. A whole (solid/distant) building might be given a different look along with resizing and rotating. I guess there would be a performance hit if all materials had the 'colored' property like my other idea.

[OrbWeaver]

I think "colored" is a shortcut for

 

red shaderParm3
green shaderParm4
blue shaderParm5

 

Where shaderparm3 - 5 are automatically set from the "color" key on the parent entity (the actual numbers may be different, I'm not certain it uses 3 - 5).

[Fidcal]

Note that the values are multiplied with the pixel values on the texture. Hence multiplying a colour channel with 1 doesn't change anything:

rgb 1

Is this done by Doom when the game is compiled or by Dark Radiant? If DR it would be useful if it allowed greater than 1. I mean if the blue component is only say 0.1 in the original then there is no way to increase it by multiplying by 1 or less.

 

[EDIT] Except by using blend add as well as Pinkdot described.

[OrbWeaver]

Is this done by Doom when the game is compiled or by Dark Radiant?

 

Neither, it is part of the rendering process which is done in realtime. I suspect that the colour value is assigned to the model vertices, not the texture itself, and then an OpenGL blend mode used to multiply the mapped texture with the underlying vertex colour.

[Nyarlathotep]

Don't the shaders have to be compiled themselves?

[OrbWeaver]

Don't the shaders have to be compiled themselves?

 

Compiled into what? All a shader does is specify which images should be loaded (at runtime), what properties the material should have, and what (if any) processing should be performed on the images when they are loaded.

[Nyarlathotep]

Not all processing can be performed on load, e.g., parallax or relief mapping. Maybe I'm confusing D3 shaders with pixel shaders?