Jump to content
The Dark Mod Forums

Figuring out complex light entities


Springheel

Recommended Posts

I'm trying to sort out the lights that flicker in sequence with a sound and I'm having trouble figuring out the math.

 

First of all, from the id site:

 

sound: The current sound amplitude of the entity using this material. This is used to create light materials that pulse with the sound.

 

What is the numerical range of "sound amplitude" and how can I find out what the amplitude of a particular sound is?

 

Second, the math in the light material shader looks like this:

 

red Parm0 / (sound*sound)

green Parm1 / (sound*sound)

blue Parm2 / (sound*sound)

 

Red, blue and green values are supposed to be from 0..1, I believe. How do I find what the value of Parm0, (etc) is?

 

Without knowing these values it's hard to troubleshoot why the lights are ridiculously bright.

Link to comment
Share on other sites

http://wiki.thedarkmod.com/index.php?title=List_of_shaderParm_variables

 

those should be relative to the "_color" spawarg applied to the entity. If that hasn't been specified or isn't being

respected that might be the problem.

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

Ok, the colour values for one of the problem lights is:

 

0.80

0.50

0.20

 

So could the problem be that the (sound*sound) is resulting in a value less than 1? That would cause parm0 to be higher than 1, which might cause the blinding whiteness ( see image).

post-9-0-91253800-1367356489_thumb.jpg

Link to comment
Share on other sites

If the "sound" arg is like other sounds, and amplitude is referring to the change in volume over some cycle, then volume is often in decibels with the scale -60 ... 0 (0 being native volume, -60 silence, each 10 dec's being another 1/2 volume: so -10 is half volume, -20 1/4 volume, etc. It's a log scale. And any positive number is over-maxing.) I think that's how it was.

 

That may explain, if there's a multiple of that "sound" factor & it's a positive number in that decibel/negative system, the lights are crazy bright (because you're putting a factor that's a crazy loud volume). It's the same reason, incidentally, that my first version of the ambient sound system had ludicrously loud ambients, because any positive value is over-maxing the native volume. 10 would be double the volume. Edit: Even a number 0..1, like 0.5, would be above the native full volume.

What do you see when you turn out the light? I can't tell you but I know that it's mine.

Link to comment
Share on other sites

If the sound is like other sounds, and amplitude is referring to the change in volume over some cycle, then volume is often in decibels with the scale -60 ... 0 (0 being native volume, -60 silence, each 10 dec's being another 1/2 volume: so -10 is half volume, -20 1/4 volume, etc. It's a log scale. And any positive number is over-maxing.) I think that's how it was.

 

Can you dumb that down for me? If "sound" = "current sound amplitude", can I find out that value from examining the relevant sound file?

Link to comment
Share on other sites

AFAICT, "sound" gets a value between 0 and 1, depending on the current amplitude of the sound. The code isn't easy to understand.

 

If the current amplitude is "0", that sets up a "divide by zero" situation, so I don't understand why the math is dividing by "sound squared". I would have thought a simple

 

red Parm0*sound

green Parm1*sound

blue Parm2*sound

 

would provide the desired effect.

Link to comment
Share on other sites

Can you dumb that down for me? If "sound" = "current sound amplitude", can I find out that value from examining the relevant sound file?

 

Well one problem is from my quick reading I'm not really sure what "sound" is or where it's coming from. Is that an argument you're setting or the system is giving you? Also, I mean, I don't know if it's an absolute argument (in reference to the native volume of the file) or a relative argument (in reference to the volume currently in play).

 

But, in any event, I think I can boil my hypothesis into a quick test. Try a negative value for the "sound" argument like -10. If the volume & brightness appear 1/2 normal, like you'd expect if what I said is right, then that's support that "sound" argument should be a negative decibel value, -60..0 on a log scale. If the result is nonsense, then what I'm thinking about is just a completely different issue so forget about it anyway. That's just my intuition speaking.

 

Edit: But to actually answer your question, if what I'm thinking about is right, then yes, you can theoretically tell the value by examining the relevant sound file, because the native volume would be a value "0" for the argument, a softer volume would be a negative value, a louder volume would be a positive value. This is only if it's working like "volume" argument does for speakers, which I don't know.

 

Edit2: Sorry, I wasn't paying attention well enough. Obviously -10^2 is positive, and you never want to divide by zero. So I think I'll just bow out & admit I don't know what's going on and what I said may just be totally off. Intuitively, a bigger number downstairs in the fraction will give you a smaller total value and thus dim the light more like one would expect. So that might point you in the general direction you want to go.

 

Edit3. Well, last ditch effort with my hypothesis, maybe sound^2 is supposed to be 1..3600, i.e., -60..0 squared & +/- flipped?? If it seems parm/3600 would give you blackness, parm/100 half brightness, and parm/1 would give you the brightest light?

What do you see when you turn out the light? I can't tell you but I know that it's mine.

Link to comment
Share on other sites

AFAICT, "sound" gets a value between 0 and 1, depending on the current amplitude of the sound. The code isn't easy to understand.

 

If the current amplitude is "0", that sets up a "divide by zero" situation, so I don't understand why the math is dividing by "sound squared". I would have thought a simple

 

red Parm0*sound

green Parm1*sound

blue Parm2*sound

 

would provide the desired effect.

biground1_parmsndflicker is actually using this math. Same goes for biground1_snd. Some others are using a time dependent sinus function (so independently from sound). Maybe the formula is just a typo.

 

EDIT: @Springheel: What light shader are you actually referring to?

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

If the current amplitude is "0", that sets up a "divide by zero" situation, so I don't understand why the math is dividing by "sound squared".

 

I think Tels set that up. I found a comment :

 

 

 

// tels: 2010-01-24 (small_snd because it has 0.x * (sound*sound) vs. (sound*sound), to reduce the amount of flicker

and that comment came right before a shader with this math:

 

red Parm0 / (0.2 * (sound*2))

green Parm1 / (0.2 * (sound*2))

blue Parm2 / (0.2 * (sound*2))

 

What I read from that is that the sound*sound one is supposed to result in greater flicker.

 

EDIT: @Springheel: What light shader are you actually referring to?

 

This one:

 

lights/biground1_streetlamp_4fold_snd

{

{

forceHighQuality

map textures/lights/biground1_streetlamp_4fold

red Parm0 / (sound*sound)

green Parm1 / (sound*sound)

blue Parm2 / (sound*sound)

zeroClamp

}

}

Link to comment
Share on other sites

I looked through the original D3 light shaders that use the "sound" keyword, and none of them divide the color value by the value of "sound", let alone divide it by the square of the value of "sound".

 

So this is something introduced by someone in TDM.

 

All the D3 light shaders that use "sound" are of the form

 

red Parm0*sound

 

This reinforces my contention that "sound" ranges from 0.0 to 1.0, because nothing else makes sense, since the resulting value for "red", etc. has to range from 0.0 to 1.0.

Link to comment
Share on other sites

Try this: Make the amplitude of the replacement light sound (light_flicker01.wav) match the amplitude of the original light sound (light_flicker104.ogg). The original has an average amplitude of 0.7, and the replacement has an average amplitude of 0.1. With smaller values for "sound" in those equations, the colors are going to be brighter.

 

See if that fixes the problem.

 

If the replacement sound is now too loud for the player, bump its volume down in the sound shader.

Link to comment
Share on other sites

I don't see if you send me PMs (possible email notification is disabled?) and stumbled over this thread by accident via the web. So, if you have any questions and don't see me looged in, please email me. (Ialso don't see a PM, either, so maybe thats another problem).

 

Anyway, to the light:

 

I'm certain I did not setup the formula, only modify it. Generally these are all id's formulas. The formular in question seems to be tweaked for each light "sound file" by using of constant factors. For instance, for some low hums, a factor of 2 is used to make the flicker brighter, for high hum sounds sometimes 0.2 is used to make the flicker less bright.

 

In general, we want to have the light to have a base color + some flickering. So, if you have a sound file which has the same loudness (which goes btw from 0.. 1.0), then you can use a constant factor to make the flicker look "just right". Unfortunately, if you swap the audio file, you need to adjust the formula.

 

There is another way to achive that, by using a constant part from parm0, parm1, parm2. I'll explain this in a minute.

 

First some basics: parm0, parm1, parm2 are the current light color of the light in RGB from 0..1. sound is a virtual variable containing the current (in time) sound volume between 0 and 1.

 

There are two variants of flickers:

 

Multiplicative, this makes the light get brighter as louder the sound gets:

 

red parm0 * sound

 

Divide, this makes the light get dimmer as louder the sound gets:

 

red parm0 / sound

 

I think the engine avoids dividing by zero, but I'm not sure. In general, you want a sound file with some constant humming, not one that goes from "23 seconds of silence to a sharp hiss", tho.

 

Anyway this

 

red parm0 / (sound * sound)

 

Makes the light dim very strongly the louder the sound is. (quadratic)

 

Again, in all cases the dimmig can be adjusted by changing the audio file (cumbersome), or by a constant factor in the shader that is multiplied with "sound":

 

red parm0 / (0.2 * sound * sound)

OR

red parm0 * 0.2 * sound

 

Another way to adjust the flickering part is by making part of "parm0" (the color) constant and vary only one part of it by the sound:

 

 

red parm0 * 0.5 + parm0 * 0.5 / (sound * sound)		  // louder => dim light

OR

red parm0 * 0.5 + parm0* 0.5 * sound				   // louder => bright light

 

The first formula can never go higher than 1 (it is basically 0.5 + (0.5 ... 0 depending on sound), while the second formula can ge very bright (it varies from 0.5 .. 1.0 or even higher but I think the value is clamped at 1.0)

 

In both cases, the actual formula must probably be adapted to the sound used by the light.

 

 

In all cases, the color of red, green and blue can be adjusted individually, I don't think we used it, but you could make a light that only (or more) flickers in the red and blue parts than in the green.

 

Hope that clears the basic facts?

 

As for the overly bright light, either adjusting the sound, or the light formular or the actual ligth color will "fix" this issue. I think fixing the formula is easiest and best. The sound might be used elsewhere, and mucking with the light colors means the mapper has to remember that some lights use completely different colors than others, which isn't good.

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

Just one more thing: Making the light dim when the sound is loudest or making it more bright depends on what the "humm" is supposed to be in elektrical terms. Should it represent some machinery that draws power the louder is is? Or some sort of defect that injects power (or a generator) the louder it is?

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

Regarding dimming the light if the sound gets louder, I would suggest the following

red parm0*(1-sound)

This behaves exactly opposite to

red parm0*sound

and there is no possibility that you divide by zero or exceed the range of [0,1].

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

Hi, Tels! Thanks for the good explanation.

 

I checked D3's definitions last night and they're all of the form "color ParmN*sound" (or some other multiplicative expression using 'sound').

 

None of them divide by 'sound', so expressions that do that were added by some TDM person, probably early in development.

 

I agree with Tels' suggestion that it's easier to tweak the expressions than to tweak the sound amplitude.

 

I also agree that Obsttorte's (1-sound) suggestion makes sense, and avoids the wild swings that can be caused by division.

 

So it looks to me like this comes down to changing the expressions until the light has some flicker and doesn't get too bright.

Link to comment
Share on other sites

For a quick and dirty solution, since the new sound's average amplitude is 1/7th that of the original sound, perhaps this would suffice:

 

red Parm0 / (( 7*sound) * ( 7*sound))

 

green Parm1 / (( 7*sound) * ( 7*sound))

 

blue Parm2 / (( 7*sound) * ( 7*sound))

 

Edit: Yes, that looks fine. Tested the City Watch light in BF.

Link to comment
Share on other sites

Ok great, thanks everyone for the help. I'll start going through them and adjusting the math until it looks right.

Link to comment
Share on other sites

FWIIW, I agree with all of what grayman said, Obsttorte's suggestion sounds more sensible, and tweaker the formula is the most easiest way. Hopefully, we always use the same formula with the same sound file, otherwise one light might get fixed and another one broken.

 

 

It's a bit ugly, but better do a quick fix and worry about creating a better system later if we ever need it.

 

Btw, the one could also use

 

blue Parm2 / (49*sound * sound)   // make it 1/7 as bright due to a new sound file

 

Probably doesn't matter, because the constant might be pre-computed, but then, I'm not sure if "7*7*1*1*1*1" wouldn't compute more stuff in the shader than a simple "49". If the code is just literally transformed into shader code without such optimizations, this might make things render a very tiny bit slower w/o benefits.

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

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.
      · 0 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...