datiswous Posted November 18, 2021 Report Share Posted November 18, 2021 (edited) If in DR in light properties I set the light type to blamplight or blamplight2 and make it switchable via some switch, it does not go on or off via the switch. When I use blamplight_cv for example I can do that. I also found that if I change the color of the light, I don't see this in-game, there it's still white (if I've set it to yellow). Maybe this is normal for this type of light, but it should be in the description what it can and cannot do. Edited November 24, 2021 by datiswous solved Quote Link to comment Share on other sites More sharing options...
datiswous Posted November 22, 2021 Author Report Share Posted November 22, 2021 (edited) Maybe this should be in section Art Assets or tech support? Anyway, I thought it would be good to mention this info somewhere, but aperently nobody cares.. Edited November 22, 2021 by datiswous Quote Link to comment Share on other sites More sharing options...
greebo Posted November 22, 2021 Report Share Posted November 22, 2021 23 minutes ago, datiswous said: but aperently nobody cares Is the situation really that gloomy? From what it sounds like, I think it's not a DR bug, but something related to the shader, so it might indeed get some more attention in the editor's guild. Generally, to be of assistance with issues like this I'd need to look deeper into it, like setting up a test map and check out the materials. I didn't do that since I was occupied with other stuff, and I assume that applies to all of the other people who didn't respond here. Quote Link to comment Share on other sites More sharing options...
datiswous Posted November 22, 2021 Author Report Share Posted November 22, 2021 (edited) 11 minutes ago, greebo said: Is the situation really that gloomy? From what it sounds like, I think it's not a DR bug, but something related to the shader, so it might indeed get some more attention in the editor's guild. No I guess not. I just wonder if posting a thread about it is the best way or is it better to directly place this in a bug report? You can move it there if you think it's a better place for this thread. And maybe I should prepare a testmap so it's quiker for people to take a look. Edited November 22, 2021 by datiswous Quote Link to comment Share on other sites More sharing options...
OrbWeaver Posted November 22, 2021 Report Share Posted November 22, 2021 If I understand correctly, there is a specific light shader which does not respond to colour or brightness adjustments? This is something light shaders can do, for example there are certain shaders which use a fixed colour or texture (possibly animated) which are not intended to be controlled via the color spawnargs. Definitely not a DR problem as Greebo says, and it may not even be a "bug" as such, since it is up to the shader author whether a particular shader responds to colour (I wonder if the "_cv" suffix means "colour variable" or something, but that's a wild guess). One could argue that this is a usability issue however. Perhaps we need some better organisation of light shaders, to distinguish the generic shaders which respond to colour and can be used anywhere, and special-purpose shaders which may have fixed colours or textures and are designed for specific purposes like association with a particular entity? Quote DarkRadiant homepage ⋄ DarkRadiant user guide ⋄ OrbWeaver's Dark Ambients ⋄ Blender export scripts Link to comment Share on other sites More sharing options...
greebo Posted November 22, 2021 Report Share Posted November 22, 2021 4 hours ago, datiswous said: I just wonder if posting a thread about it is the best way or is it better to directly place this in a bug report? Perfectly sensible approach to describe it on the forums first, to clarify whether it's an actual bug or not. It can still be converted to an actual issue later. 1 Quote Link to comment Share on other sites More sharing options...
datiswous Posted November 22, 2021 Author Report Share Posted November 22, 2021 2 hours ago, OrbWeaver said: One could argue that this is a usability issue however. Perhaps we need some better organisation of light shaders, to distinguish the generic shaders which respond to colour and can be used anywhere, and special-purpose shaders which may have fixed colours or textures and are designed for specific purposes like association with a particular entity? Yeah it took me a while to figure out that it was because of the shader that I couldn't make the light swithable. This is the shader definition: lights/blamplight2 { { forceHighQuality //map makeintensity( lights/blamplight2.tga ) map lights/blamplight_cv.tga colored rgb bathroomtable[ time *.3 ] zeroClamp } } Does the rgb value set a specific color and which therefore can't be changed in the light properties window? Quote Link to comment Share on other sites More sharing options...
OrbWeaver Posted November 22, 2021 Report Share Posted November 22, 2021 2 hours ago, datiswous said: Does the rgb value set a specific color and which therefore can't be changed in the light properties window? Yes, I believe so. rgb means "set the RGB colours to this specific value", and the value in this case comes directly from the lookup table, not the spawnargs. colored is short for color parm0, parm1, parm2, parm3 which means "take the RGB values directly from the spawnargs", but this is overridden by the rgb declaration which I believe means that colored does nothing in this case. The difference with the blamplight_cv shader is that the spawnarg values are explicitly multiplied by the value from the lookup table, so the resulting colour should take both into account (again, there is a colored declaration which I think is doing nothing). 1 Quote DarkRadiant homepage ⋄ DarkRadiant user guide ⋄ OrbWeaver's Dark Ambients ⋄ Blender export scripts Link to comment Share on other sites More sharing options...
datiswous Posted November 23, 2021 Author Report Share Posted November 23, 2021 Is there some documentation to get certain things done, for example flickering light? I see bathroomtable[ time *.3 ] So I think time has something to do with it, but I don't see this reverenced in the wiki. blamplight_cv has this code in it: red ((.1 * sintable [.15 + (time * 12) ]) +.9) * Parm0 green ((.1 * sintable [.15 + (time * 12) ]) +.9) * Parm1 blue ((.1 * sintable [.15 + (time * 12) ]) +.9) * Parm2 I cannot find documentation on how this works Quote Link to comment Share on other sites More sharing options...
HMart Posted November 23, 2021 Report Share Posted November 23, 2021 Tables is what's used to drive flickering lights, In my fast search I didn't find a explanation about them in the TDM wiki (doesn't mean there's none) but here are some links that explain, what they are and more or less what they do. This links are obviously not directed at TDM, so have in mind that some things may work differently or not at all now. But personally I still think they are useful for TDM editing at lest as a hint or pointer. https://modwiki.dhewm3.org/Table_(decl) https://iddevnet.dhewm3.org/doom3/materials.html 1 Quote Link to comment Share on other sites More sharing options...
OrbWeaver Posted November 23, 2021 Report Share Posted November 23, 2021 This looks like the relevant documentation from iddevnet: Quote Notice the use of a lookup table in this material. Here we are using 'time' (which is a floating point number that increases forever) to look up a value in 'scTable' (which was defined using a 'table' decl earlier). The mathematical operators you can use in a material are %, /, *, -, and +. You can also use the boolean operators <, >, <=, >=, ==, !=, &&, and ||. The meaning of the symbols is the same as in C/C++, Java, PHP, etc. Mathematical expressions should be enclosed in parenthesis (there are cases where they don't have to be, such as when they are used as an index to a lookup table, but it never hurts to have too many. For the operands, you can use a lookup table, any numerical constant, and any of the following variables: time: Forever increasing floating point value that returns the current time in seconds parm0-parm11: Parameters that can be set a number of ways (discussed above) global0-global7: Not used right now fragmentPrograms: Constant that is 1 if ARB fragment programs are available. This is mostly used for disabling a stage by specifying "if ( fragmentPrograms == 1 )" sound: The current sound amplitude of the entity using this material. This is used to create light materials that pulse with the sound. So time is just the current game time in seconds, and using this to lookup into a table of values (using wrap-around indexing obviously, so the table gets "played" again and again as time increases) gives you a brightness which can flicker, pulse or do whatever is defined in the lookup table. The blamplight_cv material is doing this independently for each channel (hence the separate red, green and blue declarations), so that it can multiply in the parameters which contain the red/green/blue channel of the _color spawnarg. This is what allows it to be colour-variable while still using the sintable (which I assume contains a sine wave) to animate the brightness. 1 Quote DarkRadiant homepage ⋄ DarkRadiant user guide ⋄ OrbWeaver's Dark Ambients ⋄ Blender export scripts Link to comment Share on other sites More sharing options...
datiswous Posted November 23, 2021 Author Report Share Posted November 23, 2021 (edited) I tried to make my own light table: table testWtable { { 0,0,.1,.2,.3,.4,.5,.6,1,1,1,1,1,1,2,2,3,3,3,3,3,2,2,1,1,.8,.5,0,0,0,0,0,0,0,0,0,0,0,0,0,.2,.5,.2 } } With a custom shader: lights/blamplight2_W { { forceHighQuality //map makeintensity( lights/blamplight2.tga ) map lights/blamplight_cv.tga colored //rgb bathroomtable[ time ] red testWtable[ time *.5 ] * Parm0 green testWtable[ time *.3 ] * Parm1 blue testWtable[ time *.2 ] * Parm2 zeroClamp } } Where every color changes at a different speed. It's also switchable off course. Creating this effect: https://drive.google.com/file/d/12VvDEDNsIyh8UUjEsEndW0xdsthSfxgK/view Edited November 23, 2021 by datiswous Quote Link to comment Share on other sites More sharing options...
OrbWeaver Posted November 24, 2021 Report Share Posted November 24, 2021 I guess that will be useful if you want to simulate a disco. I think you can safely get rid of the colored declaration, since I don't think it's doing anything if you set the RGB channels explicitly (I could be wrong though). Quote DarkRadiant homepage ⋄ DarkRadiant user guide ⋄ OrbWeaver's Dark Ambients ⋄ Blender export scripts Link to comment Share on other sites More sharing options...
datiswous Posted November 24, 2021 Author Report Share Posted November 24, 2021 (edited) Yeah, I think I tested without and it didn't do anything. I still don't understand what Clamp means though (and therefore zeroClamp), the explanation for Clamp on https://iddevnet.dhewm3.org/doom3/materials.html is as follows: Quote [clamp] is an optional key word which means "don't wrap around if the index is outside the range of table elements, (return the first value if less or the last value if it's more)" In section Global Keywords for regular materials: Quote clamp: Don't repeat the texture for texture coords outside [0, 1] zeroclamp: guarantee 0,0,0,255 edge for projected textures Edited November 24, 2021 by datiswous Quote Link to comment Share on other sites More sharing options...
OrbWeaver Posted November 24, 2021 Report Share Posted November 24, 2021 clamp does not appear anywhere in this light shader as far as I can see, so is not relevant here. If it did appear, its meaning would depend on whether it is a global material keyword or appears within the table declaration, as I believe the iddevnet documentation makes clear. zeroClamp means "guarantee 0,0,0,255 edge for projected textures" i.e. black with full alpha outside the texture boundaries. I assume this is needed to stop light textures from extending outside the light volume during rendering (if there was no clamping, the GPU might default to repeating the texture or extending the edge pixels indefinitely outwards). This might be something which has changed since the original Doom 3 implementation, since I recall some recent discussions about the clamping behaviour of projected light volumes. 1 Quote DarkRadiant homepage ⋄ DarkRadiant user guide ⋄ OrbWeaver's Dark Ambients ⋄ Blender export scripts Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.