Colored flame lights

[MirceaKitsune]

Following the release of my first FM I wanted to offer a little surprise to the TDM community. I've implemented a little feature I wished to have for a while: Colored flame lights! This covers all fire based light entities, meaning all torches and gas lamps get versions with colored flames. They work the same way as the normal flames in terms of functionality, meaning you can move candles around and water arrows put them out and the player can relight them with matches. Colors include: Red, green, blue, pink.

The implementation is very flexible: Each color variation inherits its original entity and only changes the light color or particle definition, thus changes to the base def will automatically reflect to the colored versions during development modifications. The colored entities replicate the same DarkRadiant tree structure as the normal lights directory except in their own subdirectories.

I'm eager to hear what you think and if you like them! My goal is to offer this submission for vanilla TDM, ideally as a new feature for 2.09... I think they would look very nice for many fantasy setups! And of course, here are some screenshots of how each color looks in-game (red, green, blue, pink):

Spoiler

Spoiler

Spoiler

Spoiler

The pk4 is attached to this post as it includes only particle and entity definitions so it's ridiculously tiny. You can install it in one of two ways: Either unpack its contents inside the directory of your fm, or copy the file as is inside the darkmod folder next to all the other pk4's... both should work just fine.

color_lights_1.0.pk4

Edited November 7, 2020 by MirceaKitsune

[MirceaKitsune]

Updated to use better naming and editor folder paths.

color_lights_1.1.pk4

[Obsttorte]

You can make the particles use the light color. This way you wouldn't need to have specific entities for each color.

 

Btw.: You may want to start a mapping thread to bundle your ideas instead of creating a new one for everything?!

[MirceaKitsune]

7 hours ago, Obsttorte said:

You can make the particles use the light color. This way you wouldn't need to have specific entities for each color.

 

Btw.: You may want to start a mapping thread to bundle your ideas instead of creating a new one for everything?!

Nice, I didn't know you could do that. Perhaps I could use it to have a single colorable version of each flame type? How do you do this though, as in allow the color of a particle to be specified from the light def rather than coded in the prt file?

I ask most questions in Newbie DarkRadiant Questions. Usually I only start a new thread if it's an idea that warrants its own discussion or something I produced.

[MirceaKitsune]

New update. I didn't quite like how the pink flame looked, too unrealistic and illogical for a fire. I thus converted it to a purple flame which I feel looks a lot nicer! Violet flames are common in magic too so it's a better choice for this reason as well.

Spoiler

 

color_lights_1.2.pk4

Edited November 7, 2020 by MirceaKitsune

[Dragofer]

1 hour ago, MirceaKitsune said:

Nice, I didn't know you could do that. Perhaps I could use it to have a single colorable version of each flame type? How do you do this though, as in allow the color of a particle to be specified from the light def rather than coded in the prt file?

You'd need to:

- make black&white versions of the flame diffusemaps so they can be recoloured better
- use the "colored" keyword in their material definitions, see existing colorme textures for examples
- enable "use entity colour" in the particle editor
- this gives you a recolourable flame entity. Since it's def_attached to a lamp fixture, you need to use the spawnarg "set _color on flame" on the fixture to change the colour.

More initial work this way than cloning existing entities with different fixed colours, but you'd get a much more versatile entity and the entity list would remain more navigable.

[Obsttorte]

@MirceaKitsuneLike @Dragofersaid. If lights can have models (can't remember right now as it has been a while) and you use the particle as model, you may even be able to skip the "set _color on flame" part (note that there is a space after set).

[MirceaKitsune]

I don't plan on editing the default flames, that might mess up what was done in development. That also sounds a bit more complicated... I'd have to rewrite the particle definitions as well as re-texture the flame images to use color maps. And since the red tint of the texture applied on top of the particle color looks nice, I would rather leave it as is for now. It's good to know this is a possibility in general none the less!

[Geep]

I've just expanded the "_color" wiki page, to include how to change the brightness or color of the light cast by flame lights, and a link to this thread as well.

[MirceaKitsune]

9 hours ago, Geep said:

I've just expanded the "_color" wiki page, to include how to change the brightness or color of the light cast by flame lights, and a link to this thread as well.

Do you mean the light source or the flame particles? The first is super easy... main problem is colorizing the particles themselves, I didn't know how to do that. Once I do I'll make what should be the final update to this, so I can define a single set of particle defs instead of one for each color variant.

In the prt. sub-particle definition (the entries between {}'s nested inside that particle def's {}'s) uses the flag "color R G B". What do you use there so it inherits the color of the light source? Would it be something like "color _color" or just "colored" or a similar format?

[Geep]

I only dealt with the "super super easy" part of using the entity's "set _color to flame" to override the default color. I needed to do that in my current FM WIP to make the cast light dimmer. Sorry, I'm clueless regarding anything to do with particles, such as colorizing them.

[HMart]

Afaik particles are just like any model, you use a material to give them their look, so most material tricks should work on them, have you tried to use a material, with a material stage keyword "colored"? It should give you the ability to color them in DR, you do this, like i said by just giving the particle, a material with a stage using the keyword "colored" then in DR you just use keyword parm0 to parm3 (R G B A respectively) to change its color. 

Btw don't know if really necessary but the Doom3 materials I saw using this, add a black&white diffuse texture.

 

Example from Doom 3

models/mapobjects/chairs/kitchenchair/kitchenchair
{
	qer_editorimage models/mapobjects/chairs/kitchenchair/kitchenchair
	bumpmap			models/mapobjects/chairs/kitchenchair/kitchenchair_local
	{
		blend		diffusemap		
		map			models/mapobjects/chairs/kitchenchair/kitchenchair_d
		colored
	}
	{
		blend		specularmap		
		map			models/mapobjects/chairs/kitchenchair/kitchenchair_d
		rgb			parm3 * 0.4
	}
}

 

[MirceaKitsune]

Got them working! Now the entity's "_color" parameter automatically colors the flames as well. I had to redefine all the flame materials but the new mtr is a single set so it's no issue. Please try out the update and see if everything's good.

There's only one problem: I have to comment out the "vertexColor" parameter in order for the "colored" one to work. This seems to cause the particles to appear and disappear suddenly (no fading). Not sure what solution there is to this side effect.

color_lights_1.3.pk4

 

[MirceaKitsune]

I tried using "vertexColor parm3 * 0.4" as suggested by nbohr1more. No idea why that post isn't appearing here any more, I could only see it from an email notification. Sadly it only causes the particles to turn into black boxes without solving the fading issue.

 

[nbohr1more]

Hmm...

I remember this problem from before. I believe the "scale" image program was the workaround:

 

blend diffusemap

map scale (models/mapobjects/chairs/kitchenchair/kitchenchair_d, parm0, parm1, parm2, parm3)

colored

 

parm0 = red

parm1 = green

parm2 = blue

parm3 = alpha

 

https://www.iddevnet.com/doom3/materials.html

[MirceaKitsune]

42 minutes ago, nbohr1more said:

Hmm...

I remember this problem from before. I believe the "scale" image program was the workaround:

 

blend diffusemap

map scale (models/mapobjects/chairs/kitchenchair/kitchenchair_d, parm0, parm1, parm2, parm3)

colored

 

parm0 = red

parm1 = green

parm2 = blue

parm3 = alpha

 

https://www.iddevnet.com/doom3/materials.html

map scale (the_texture, parm0, parm1, parm2, parm3): Causes the flames to become completely invisible.

map scale (the_texture, 1, 1, 1, parm3): No change from not using it at all, you still see the flames popping out of existence instead of fading away.

Apparently the engine really wants me to use vertexColor, which I cannot as it overrides the colored parameter and causes colorization to stop working. It take it vertex colors are somehow used to tell the particles when to fade... I'd need to somehow set only the alpha channel from it but leave the RGB set by the entity.

[MirceaKitsune]

It's been a while since I received any feedback on this feature. As it's an addition created with the hope of being included in TDM by default, I'd like to ask if a look can be taken at this pk4 again please, and let me know if and how anything can and should be changed.

I remember that last time, we almost got everything working as intended. A final remaining issue had to do with alpha fading not working properly as the particles were colorized via common definition, due to vertex colors interfering in some form. Has this been fixed in the engine, or are there changes I can and should do to work around it?

[Dragofer]

We've just talked about adding these coloured lights: we'd probably add a set of colorme lights that allow the mapper to easily set their desired hue, saturation and intensity.

For one, this is because it became clear everyone has their own opinion of what these settings should be. For the other, this minimises the number of entity duplications in the Lights folder compared to having multiple preset colours for each light.

Kingsal offered to pick up this .pk4 and look into making it become core-ready in accordance with these specifications.

Btw, is it intentional you've also recoloured the deprecated entities? Those should probably not be shown anymore in DR by default.

[kingsal]

Having colored lights is a great idea! As Dragofer mentioned we are looking into ways to make this as customizable as possible. 

I've made some progress  and have colorable candles, torches, ect that will pass their color to their particle effects.  I'm going to look into some other stuff and then I'll post up what I have.

[MirceaKitsune]

I agree: Making them as customizable as possible is ideal, as well as using as few definitions as we can along the way. I believe last time I de-hardcoded the color from the particles and made common particle definitions. To create colorme versions anyone can colorize with a spawnarg would be perfect!

Yet I can already see one problem with that; Let's say you have a candle holder, which attaches a candle, which attaches its flame light entity. The candle holder is the entity you place on the map. How do I configure its def so it passes its "_color" spawnarg to the candle, which in turn passes it to the light? The last version works because I still colorize the flame entity only then tell each candle which one to attach... I'm not aware of a way to propagate the color along a chain of attachments instead. Any thoughts?

[kingsal]

1 hour ago, MirceaKitsune said:

I believe last time I de-hardcoded the color from the particles and made common particle definitions.

The color is not hard coded into the particles, it comes from the texture map which then gets "tinted" by the entityColor argument in the .prt. So we need to create grayscale maps for all the associated particles, which I've already done. This method doesn't require explicit color defs like you have (red, green, blue, pink).
 

1 hour ago, MirceaKitsune said:

I'm not aware of a way to propagate the color along a chain of attachments instead. Any thoughts?

Yeah so this is done with a "set _color on flame" "1.0 1.0 1.0" Basically telling attached object named "flame" to have _color set to 1 1 1.

Dragofer and I are  looking into a  method using the script object for light holders to colorize the FX and  even model skins. This way *any* light object with an associated flame can be colored as well as the models glowy bits. Glowing candle wax or fire embers for instance

[MirceaKitsune]

On 8/1/2021 at 6:39 AM, kingsal said:

Dragofer and I are  looking into a  method using the script object for light holders to colorize the FX and  even model skins. This way *any* light object with an associated flame can be colored as well as the models glowy bits. Glowing candle wax or fire embers for instance
 

Yes, I played with particles a bit and noticed this: If you give a particle paragraph the parameter "entityColor 1" it will ignore the default color and colorize based on the _color spawnarg. That's obviously what we want to use in this case.

The limitation is that particles are produced by the flame entity, thus this ent must take care of coloring them. TDM defs are configured so a candleholder entity spawns and attaches a candle entity, which in turn spawns and attaches the light entity: The entity at the base of the chain is placed on the map thus it must send its color setting to the top ent. So I'll need to wait on the change you mentioned... great idea BTW, thank you and @Dragofer for working on it!

And you know... I have to wonder: Should my pk4 really be needed any more in that case? Once the change you mentioned is ready, setting the color on a torch will automatically colorize its light, correct? Only other thing needed to allow colored flames is letting the default flame particles be colorized as well! If that extra change is acceptable, we should simply let all existing flame and gas lights be colored by default, just as electrical ones can be already, no need to bloat the defs with extra _colorme versions! Obviously their existing looks shouldn't change, all candles and torches should look the same as now by default... just that once you add the _color spawnarg to them in your map, both the light color and flame particles know to use that instead. Now that's an exciting thought, would be so convenient and encouraging for mappers to use then

[Dragofer]

11 hours ago, MirceaKitsune said:

Once the change you mentioned is ready, setting the color on a torch will automatically colorize its light, correct?

Indeed, this new segment in ::init of the tdm_light_holder scriptobject applies the _color of the parent entity to everything bound to it, if the spawnarg "propagate_color" is set to "1":

    if ( getKey("propagate_color") == "1" )
    {
        vector col = getVectorKey("_color");
    
        for (ind = 0; ind < numBindChildren(); ind++)
        {
            child = getBindChild(ind);
            if( child )
            {
                child.setColor(col_x, col_y, col_z);
                child.setKey("_color",col);
            }
        }
    }

I would only apply this script to new entities with the propagate_color spawnarg, and only make the new entities recolourable, for a number of reasons:

1. There are bound to be a lot of light holders across TDM's missions that have leftover _color spawnargs from when the mapper was trying to work out how to recolour the def_attached lights. If this starts to take effect, it may unpredictably change how those missions look or play.
2. The _color spawnarg isn't fully as realistic as having a pre-coloured particle image, in part because of the additive effect. You can see here how at default particle settings, this blue-coloured flame is incredibly bright. Recolourable particles will therefore need fewer than the default 12 cards to still look reasonably realistic. From a visual perspective it'd be ideal if we had one duplication of our light entities per pre-set colour, but this would be extremely cluttered. I think we can justify 2 sets of entities: standard flames and recolourable flames.

Generally we're quite stringent about avoiding changes to existing assets that could alter or break released missions, preferring to create new entities. Being able to recolour any standard light with a single spawnarg would be great, rather than using a separate set of entities, but it'd have far-reaching effects for TDM's missions.

[MirceaKitsune]

I see your point. Only part I may disagree on is that someone forgetting the _color spawnarg on a torch should keep us from properly implementing this: Did anyone even do that in existing FM's, and if they did would it count as breakage to assume it was intended and just let it work all of a sudden? Would like more opinions on that.

But even so we have another option: You clarified the new functionality requires setting the additional spawnarg "propagate_color". What if we simply don't enable that on the default light entities but configure them so they're compatible with it? That way, in order to colorize a torch or candle, you need to set both the propagate_color and _color spawnargs... if you set the two of them though they would work without requiring additional defs and it wouldn't risk changing existing FM's either.

As for brightness, isn't it possible to adjust it from the color? So if you want a blue light that's as bright as possible that's "_color 0 0.5 1" but if you want half the brightness you can set that to "_color 0 0.25 0.5" instead. I love the appearance in that screenshot still, that feels very right and pleasant to me!

Edited August 5, 2021 by MirceaKitsune

[Dragofer]

1 hour ago, MirceaKitsune said:

Only part I may disagree on is that someone forgetting the _color spawnarg on a torch should keep us from properly implementing this:

It's basically the policy of the team with regards to making changes to assets used in existing missions. You may argue that the likelihood of a negative effect may not be too high or too severe, but if one adopts this approach, then over the years the integrity of released missions would gradually degrade. In this case you'd have areas that may not be lit like the author intended since he never had a chance to look at what the lights are like with the _color spawnargs in action, which has visual + gameplay consequences. In the worst case the colours may be completely wrong.

1 hour ago, MirceaKitsune said:

As for brightness, isn't it possible to adjust it from the color? So if you want a blue light that's as bright as possible that's "_color 0 0.5 1" but if you want half the brightness you can set that to "_color 0 0.25 0.5" instead. I love the appearance in that screenshot still, that feels very right and pleasant to me!

Yes, but if you want to use 1 spawnarg for both the flame and the light, then the light would become too dim. Colourable particles need to be calibrated so that they look right at a normal light intensity.

1 hour ago, MirceaKitsune said:

What if we simply don't enable that on the default light entities but configure them so they're compatible with it?

The problem is that a light fixture consists not just of the entity defs, but also materials, models, particles and skins. Changing them, i.e. by making particle and glow maps black & white, has a high chance of breaking custom light fixtures that relied on the original version of some of those assets, i.e. by causing them to appear bright white because the mapper didn't foresee a need to apply a matching _color spawnarg. This can be avoided by creating separate versions of those assets.