[ON HOLD] Bumi: Real-Time Day/Night & Weather
Forum rules
Before posting your Resource, please make sure you can answer YES to any of the following questions:
Consult the Resource/Request Posting Guidelines for more information.
Please don't put requests here! They have their own forum --> here. Thank you!
Before posting your Resource, please make sure you can answer YES to any of the following questions:
- Is the resource ENTIRELY my own work?
- If no to the previous one, do I have permission from the original author?
- If no to the previous one, did I put a reasonable amount of work into the resource myself, such that the changes are noticeably different from the source that I could take credit for them?
Consult the Resource/Request Posting Guidelines for more information.
Please don't put requests here! They have their own forum --> here. Thank you!
-
- Posts: 170
- Joined: Tue Jul 28, 2015 6:30 am
- Location: United States
Re: [ON HOLD] Bumi: Real-Time Day/Night & Weather
I love this, especially having watched the demonstrations of the seasons you have here! I would like seeing the trees during the fall- I can easily imagine you pulling off some Hexen-styled leaf falling animations for those along will some colorful leaves. It'd be seriously beautiful to see in conjunction with an actual serious scene/level. You're doing great, Nash!
-
- Posts: 1562
- Joined: Tue Oct 20, 2015 12:50 pm
- Graphics Processor: nVidia with Vulkan support
- Location: Kozolupy, Bohemia
Re: [ON HOLD] Bumi: Real-Time Day/Night & Weather
Hi Nash, any progress on this? The last you said that it is finished...
-
-
- Posts: 17468
- Joined: Mon Oct 27, 2003 12:07 am
- Location: Kuala Lumpur, Malaysia
Re: [ON HOLD] Bumi: Real-Time Day/Night & Weather
This entire system is going through a massive overhaul... basically a rewrite almost from scratch to ZScript.
Progress? I've already made a ZScript actor that turns all the lights to black in the entire level when you type "summon bumi", no sector tags required... so yeah, I'm off to a good start. :P
Progress? I've already made a ZScript actor that turns all the lights to black in the entire level when you type "summon bumi", no sector tags required... so yeah, I'm off to a good start. :P
-
- Posts: 9
- Joined: Sat Sep 03, 2016 11:25 am
Re: [ON HOLD] Bumi: Real-Time Day/Night & Weather
ZScript.... Well that basically kills my hype to try this on Zandronum....
(also is the github private on purpose? it would be interesting to look at the coding.)

(also is the github private on purpose? it would be interesting to look at the coding.)
-
- Posts: 80
- Joined: Wed Jul 02, 2014 2:44 pm
Re: [ON HOLD] Bumi: Real-Time Day/Night & Weather
Even then, I tried this on Zandronum 4.0 a while ago.TGminer wrote:ZScript.... Well that basically kills my hype to try this on Zandronum....![]()
(also is the github private on purpose? it would be interesting to look at the coding.)
Wouln't reccomend.
-
-
- Posts: 17468
- Joined: Mon Oct 27, 2003 12:07 am
- Location: Kuala Lumpur, Malaysia
Re: [ON HOLD] Bumi: Real-Time Day/Night & Weather
Yeah I can imagine it'll be slow, even if Zan supported ZScript.
My ZScript re-write is almost complete (all that's left is precipitation spawning and the season texture swap), here are some numbers:
My machine:
i7 950 @ 3.2 GHz
NVidia GTX 960
15 GB DDR3
Win 8.1
GZDoom at stock settings with all post processing turned off, VSync off, 1920x1200
On a simple square map with 2 sectors
Without Bumi: 800 FPS
With Bumi: 300 FPS
So yea, this system comes with a 500 FPS overhead. 2 main suspects right now are the colour tinter and the clouds.
The former is running a sector iterator and applying colourization to them. There's already calculations in there to skip colourization if the previous colour is the same as the current colour but I'm not sure if it really works correctly, or if it's enough. Due to the large number I use to keep track of time per day, it is possible to generate LOTS of shades of colours so the colourization is still happening frequently. I can try to quantize the colours to a smaller gradient but the colours won't look so nice as time moves, as the colours will "snap" to the nearest gradient (kinda like how the software renderer can't produce smooth colour ramps).
I could also look into pre-generating the list of colours at map-start instead of calculating them every Bumi-tick but I'm not sure if that will really help much.
The latter, the clouds - each instance of a cloud is querying the main Bumi class every Bumi-tick to calculate the cloud's alpha - things like whether it's overcasting/raining or not, how far it is from the center of the skybox, etc. I think that distance check in particular is quite expensive. I'm already limiting the clouds to run the query every Bumi-tick (which is slower than a real-life Doom tick), maybe I can afford to make that less frequent.
Do note that the 500 FPS cost is true also for the ACS version back then so it's not like moving this to ZScript made it slower. It's already as fast as it can be.
I don't know how Zandronum works and I have no experience optimizing stuff to be network friendly, so yeah... tl;dr it probably won't play nice in Zan.
EDIT:
Bumi spawns 2 semitransparent skydomes and several clouds into the skybox. I guess all that transparency overdraw costs roughly ~250 just for them to exist and be drawn (this is spawning the objects - the Bumi ticker is disabled)
I also get a 300 FPS decrease just by looking at the chainsaw-balcony area at the start of Doom 2 (no mods), or if there's a horizon line.
I'm not sure if I should worry about these last 2 too much... you probably get the same CPU overhead just loading Brutal Doom :V
My ZScript re-write is almost complete (all that's left is precipitation spawning and the season texture swap), here are some numbers:
My machine:
i7 950 @ 3.2 GHz
NVidia GTX 960
15 GB DDR3
Win 8.1
GZDoom at stock settings with all post processing turned off, VSync off, 1920x1200
On a simple square map with 2 sectors
Without Bumi: 800 FPS
With Bumi: 300 FPS
So yea, this system comes with a 500 FPS overhead. 2 main suspects right now are the colour tinter and the clouds.
The former is running a sector iterator and applying colourization to them. There's already calculations in there to skip colourization if the previous colour is the same as the current colour but I'm not sure if it really works correctly, or if it's enough. Due to the large number I use to keep track of time per day, it is possible to generate LOTS of shades of colours so the colourization is still happening frequently. I can try to quantize the colours to a smaller gradient but the colours won't look so nice as time moves, as the colours will "snap" to the nearest gradient (kinda like how the software renderer can't produce smooth colour ramps).
I could also look into pre-generating the list of colours at map-start instead of calculating them every Bumi-tick but I'm not sure if that will really help much.
The latter, the clouds - each instance of a cloud is querying the main Bumi class every Bumi-tick to calculate the cloud's alpha - things like whether it's overcasting/raining or not, how far it is from the center of the skybox, etc. I think that distance check in particular is quite expensive. I'm already limiting the clouds to run the query every Bumi-tick (which is slower than a real-life Doom tick), maybe I can afford to make that less frequent.
Do note that the 500 FPS cost is true also for the ACS version back then so it's not like moving this to ZScript made it slower. It's already as fast as it can be.
I don't know how Zandronum works and I have no experience optimizing stuff to be network friendly, so yeah... tl;dr it probably won't play nice in Zan.
EDIT:
Bumi spawns 2 semitransparent skydomes and several clouds into the skybox. I guess all that transparency overdraw costs roughly ~250 just for them to exist and be drawn (this is spawning the objects - the Bumi ticker is disabled)
I also get a 300 FPS decrease just by looking at the chainsaw-balcony area at the start of Doom 2 (no mods), or if there's a horizon line.
I'm not sure if I should worry about these last 2 too much... you probably get the same CPU overhead just loading Brutal Doom :V

-
- Posts: 135
- Joined: Sat Mar 18, 2017 6:34 am
Re: [ON HOLD] Bumi: Real-Time Day/Night & Weather
Excited when you get this finished; hope my computer could actually run it
-
- Posts: 115
- Joined: Sun Feb 25, 2018 10:53 am
- Location: Tatarstan
Re: [ON HOLD] Bumi: Real-Time Day/Night & Weather
Very good looking.
Will this be built into the gzdoom?
Will this be built into the gzdoom?
-
- Posts: 598
- Joined: Sun Jul 31, 2016 2:43 pm
Re: [ON HOLD] Bumi: Real-Time Day/Night & Weather
...Probably not? It's an engine for people to use in other projects, like if someone made an open world game in the engine.camper wrote:Will this be built into the gzdoom?
The one thing you might be able to do is add it as a mod on top of normal maps, so you can have weather in your doom / hexen maps...
-
-
- Posts: 17468
- Joined: Mon Oct 27, 2003 12:07 am
- Location: Kuala Lumpur, Malaysia
Re: [ON HOLD] Bumi: Real-Time Day/Night & Weather
This is built for and into a commercial game project, and will be built as part of a complete open world RPG toolkit. In other words, the weather/time stuff won't be available separately. Think of it like the Creation Engine. All in one open world RPG system.
The template/toolkit will be released after said game is released, but I won't support any attempts to separate the weather/time system from the other RPG stuff. You'll be on your own.
The template/toolkit will be released after said game is released, but I won't support any attempts to separate the weather/time system from the other RPG stuff. You'll be on your own.