[Mod]Smoke [WIP]

[Astrobe]

Full node smoke that moves preferably upwards. The smoke is toxic in addition to not breathable. The sources of smoke are furnaces, flames and lava.

Git repo
Download (rename the folder to just "smoke")

As usual, this is a WIP so don't use that on a live map. Bugs in this mod, due to its nature, may result in your world being filled with a toxic gas.

It would be surprising that nobody thought about this before, so this is either not a very good idea or not viable for servers; indeed in case of a large forest fire I guess the extra load is significant.


You need chimneys now


Remains of a bone fire

I spare you the screenshot of a jungle forest in fire because it is uncomfortably realistic; if the fire doesn't kill the fauna, the smoke most likely will.

[texmex]

What a great concept! I'd like to see it developed further. I've long awaited a way of being forced to handle smoke and pollution.

Ideas:
- Don't let smoke escape to an diagonally available space if otherwise locked in
- Lightly animate the smoke node
- Create a smoke type that spreads much more horizontally, only going upwards as a last resort
- Create support for pipes, look for a group name called chimney or similar
- Find a way to get rid of the ABM

[Astrobe]

- Don't let smoke escape to an diagonally available space if otherwise locked in
- Create a smoke type that spreads much more horizontally, only going upwards as a last resort

I noticed the issue - it is not deliberate, it's just how find_node_near() works. I didn't think too much about it since I tend to build square things. Fixing it would require to abandon that fast engine function for a manual six-neighbor-nodes check. I am a little worried about the perfs, but it would make your second suggestion trivial to do - it would be a different mod, though.

I'll experiment with lava lakes with this change to see how it goes.

- Lightly animate the smoke node

I was diagnosed with a genetic inability for graphics artwork, so someone will have to feed me textures.

However, I am also worried about performance here; during tests I heard the fan of my graphics card speed up a bit for big fires (although fire nodes themselves do that too). I didn't notice framerate drops, but I'm thinking about mobile devices that have less graphic horsepower.

I would like to experiment with tiling textures. But then again my graphics disability...

- Create support for pipes, look for a group name called chimney or similar
- Find a way to get rid of the ABM

For those horrified by the three letters this is just for the smoke sources, the smoke nodes themselves use proper node timers.

I don't like it either but getting rid of it would require invasive hacks in the source nodes (or clumsy and unhygienic overrides). A smoke-aware mod could create a smoke node where and when it sees fit, the Smoke mod would do the rest. Maybe I can add a thin API to isolate other mods from future changes.

Direct support for pipes is beyond the scope of the mod; the pipe or whatever consuming node might have different status (e.g. there might be a valve somewhere) that I don't want to know about. A smoke-aware mod could remove itself smoke nodes when it sees them, but here too a thin API is something I can do.

[texmex]

I think find_node_near can be replaced with something faster since it’s fewer checks to do but maybe I’m wrong.

I might have time to look into a nice smoke animation, stay tuned.

I strongly suspect the ABM to be the source of your performance woes. If so, a lite node def injection hackyness is worth it imo. Compare to the unlagginess of oilbois fire in his alpha game.

I’ve long thought about ”rising” nodes, opposed to the falling ones. My usecase was for making buoyant nodes, but it’d fit this one too. Maybe smoke can use such a mechanism of switching between being represented by a node and an entity? The upside would be that it would travel quicker to it’s destination under a ceiling for example. Maybe too quick if using the same speed as the default falling nodes but maybe that speed can be decreased.

Also, try the glasslike drawtype as ”Only external sides of textures are visible.” it can help with forming a more unified smoke cloud, and also look better when/if it get animated textures.

[FreeGamers]

I really like this idea! It would be a nice addition for my survival server after, at least eventually. The concept of making smoke generate from fire sources is something I haven't realized the game lacked until now.

Could you use some sort of timer to generate and disperse smoke nodes over time? The vacuum mod has some nice vacuum nodes that suffocate players while they are in the vaccum of space.

I'll keep on eye on this project.

[Astrobe]

Could you use some sort of timer to generate and disperse smoke nodes over time? The vacuum mod has some nice vacuum nodes that suffocate players while they are in the vaccum of space.

The generation is currently done with an ABM in order to make it easy to add more sources (note for instance that I didn't include torches). The dispersion and dissipation of the smoke nodes themselves uses node timers only.

The smoke nodes have a damage_per_second value, so players will get damage if they enter them. If they insist on staying there, they also have the drowning property like water, so they'll suffocate too.

[Astrobe]

I think find_node_near can be replaced with something faster since it’s fewer checks to do but maybe I’m wrong.

My intuition was that find_node_near is a native function, so it had to be faster that Lua script (even with JIT).
But you were actually not incorrect. It is a matter of +15% CPU usage versus +20% CPU usage (near some lava lake) in favor of the find_node_near version, but the "manual" version also randomizes a bit the movements of the smoke (find_node_near always do the checks in the same order, so sometimes you see semi-trapped nodes oscillate between two positions, which is not really smok-y).

I strongly suspect the ABM to be the source of your performance woes. If so, a lite node def injection hackyness is worth it imo. Compare to the unlagginess of oilbois fire in his alpha game.

It's not really woes, more like worries.

The source ABM is innocent, the CPU activity mainly varies with the number of smoke nodes (timers only).

Anyway, I plan to split the mod into two: an API that moves the smoke and depends on nothing but default and a basic usage mod that will use ABMs for smoke sources. It will be up to whoever is interested in adding smoke sources (torches, for instance) to either add it to the basic mod's ABM (or this ABM could use a specific group) or to go the optimal route.

I’ve long thought about ”rising” nodes, opposed to the falling ones. My usecase was for making buoyant nodes, but it’d fit this one too.

Yes, I have noticed that smoke nodes did look like air bubbles in a way. Not surprising, Archimedes' force is at play in both cases. I think it is more or less a matter of changing "air" to "default:water_source", although there are six different liquid types in default (maybe use "group:liquid", but it would a bit more problematic in the next version).

Maybe smoke can use such a mechanism of switching between being represented by a node and an entity?

Falling nodes stabilize into normal nodes relatively quickly, this is not the case for smoke nodes. A wildfire would create hundreds of entities; I think it could set the PC itself on fire.

Also, try the glasslike drawtype as ”Only external sides of textures are visible.” it can help with forming a more unified smoke cloud, and also look better when/if it get animated textures.

Yes, thanks for pointing that out; also I have noticed a glitch happens when the smoke is next to another liquid node (something to do with backface culling). You really see it only if you disable "waving water".

[BuckarooBanzay]

Any chance you can put that on github/gitlab...?

[CalebJ]

Hmmm, I went for a vacation, got back, and had a discussion with somebody about the possibility of a smoke node ... and then I find this. :D

Good work, I'm excited about this mod's development.

[Yvanhoe]

You know, I'd love it if it interfaced with the hanglider to provide an uplift force where there is smoke.

[texmex]

You know, I'd love it if it interfaced with the hanglider to provide an uplift force where there is smoke.

Yeah, I think it’s just for hangglider to look for these nodes and add velocitt accordingly. Will maybe add a little lag to it though.

[Astrobe]

You know, I'd love it if it interfaced with the hanglider to provide an uplift force where there is smoke.

Yeah, I think it’s just for hangglider to look for these nodes and add velocitt accordingly. Will maybe add a little lag to it though.

I am a former flight simulation fan, I even did have glider mods for Flight Simulator, but I believe a smoke node is too small for that purpose; and generating tons of smoke nodes has a significant cost. For a singleplayer game it could be viable; for a server maybe with lot of nodes could work with a really slow update frequency...

That said, the drag could make up for the small nodes, and would sort of simulate the fact that you pull up in a thermal lift in order to slow down the glider while turning in order to stay in the thermal as long as possible. But probably more satisfying would be to give the hang glider mod a basic kinetic energy and wing lift simulation (I didn't follow its evolution, that may already be the case).

But I believe a more efficient method would be to cast a ray down (with the new raycast function) to see what is there. Combine with some perlin noise - you would slowly shift where you look on that noise map over time, like Snowdrift does. Integration with a Paramat's Snowdrift (weather simulation) would be nice too (perhaps steal one of its perlin noise maps). With that ray cast one could also try to look at the nearby nodes to calculate the local slope (alternatively I believe one can get a height map for the terrain) and have ridge lifts too.

[Astrobe]

I was puzzled how fast the average smoke column height was dropping with the PERSIST parameter. As Minetest is sometimes used as a teaching tool, it would be an interesting chance to teach probabilities.

In the next version, I switched that parameter to a decimal value; for instance 0.8 means that a smoke node has 80% chances to move up and 20% chances to disappear.

The question is, if you have a single source of smoke under the sky, what is the average height of the smoke column? Obviously it depends on this "persist" (let's call it P) parameter.

I naively believed that it must be P/2 because that's the average of a uniform probability law. But this doesn't match the observations, because when you use P=0.8 the smoke hardly goes up 5 nodes.

What actually happens is that on the first step, the smoke has 0.2 chance to disappear and 0.8 chance to go up. On the second step, if the smoke has not disappeared, its chance to go again one node up is 0.8.

So the chance to see a node at height 3 is 0.8 chance that it went up on the first step times 0.8 chance that it went up on the second step. 0.8x0.8=0.64. More generally, the chance to see smoke at height N is P power N (P^N),

WIth this formula, the smaller P is, the faster P^N falls toward 0. If we consider the average half-size of the column (it's easier to consider the half-size because P^N cannot become 0 except because of rounding errors) - that is the N so that P^N<0.5 - for P=0.8 we get N=4; but for P=0.95 we get N=14.

[ShadMOrdre]

Astrobe,

I wanted to point out dokimi's [urlhttps://forum.minetest.net/viewtopic.php?f=9&t=17608&hilit=ecobot]self-organizing-systems[/url] mod. There are some great samples for naturally spreading things. Might make a good logic backend for gases.


Shad

[Astrobe]

Astrobe,

I wanted to point out dokimi's self-organizing-systems mod. There are some great samples for naturally spreading things. Might make a good logic backend for gases.


Shad

Yes! This is more or less a descendant of Dokimi's mod - selfrep_doomsday features an ever-expanding poison gas if I recall correctly. Perhaps not in code, but at least for inspiration. I wanted to give him/her credit the other day but couldn't find the reference. Thanks for finding it for me.

[Yvanhoe]

Astrobe: I agree with your post but the model used right now is extremely simple: constant downward speed, you are allowed to move in every direction a bit faster than if you were walking. Or stay still.

I don't do hangliding but my understanding is that you should be able to feel an upward force above a forest fire or magma pool. At least these effects would be felt. A single one-node fire would offer only a small and almost negligible lift, unless you station over it and then you basically have a balloon (I think staying still with hanglider should be disallowed, probably not hard)

But a true thermal map could be easy: use the surface map and compute the albedo (basically, the luminosity). Add a malus for water, a bonus for vegetation (or just the green channel, a pretty close approximation) and you have a good "thermal map" that produces uplifting forces above patches of white sand or forests.

Alternatively, add a random factor to it and add birds mods to make them guessable.

But all this is more complicated than just have an effect over the smoke nodes :-) Which I agree is probably more of a PR to the hanglider mode than the smoke.

[Astrobe]

Version 0.1 is out; see new links in the first post.

Changes:
- the drawtype of smoke is now "glasslike" to prevent visual glitches.
- the move direction of smoke when it cannot go up is now more random.
- jitters were added to the smoke node timer, so that they don't update all at once. It smooths the CPU load and is visually more pleasing IMO.
- adjusted the smoke parameters to achieve a good visuals/acceptable CPU load balance.
- added "default:lava_source" to the smoke sources.

What's next:
- split this into an API part and a usage part.
- When a mapblock becomes inactive because the player leaves the location, and then comes back later, the smoke nodes are still there (and start to move again). I'm split about this. On one hand this is a bit weird (it can suggest that e.g. a furnace was in use recently), on the other hand clearing the smoke nodes with an LBM can give odd results too (e.g. with lava lakes). On the third hand, this less likely to happen in multiplayer settings..

[texmex]

Good updates, will try out!

[texmex]

- Glasslike was a better look for sure. Still want to experiment with lightly animated textures.
- I'd still like for the smoke to travel a little random even is the upwards path is clear, enforcing chimney building and emulating wind impact a little
- I found the jittered timer feature a little annoying but perhaps I was too much in testing mode and not enough in gameplay mode.
- For the API part, can it be made to support different types of smoke, with different behaviors?
- Imo the smoke should stay in the mapblock. Like you say, it's weird to witness lava or a large fire start emitting smoke each time.

[Pyrollo]

You could have several densities of smoke (thick, average, thin). A thick smoke could spread into several thinner smoke nodes.

[FreeGamers]

Development of this mod has been progressing pretty smoothly. Its looking very neat. I'm looking forward to giving it a try soon :) It looks fun!

[texmex]

PR inbound!

[Astrobe]

PR inbound!

Thanks! It looks good indeed. You forgot to license your texture, though.

The update jitters now conflicts a little with the animation; the smoke nodes have a variable lifespan while the animation has a fixed duration. No big deal, but I'm considering changing the update jitters to a first-update-after-creation parameter in the future API, which would render the effect optional.

I'll try the "crawling" or "heavy" smoke as a second smoke type and behavior. Different behaviors are ok to me as long as they are different enough to justify a separate spread_smoke function. Heavy smoke will probably prefer to go down, horizontally or upwards in that order; it will probably need its own "persist" parameter and not to vanish at the mapblock boundaries.

Speaking of, the problem of "dead" smoke nodes high in the sky still bugs me. I'll try to introduce a malus to the "persist" parameter based on altitude. This will only mitigate the problem, but it has the additional potentially nice effect of becoming a bonus underground (because the altitude is negative). Currently the smoke cannot fill a closed space like a cave, which is a bit puzzling. Hopefully deep caves won't become deadly traps.

- I'd still like for the smoke to travel a little random even is the upwards path is clear, enforcing chimney building and emulating wind impact a little

This somewhat happens already: because of the update jitters sometimes a new smoke node that goes out of a furnace "collides" with the previous one and moves horizontally (this happens in "free" smoke columns too). I have set the main update cycle to 2.5s so that it doesn't happen too often. I tend to build small in my hardcore survival game, so having to build big chimneys to avoid smoke wandering on your ceiling is a bit annoying. I actually wanted a 2 seconds update cycle, but this was happening too often for my taste.

You could have several densities of smoke (thick, average, thin). A thick smoke could spread into several thinner smoke nodes.

I actually resisted the urge to develop a full-blown smoke simulation :-). But I want the mod to be viable on servers where lots of players use furnaces, visit lava lakes, etc. Perhaps even have torches to generate smoke too, in order to prevent players from abusing them. So I favor the possibility to handle lots of simple nodes over a fewer complex nodes.

[micheal65536]

The source ABM is innocent, the CPU activity mainly varies with the number of smoke nodes (timers only).

If my experience is anything to go by, ABMs are more efficient than node timers if you have a large set of identical nodes that you want to do something with. Node timers are better with one or two nodes because you know exactly where the nodes are and the engine won't have to scan every single loaded node to find the right ones, but with large numbers of nodes the performance penalty of firing and updating multiple individual node timers becomes greater than the savings from not using an ABM and ABMs can actually offer a performance advantage in that there's only one timer for the engine to keep track of and all the nodes can be scheduled for firing at the same time which is more efficient than firing hundreds of timers in turn.

I haven't done any particular testing on this but this has been my anecdotal experience, anyway. It might be worth trying your mod with ABMs rather than node timers and doing a comparison to see which method is actually faster.

[Astrobe]

The source ABM is innocent, the CPU activity mainly varies with the number of smoke nodes (timers only).

I haven't done any particular testing on this but this has been my anecdotal experience, anyway. It might be worth trying your mod with ABMs rather than node timers and doing a comparison to see which method is actually faster.

Maybe I'll try this, but one drawback I immediately see is that all smoke nodes will be updated at once (similar to what I had prior the introduction of update jitters), causing "spikes" of activity.