Jump to content
The Dark Mod Forums

[SOLVED] Light type blamplight not switchable


datiswous

Recommended Posts

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 by datiswous
solved
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by datiswous
Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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).

  • Like 1
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

  • Thanks 1
Link to comment
Share on other sites

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.

  • Thanks 1
Link to comment
Share on other sites

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 by datiswous
Link to comment
Share on other sites

  • datiswous changed the title to [SOLVED] Light type blamplight not switchable

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).

Link to comment
Share on other sites

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 by datiswous
Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recent Status Updates

    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 4 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
    • OrbWeaver

      I like the new frob highlight but it would nice if it was less "flickery" while moving over objects (especially barred metal doors).
      · 4 replies
    • nbohr1more

      Please vote in the 15th Anniversary Contest Theme Poll
       
      · 0 replies
×
×
  • Create New...