[Mod]Smoke [WIP]
[Mod]Smoke [WIP]
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.
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.
- Attachments
-
- smoke.zip
- Prototype implementation
- (1.21 KiB) Downloaded 156 times
-
- smoke2.png (131.48 KiB) Viewed 1943 times
-
- smoke1.png (197.07 KiB) Viewed 1943 times
Last edited by Astrobe on Sat Sep 07, 2019 08:15, edited 2 times in total.
- texmex
- Member
- Posts: 1753
- Joined: Mon Jul 11, 2016 21:08
- GitHub: tacotexmex
- In-game: tacotexmex
Re: [Mod]Smoke [WIP]
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
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
Re: [Mod]Smoke [WIP]
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.texmex wrote: - 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'll experiment with lava lakes with this change to see how it goes.
I was diagnosed with a genetic inability for graphics artwork, so someone will have to feed me textures.- Lightly animate the smoke node
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...
For those horrified by the three letters this is just for the smoke sources, the smoke nodes themselves use proper node timers.- Create support for pipes, look for a group name called chimney or similar
- Find a way to get rid of the ABM
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
- Member
- Posts: 1753
- Joined: Mon Jul 11, 2016 21:08
- GitHub: tacotexmex
- In-game: tacotexmex
Re: [Mod]Smoke [WIP]
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.
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
- Member
- Posts: 650
- Joined: Sat May 25, 2019 00:15
- GitHub: is proprietary I use NotABug
- Location: United States
- Contact:
Re: [Mod]Smoke [WIP]
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.
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.
FreeGamers.org has moved to MeseCraft.net | FreeGamers on this forum is now MeseCraft
Re: [Mod]Smoke [WIP]
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.FreeGamers wrote: 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 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.
Re: [Mod]Smoke [WIP]
My intuition was that find_node_near is a native function, so it had to be faster that Lua script (even with JIT).texmex wrote:I think find_node_near can be replaced with something faster since it’s fewer checks to do but maybe I’m wrong.
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).
It's not really woes, more like worries.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.
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.
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).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.
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.Maybe smoke can use such a mechanism of switching between being represented by a node and an entity?
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".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.
- BuckarooBanzay
- Member
- Posts: 437
- Joined: Tue Apr 24, 2018 05:58
- GitHub: BuckarooBanzay
- IRC: BuckarooBanzai
- In-game: BuckarooBanzai
Re: [Mod]Smoke [WIP]
Any chance you can put that on github/gitlab...?
-
- Member
- Posts: 407
- Joined: Sat Dec 29, 2018 19:21
- GitHub: KaylebJay
- IRC: KaylebJay
- In-game: CalebJ
- Location: Tunnelers' Abyss
Re: [Mod]Smoke [WIP]
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.
Good work, I'm excited about this mod's development.
Re: [Mod]Smoke [WIP]
You know, I'd love it if it interfaced with the hanglider to provide an uplift force where there is smoke.
- texmex
- Member
- Posts: 1753
- Joined: Mon Jul 11, 2016 21:08
- GitHub: tacotexmex
- In-game: tacotexmex
Re: [Mod]Smoke [WIP]
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.Yvanhoe wrote:You know, I'd love it if it interfaced with the hanglider to provide an uplift force where there is smoke.
Re: [Mod]Smoke [WIP]
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...texmex wrote: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.Yvanhoe wrote:You know, I'd love it if it interfaced with the hanglider to provide an uplift force where there is smoke.
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.
Re: [Mod]Smoke [WIP]
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.
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.
-
- Member
- Posts: 1118
- Joined: Mon Dec 29, 2014 08:07
- Location: USA
Re: [Mod]Smoke [WIP]
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
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
Re: [Mod]Smoke [WIP]
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.ShadMOrdre wrote: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
Re: [Mod]Smoke [WIP]
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.
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.
Re: [Mod]Smoke [WIP]
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..
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
- Member
- Posts: 1753
- Joined: Mon Jul 11, 2016 21:08
- GitHub: tacotexmex
- In-game: tacotexmex
- texmex
- Member
- Posts: 1753
- Joined: Mon Jul 11, 2016 21:08
- GitHub: tacotexmex
- In-game: tacotexmex
Re: [Mod]Smoke [WIP]
- 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.
- 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
- Developer
- Posts: 385
- Joined: Mon Jan 08, 2018 15:14
- GitHub: pyrollo
- In-game: Naj
- Location: Paris
Re: [Mod]Smoke [WIP]
You could have several densities of smoke (thick, average, thin). A thick smoke could spread into several thinner smoke nodes.
[ Display Modpack ] - [ Digiterms ] - [ Crater MG ] - [ LATE ]
- FreeGamers
- Member
- Posts: 650
- Joined: Sat May 25, 2019 00:15
- GitHub: is proprietary I use NotABug
- Location: United States
- Contact:
Re: [Mod]Smoke [WIP]
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!
FreeGamers.org has moved to MeseCraft.net | FreeGamers on this forum is now MeseCraft
- texmex
- Member
- Posts: 1753
- Joined: Mon Jul 11, 2016 21:08
- GitHub: tacotexmex
- In-game: tacotexmex
Re: [Mod]Smoke [WIP]
Thanks! It looks good indeed. You forgot to license your texture, though.texmex wrote:PR inbound!
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.
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.- 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 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.Pyrollo wrote: You could have several densities of smoke (thick, average, thin). A thick smoke could spread into several thinner smoke nodes.
-
- Member
- Posts: 167
- Joined: Mon May 22, 2017 20:27
Re: [Mod]Smoke [WIP]
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.Astrobe wrote: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.
Re: [Mod]Smoke [WIP]
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.micheal65536 wrote: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 wrote:The source ABM is innocent, the CPU activity mainly varies with the number of smoke nodes (timers only).
Who is online
Users browsing this forum: No registered users and 41 guests