Additional lighting in engine

[vladislavbelov]

I spent last 2 of my evening on the implementing of the addition light system in the pyrogenesis to find implementing bottlenecks for new objects. And I found some places, but that's not the topic.

How additional lighting system looks:

Fully dynamic lighting. And all light sources can be attached as props (i.e. to bones):

"May the Light be with you..."

But what restrictions do we have? We have 2 main:

1. The lights can't throw shadows, because performance (we can implement it, but only few powerful videocards can handle it).
2. There can't be many light sources in one place (at least for low videocards and since we don't support deferred rendering). Because shaders have own restrictions, particularly uniform sizes. But probably it's not the real problem.

So I have a question: do we need additional light sources in near releases? Would it be real useful?

P.S. I found strange normal values for some model, it should be investigated (probably the shader problem).

[Stan`]

1 hour ago, vladislavbelov said:

The lights can't throw shadows, because performance (we can implement it, but only few powerful videocards can handle it).

"Ultra" Option maybe ?

1 hour ago, vladislavbelov said:

There can't be many light sources in one place (at least for low videocards and since we don't support deferred rendering). Because shaders have own restrictions, particularly uniform sizes. But probably it's not the real problem.

Well it looks already gorgeous with the campfires.

 

1 hour ago, vladislavbelov said:

So I have a question: do we need additional light sources in near releases? Would it be real useful?

Why not ? Do you have a patch somewhere

@aeonios Ping

 

1 hour ago, vladislavbelov said:

P.S. I found strange normal values for some model, it should be investigated (probably the shader problem).

Which one ?

[Trinketos]

maybe the alpha 24 is the last alpha that my pc cant run

 

 

[wowgetoffyourcellphone]

So, if we get glow maps implemented we can have light sabers. Nice.  

[wowgetoffyourcellphone]

8 hours ago, stanislas69 said:

"Ultra" Option maybe ?

Yes, please. Don't automatically nerf graphics options just because not everyone can see them (yet). I remember a time when the team poo pooed the idea of normal maps or even self-shadowing (!).

 

Another thing we need is lighting conditions to affect particles correctly, such as smoke and dust. 

Edited June 27, 2018 by wowgetoffyourcellphone

[Lion.Kanzen]

1 minute ago, wowgetoffyourcellphone said:

So, if we get glow maps implemented we can have light sabers. Nice.  

Or glow aliens 

 

 

[Guest]

59 minutes ago, wowgetoffyourcellphone said:

Don't automatically nerf graphics options just because not everyone can see them (yet).

IMO, I don’t see a reason as to why the capabilities of the engine should be held back just because there maybe people who can’t run it.

Keeping features like this one as an option would give users with high-end machines a chance to enjoy them while at the same time others could still enjoy the game.

The awesome graphics capabilites of Pyrogenesis is a huge plus point for it and I guess it wont hurt to have more 

[Stan`]

Also it's worth noting that Pyrogenesis should be a standalone engine. Just because 0 A.D. cannot handle it doesn't mean the engine shouldn't support it. IMHO the engine split would be great for that.

[vladislavbelov]

20 hours ago, stanislas69 said:

"Ultra" Option maybe ?

Of course as option  I'm mostly interested, is it useful without shadows for artists/modders?

15 hours ago, Trinketos said:

maybe the alpha 24 is the last alpha that my pc cant run 

It'd be as option, so you'd can disable it.

11 hours ago, wowgetoffyourcellphone said:

So, if we get glow maps implemented we can have light sabers. Nice.  

It's a little bit different technique, the glow effect can exist without lightings.

20 hours ago, stanislas69 said:

Do you have a patch somewhere

Yep, but it requires the refactoring as I mentioned. So you could test my phab patches to accelerate this implementation

20 hours ago, stanislas69 said:

Which one ?

You may notice it on clothes on sticks near the bottom house of 2.

[Lion.Kanzen]

Can be nice try to Hyrule conquest such feature, a game with magic can need it.

Spoiler

 

 

[asterix]

3 minutes ago, Lion.Kanzen said:

Can be nice try to Hyrule conquest such feature, a game with magic can need it.

  Reveal hidden contents

 

 

it definitely will for Gohma (eg. eggs, glowing eyes ...) and other civs, which means it would be useful to be able to make settings for this in Atlas editor such as brightness or where to attach it ... 

[elexis]

The gifs look so good that it'd be a shame not to have it.

Imagine some guys walking through the forest with torches or a campfire at night!

[aeonios]

Hm. Without using some form of complexity reduction lights become very expensive very rapidly. 0ad's art heavily uses transparency so deferred rendering isn't an option. Forward+ could work but I'm pretty sure that requires openGL 3.x.

[Lion.Kanzen]

Spoiler

 

Lighting/laser and fire attacks,  force field shield...etc. 

[vladislavbelov]

On 6/29/2018 at 6:54 PM, aeonios said:

Forward+ could work but I'm pretty sure that requires openGL 3.x.

Nope, it doesn't need it.

On 6/29/2018 at 6:54 PM, aeonios said:

0ad's art heavily uses transparency so deferred rendering isn't an option.

The deffered rendering can be easily used with transparent objects too.

[vladislavbelov]

Another using of lightings:

[wowgetoffyourcellphone]

Awesome! Are you working on rain effects too? Those raindrops seem to be falling correctly, not like they do now. 

[aeonios]

27 minutes ago, vladislavbelov said:

Nope, it doesn't need it.

Eh, if you want more than a couple of lights then you do. I don't know if it absolutely needs openGL3.x but it does need to do some fancy data structure access in order to know which lights it needs to draw and to access the data for those lights. I don't know how all of that works unfortunately, and it seems to be more complicated to code than deferred rendering is.

29 minutes ago, vladislavbelov said:

The deffered rendering can be easily used with transparent objects too.

Sure, except that they won't be lit by dynamic lights at all, which would look really bad given the amount of transparency used in 0ad. Trees, bushes, even things like shields would stand out like a sore thumb. Everything under water as well. Forward+ would allow everything to be lit dynamically, deferred would not.

31 minutes ago, vladislavbelov said:

Another using of lightings:

That is pretty cool. Lightning looks kinda bad without dynamic shadows though.

[wowgetoffyourcellphone]

33 minutes ago, aeonios said:

That is pretty cool. Lightning looks kinda bad without dynamic shadows though.

Looks pretty good to me, even without dynamic shadows.

[Trinketos]

2 hours ago, vladislavbelov said:

Another using of lightings:

Weather confirmed?

[elexis]

Same question here, how is the rain implemented? (As the camera isn't moving it could also be a single 2D texture cheat)

The rain we currently have is extremely low performant and rotates with the camera tilt which is incorrect as mentioned by wow.

[vladislavbelov]

On 7/4/2018 at 2:29 AM, wowgetoffyourcellphone said:

Awesome! Are you working on rain effects too? Those raindrops seem to be falling correctly, not like they do now. 

Currently I'm trying to add features that popular in modern engines and liked by players to find different implementation bottlenecks in our code.

On 7/4/2018 at 2:51 AM, aeonios said:

Eh, if you want more than a couple of lights then you do. I don't know if it absolutely needs openGL3.x but it does need to do some fancy data structure access in order to know which lights it needs to draw and to access the data for those lights. I don't know how all of that works unfortunately, and it seems to be more complicated to code than deferred rendering is.

Yes, I mentioned, that it doesn't support many lights per model. Usually video card can support from 8 to 128 lights per model. It uses simple uniform structs (even not UBO).

// 8 floats per struct.
struct PointLight
{
	vec3 position;
	float radius;
	// vec2 - compressed 4 components, instead of unsupported "half".
	vec2 color;
	vec2 coef; // Cubic curve coef.
};

So we can calculate how many lights we can use from GL_MAX_FRAGMENT_UNIFORM_COMPONENTS.

On 7/4/2018 at 2:51 AM, aeonios said:

Sure, except that they won't be lit by dynamic lights at all, which would look really bad given the amount of transparency used in 0ad. Trees, bushes, even things like shields would stand out like a sore thumb. Everything under water as well. Forward+ would allow everything to be lit dynamically, deferred would not.

There're 2 import notes: 1) we can use forward and deferred rendering simultaneously (i.e. for different distance), 2) as you noticed we don't have a lot of semitransparent objects; trees, bushes have transparent only for soft edges, so on enough distances we can render them without alpha blending and they're not transparent objects anymore (we don't need to be honest for rendering always; if it looks the same/very similar but cheaper, then we'd can use the cheaper one).

On 7/4/2018 at 2:51 AM, aeonios said:

That is pretty cool. Lightning looks kinda bad without dynamic shadows though.

If we assume that we don't have a sun at rain, then we'd easily add shadows to the lightnings

On 7/4/2018 at 4:49 AM, Trinketos said:

Weather confirmed?

Nope (at least not yet). It'd be confirmed when it'll be in the our main repository

22 hours ago, elexis said:

Same question here, how is the rain implemented? (As the camera isn't moving it could also be a single 2D texture cheat)

The rain we currently have is extremely low performant and rotates with the camera tilt which is incorrect as mentioned by wow.

It uses 2D rain texture (drawn by me in Ps for 5 mins ) on many long crosses with double side rendering (because many particles would be slow). They're not moving when the camera is moving. So it seems a correct rain. Current implementation doesn't use shaders yet, but with shaders it can be a little bit nicer.

[Stan`]

38 minutes ago, vladislavbelov said:

It uses 2D rain texture (drawn by me in Ps for 5 mins ) on many long crosses with double side rendering (because many particles would be slow). They're not moving when the camera is moving. So it seems a correct rain. Current implementation doesn't use shaders yet, but with shaders it can be a little bit nicer.

Can you make this a separate patch ? The best way, would be a simulation triggerable version of it  But a map specific one is fine too.

[aeonios]

2 hours ago, vladislavbelov said:

There're 2 import notes: 1) we can use forward and deferred rendering simultaneously (i.e. for different distance), 2) as you noticed we don't have a lot of semitransparent objects; trees, bushes have transparent only for soft edges, so on enough distances we can render them without alpha blending and they're not transparent objects anymore (we don't need to be honest for rendering always; if it looks the same/very similar but cheaper, then we'd can use the cheaper one).

That's not actually true. Most of the foliage uses transparency not only for soft edges but also to blend with terrain and other foliage behind. I messed around with foliage a bit and found that the bleed-through effect was much more prominent than the soft-edge effect (which doesn't seem to be used particularly well at all). Fixing all of the art to use alpha test would take a lot of work and the results might be questionable.

2 hours ago, vladislavbelov said:

It uses 2D rain texture (drawn by me in Ps for 5 mins ) on many long crosses with double side rendering (because many particles would be slow). They're not moving when the camera is moving. So it seems a correct rain. Current implementation doesn't use shaders yet, but with shaders it can be a little bit nicer.

Particles can be fast but you have to use drawinstanced and geometry shaders, which are GL3.

[vladislavbelov]

1 hour ago, aeonios said:

That's not actually true. Most of the foliage uses transparency not only for soft edges but also to blend with terrain and other foliage behind. I messed around with foliage a bit and found that the bleed-through effect was much more prominent than the soft-edge effect (which doesn't seem to be used particularly well at all). Fixing all of the art to use alpha test would take a lot of work and the results might be questionable.

The terrain isn't transparent and blending doesn't make sense after the blending is done (especially on long distances), so there is no problem with it. Yes, it requires a work, but it's simple.

1 hour ago, aeonios said:

Particles can be fast but you have to use drawinstanced and geometry shaders, which are GL3.

True, as the tessellation one  But it's the another level. It can't be faster than simple quads with a texture. But it can be nicer.