Jump to content
The Dark Mod Forums
Sign in to follow this  
cabalistic

Heads up: New (HDR) Bloom effect in 2.08 for bright light sources

Recommended Posts

Nicely done. I have lamps in 2 WIPs that could certainly use this effect.

 

Thanks!

Share this post


Link to post
Share on other sites
On 4/27/2020 at 11:12 PM, cabalistic said:

(The downside, of course, is that both Bloom and 64 bit color precision are not going to be on by default in 2.08. If they are off, the lamps will just appear white without glow.)

Does that mean, that the new feature isn't actually usable in 2.08, because almost all players will see sharply-edged white blobs instead of glowing lights?

Share this post


Link to post
Share on other sites

You'll have to decide that for yourself. This is what the above screen looks like with bloom disabled:

no_bloom.jpg.19a03a9d4e0b36d53ac87768005abdd7.jpg

  • Like 1

Share this post


Link to post
Share on other sites
6 minutes ago, cabalistic said:

You'll have to decide that for yourself. This is what the above screen looks like with bloom disabled:

That does look a bit odd, but far from my imagination. Seems to be like with soft shadows: As a player you definitely want them and can't go back after seeing them. But if you never saw them, sharp shadows are okay.
I will definitely enable the double color mode as soon as 2.08 beta 5 becomes available.

Is there any chance, that vanilla lights also get the HDR treatment?

Share this post


Link to post
Share on other sites

Vanilla lights will look similar to how they looked like with 2.07 and earlier postprocessing turned on. To make use of this feature, you need to make changes in the model material as described above. But aside from new possibilities for Bloom, the r_fboColorBits 64 value increases the rendering quality of all gradient textures in lights, particles, fog etc. Small comparison, on the left r_fboColorBits 32, on the right r_fboColorBits 64. See how banding is substantially reduced. IMO for that effect alone, it's worth switching to 64 bits.

 

obraz.png

obraz.png

Edited by peter_spy
  • Like 2

Share this post


Link to post
Share on other sites
14 hours ago, peter_spy said:

See how banding is substantially reduced. IMO for that effect alone, it's worth switching to 64 bits.

Yes, that is a significant improvement. There still is some slight banding - but it is way less noticable.
This should be on by default.

Edited by Abusimplea

Share this post


Link to post
Share on other sites
On 4/28/2020 at 8:02 PM, joebarnin said:

Nice! How do you actually enable this on a specific light?

In the material for your light source, just add a new blend stage, like this:

	{
		blend	add
		map		textures/models/light_emissive
		rgb     10
	}

Use a texture which highlights the emissive parts of your light source (i.e. the areas that shine light), then use the "rgb" factor to scale the light to your desired brightness.

  • Like 2
  • Thanks 1

Share this post


Link to post
Share on other sites

Very nice, congrats to whoever implemented HDR in the engine, tried to do the same my self, failed, very bad at graphics programming, failed on the part where you have to create a 16bits (half_Float) idImage, instead of using the normal 8bits one, was to low level stuff to my brain.

Btw would love to see a comparative to a flare material in look and performance, I assume that even tho a flare material, wouldn't look that good, it would be faster? I'm thinking in the case where you enable this on many lights in a scene. 

Share this post


Link to post
Share on other sites

Bloom is a screen-space effect, it has a constant cost independent of the number of lights (or bright spots). That cost is very low; I think it was below 0.5ms on a GTX 1050Ti mobile. I don't know how many fake halos you can render in that time (probably quite a few), but compared to the total cost of scene rendering, you are unlikely to notice this one, except on really old hardware perhaps :)

  • Like 2

Share this post


Link to post
Share on other sites
1 hour ago, HMart said:

I assume that even tho a flare material, wouldn't look that good, it would be faster?

It's exactly the opposite, and that's why I requested the bloom feature some time ago. As Cabalistic said, bloom is a screen post-effect, it has a constant cost, it just uses a defined threshold to blur pixels above certain intensity values. Halos used so far in TDM are emitters. Not only do these use several particles per second, they also need transparent materials. So having e.g. several dozens of lanterns in a street will be much more demanding, both due to particle emitters and big transparency overdraw. Using bloom is much, much more efficient.

Edited by peter_spy

Share this post


Link to post
Share on other sites
1 hour ago, cabalistic said:

Bloom is a screen-space effect, it has a constant cost independent of the number of lights (or bright spots). That cost is very low; I think it was below 0.5ms on a GTX 1050Ti mobile. I don't know how many fake halos you can render in that time (probably quite a few), but compared to the total cost of scene rendering, you are unlikely to notice this one, except on really old hardware perhaps :)

Ah ok that makes sense. Thanks for the info. 

 

20 minutes ago, peter_spy said:

It's exactly the opposite, and that's why I requested the bloom feature some time ago. As Cabalistic said, bloom is a screen post-effect, it has a constant cost, it just uses a defined threshold to blur pixels above certain intensity values. Halos used so far in TDM are emitters. Not only do these use several particles per second, they also need transparent materials. So having e.g. several dozens of lanterns in a street will be much more demanding, both due to particle emitters and big transparency overdraw. Using bloom is much, much more efficient.

I agree but I was not talking about particle emitters but this flare system that comes with idtech 4, but is moot point now, I like the look of this new "flares" and if faster the better. :) 

Share this post


Link to post
Share on other sites
9 hours ago, cabalistic said:

Bloom is a screen-space effect, it has a constant cost independent of the number of lights (or bright spots). That cost is very low; I think it was below 0.5ms on a GTX 1050Ti mobile. I don't know how many fake halos you can render in that time (probably quite a few), but compared to the total cost of scene rendering, you are unlikely to notice this one, except on really old hardware perhaps :)

The cost of bloom itself is pretty low, but the cost of HDR is not so evident. It increases size of framebuffer color image by 100%, size of the whole framebuffer by 50%, and total memory consumed by framebuffers by 33% or 25%. If a particular scene is limited by memory bandwidth or size on particular hardware, it might be noticeable. Don't forget about integrated GPUs, which use ordinary RAM.

8 hours ago, peter_spy said:

It's exactly the opposite, and that's why I requested the bloom feature some time ago. As Cabalistic said, bloom is a screen post-effect, it has a constant cost, it just uses a defined threshold to blur pixels above certain intensity values. Halos used so far in TDM are emitters. Not only do these use several particles per second, they also need transparent materials. So having e.g. several dozens of lanterns in a street will be much more demanding, both due to particle emitters and big transparency overdraw. Using bloom is much, much more efficient.

I don't think fake bloom has considerable performance cost. Moreover, you don't need to create particle for the halo, a transparent func_static is enough. I thought light flares are created like this.

UPDATE: Also you should take into account that some people won't want to enable bloom in its current form, regardless of whether HDR is enabled or not.

Share this post


Link to post
Share on other sites
4 hours ago, stgatilov said:

Moreover, you don't need to create particle for the halo, a transparent func_static is enough.

You need a particle, so the transparent plane can constantly turn to face the player position. And since they are stacked together and occupy quite a lot of space, you will run into transparency overdraw problems at some point.

obraz.png

Not to mention that making light with postprocess bloom is much faster. You just make an emissive texture and tweak the rgb value in the material. You don't have to create emitters, tweak their positions, colors, particle sizes, etc.

 

4 hours ago, stgatilov said:

Don't forget about integrated GPUs, which use ordinary RAM.

Most laptops with integrated GPUs are not suited towards running games, they're business-oriented machines. Since TDM is demanding in all other areas anyway, including them as target hardware doesn't make much sense. A dedicated 1-2 GB VRAM GPU is an ancient hardware at this point, an it can be easily used as baseline instead.

Edited by peter_spy

Share this post


Link to post
Share on other sites
5 hours ago, stgatilov said:

The cost of bloom itself is pretty low, but the cost of HDR is not so evident. It increases size of framebuffer color image by 100%, size of the whole framebuffer by 50%, and total memory consumed by framebuffers by 33% or 25%. If a particular scene is limited by memory bandwidth or size on particular hardware, it might be noticeable. Don't forget about integrated GPUs, which use ordinary RAM.

Yeah, that's fair enough, although so far I haven't found an instance where HDR actually has a significant overhead. Just for fun, I tested it on my GPD Win 2 with its dual-core M3 and an HD615, and the framerate difference between 32 bit color precision and no bloom to 64 bit color precision with bloom was something like 35 to 32 fps in the beginning of "A new job". Not that that's an exhaustive test or anything, and as you say, there could be scenes that react more strongly. But my impression is that even the low end of the current hardware generation is pretty well optimized to handle floating point buffers.

  • Like 1

Share this post


Link to post
Share on other sites
8 hours ago, peter_spy said:

You need a particle, so the transparent plane can constantly turn to face the player position. And since they are stacked together and occupy quite a lot of space, you will run into transparency overdraw problems at some point.

obraz.png

Not to mention that making light with postprocess bloom is much faster. You just make an emissive texture and tweak the rgb value in the material. You don't have to create emitters, tweak their positions, colors, particle sizes, etc.

 

Most laptops with integrated GPUs are not suited towards running games, they're business-oriented machines. Since TDM is demanding in all other areas anyway, including them as target hardware doesn't make much sense. A dedicated 1-2 GB VRAM GPU is an ancient hardware at this point, an it can be easily used as baseline instead.

Not that I'm trying to diminish your guys work or make you guys think that implementing HDR and this screen space bloom, was wasted work or not usefull, far from it, HDR IMO is useful for more than bloom and flares.

But about Flares, peter_spy you don't need a particle system to do flares, you can use a single plane with a material using the global keyword "deform sprite" and it will always look at the player, you can also use the global material keyword "flare <size>", for the system I posted above, see some of the Doom 3 flare materials, if you can and don't know how was done. If you have been using entire particle system to do simple flares, no wonder you think they are slow.  One thing I don't know is if sprites and the special flare system,  in TDM engine can be made soft like particles can. 

edit: And if you want to give "movement" to the flare effect using the "deform sprite" trick you can use a image strip and use the stage keyword "scroll" to change frames. 

Edited by HMart

Share this post


Link to post
Share on other sites
1 hour ago, HMart said:

But about Flares, peter_spy you don't need a particle system to do flares, you can use a single plane with a material using the global keyword "deform sprite" and it will always look at the player, you can also use the global material keyword "flare <size>", for the system I posted above, see some of the Doom 3 flare materials, if you can and don't know how was done. If you have been using entire particle system to do simple flares, no wonder you think they are slow.  One thing I don't know is if sprites and the special flare system,  in TDM engine can be made soft like particles can. 

I haven't been using particles to make flares, it's what I found in fms and TDM assets, and I've seen how slow they can be. Try putting a dozen candles or so in one spot, and you'll see what I mean. These have like 20 particles per second to simulate the glow. It seems like they were meant to be used as a singular source of light only.

I guess that flares made sense in Doom3 days and earlier, when there was no proper bloom and HDR. But today, they're going against the grain as much as emitters, from both performance and content creation perspective. I assume you'll either need a separate flare model (plane) with its material, or two materials per light model, one for light itself, another for flare, which is both additional work and a waste of processing power (2 materials per model instead of one, or two models instead of one). On the top of that, you need a transparent material for the flare, which has added cost of that, plus the possibility to overdraw problem when several light models are placed in one line or close by.

Bloom has none of these problems and it's much faster to create. You have to make the blend add texture anyway, so the light model looks lit, and then all you have to do is set the RGB value over 1.

Last but not least, this is how this feature/workflow is used in other engines, so knowledge of Unity, Unreal or other engine is transferable here. Anyone coming to make stuff for TDM will feel at home, at least with this feature.

Share this post


Link to post
Share on other sites

Yes if those assets come with such heavy effect than imo they should be revised and it will not break the existent missions. Is like those making a candelabra and using a light for each candle instead of single light, I did that before knowing how wasteful that was.

I'm all for Bloom and HDR like anyone else but I still think flares made with planes, still make sense today, specially if you are doing a game for low end mobile or retro hardware and want to spend graphics power in other more important stuff and imo making a light with a extra plane for the flare, is not that work intensive, is more than switching bloom on but is not hard or something, making the main light model and material is the hard part.

Anyone coming from latest Unity, Unreal 4 or any modern engine may feel a little at home in TDM, because there's many premade stuff and the tools are relatively easy, but them coming to idtech 4 in general after working in those engines, is like driving for years only on automatic cars and coming back to a manual shift car, with hand driven windows and no parking assistance, shit will hit the fan fast.  😜

Edited by HMart
  • Like 1

Share this post


Link to post
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.

Sign in to follow this  

×
×
  • Create New...