8 replies to this topic

[deathwearer]

I'm uncertain about how Shaders are "tied" to the game.

Let's say I have a Specular lighting Shader. It probably have lightsource's parameters. (Direction, intensity, etc). It does it's calculation and the graphic card use that to draw on the screen. This part is fine for me (At least if I'm not mistaken). But how is the Shader aware of the lightsource? I need to pass this information when I render with this Shader? Who check if the lightsource is blocked by another object before it reach my rendering object? Is it my scene renderer that need to make a check before it send the lightsource to the Shader?

Also is it possible that your Shader communicate with your game/other shader? In the case of a high reflectance surface could your Shader "re-emit" light that will be taken in consideration when rendering other objects?

Edited by deathwearer, 06 December 2012 - 09:01 AM.

[Radikalizm]

The graphics API you're using will provide ways for you to submit data to your shaders, so depending on what kind of setup you're using you can check which lights should light an object (note: I'm not talking about actual occlusion/shadows here) and you can send all the light data required to your shader before you render your object.

Occlusion and shadows can be done on the GPU, so your renderer doesn't have to take care of that on the CPU-side. Have a look at shadow mapping to see how occlusion is done (be prepared to do a lot of reading though, it's a very broad subject). Shadow mapping isn't the only solution for this though, but it's the most popular one at the moment.

Also is it possible that your Shader communicate with your game/other shader? In the case of a high reflectance surface could your Shader "re-emit" light that will be taken in consideration when rendering other objects?

Light bouncing off objects is called Indirect Illumination (sometimes also called Global Illumination) and is quite an advanced subject. Note that indirect illumination doesn't only come into play for highly reflective surfaces, every 'colored' surface will bounce off light. There are techniques to achieve indirect lighting in real-time on the GPU, but there are also techniques for pre-calculating this on the CPU. Each technique has its pro's and its cons though, in general indirect illumination is still very expensive in real-time applications and mostly cuts corners here and there to achieve actual usable results, while pre-calculated results can get accurate (diffuse only) results as long as no lights or objects in the scene move. There's still a lot of research being done on this subject, and some amazing techniques have been developed for future applications (have a look at "Interactive Indirect Illumination Using Voxel Cone Tracing" by C. Crassin for such a technique).

Edited by Radikalizm, 06 December 2012 - 09:56 AM.

[deathwearer]

The graphics API you're using will provide ways for you to submit data to your shaders, so depending on what kind of setup you're using you can check which lights should light an object (note: I'm not talking about actual occlusion/shadows here) and you can send all the light data required to your shader before you render your object.

Let's say it's dirextx. In my game I first check if the light is not blocked and send the light info to the shaders? So I manually (Just for the sake of my question I'm not using an engine or anything) check every light and set them or not to the shaders before I render?

Occlusion and shadows can be done on the GPU, so your renderer doesn't have to take care of that on the CPU-side. Have a look at shadow mapping to see how occlusion is done (be prepared to do a lot of reading though, it's a very broad subject). Shadow mapping isn't the only solution for this though, but it's the most popular one at the moment.

Do you have any tutorials you could recommand me on this? I'm not sure I understand the concept or what your trying to explain.

Also is it possible that your Shader communicate with your game/other shader? In the case of a high reflectance surface could your Shader "re-emit" light that will be taken in consideration when rendering other objects?

Light bouncing off objects is called Indirect Illumination (sometimes also called Global Illumination) and is quite an advanced subject. Note that indirect illumination doesn't only come into play for highly reflective surfaces, every 'colored' surface will bounce off light. There are techniques to achieve indirect lighting in real-time on the GPU, but there are also techniques for pre-calculating this on the CPU. Each technique has its pro's and its cons though, in general indirect illumination is still very expensive in real-time applications and mostly cuts corners here and there to achieve actual usable results, while pre-calculated results can get accurate (diffuse only) results as long as no lights or objects in the scene move. There's still a lot of research being done on this subject, and some amazing techniques have been developed for future applications (have a look at "Interactive Indirect Illumination Using Voxel Cone Tracing" by C. Crassin for such a technique).

I'll pass this one for now ;) and try to understand the basic concept. It was a question to understand how shaders could communicate between each other or impact your game in a way.

[Radikalizm]

Let's say it's dirextx. In my game I first check if the light is not blocked and send the light info to the shaders? So I manually (Just for the sake of my question I'm not using an engine or anything) check every light and set them or not to the shaders before I render?

When you're doing forward shading (ie. you render and light each object one by one after eachother) you would look for the lights which would affect your object (for point and spot lights you would check whether the renderable object falls within their light volumes, being a sphere for points lights and a cone for spot lights. Plain directional lights will always affect each object), and you send each light's data to an appropriate shader. You'll have to make sure you have shader permutations which can handle these setups though.
If you're in a situation where you have a lot of lights you might want to set a limit on how many lights can affect an object at once, and you'll have to apply some optimization tricks like only uploading the nearest n lights, with n being your light limit per object, or merging some more distant lights together until you get an acceptable light count.
Another solution would be to use deferred rendering/shading which effectively decouples geometry from lighting, allowing for an incredible amount of lights at the cost of memory usage and material complexity.

Do you have any tutorials you could recommand me on this? I'm not sure I understand the concept or what your trying to explain.

I'm not up to date on the latest tutorials on these subjects, so I'm afraid I can't directly recommend you anything. I'm sure that a google search for "shadow mapping" will get you some valid results though.

I'll pass this one for now ;) and try to understand the basic concept. It was a question to understand how shaders could communicate between each other or impact your game in a way.

Remember that shaders are completely able to read and write data, and that data can be (re-)used by other shaders as well. When talking about pixel/fragment shaders this writing of data will mostly be in the form of textures (not considering advancements made in newer graphics APIs which allow some shaders to write to random access buffers as well), and textures can be used as buffers to store calculation results.
So to establish 'communication' between shaders, one shader could do some sort of calculation and write its results to a texture (which is bound as a render target), while another shader can use that texture afterwards as input to do its own calculations.

[deathwearer]

Let's say it's dirextx. In my game I first check if the light is not blocked and send the light info to the shaders? So I manually (Just for the sake of my question I'm not using an engine or anything) check every light and set them or not to the shaders before I render?

When you're doing forward shading (ie. you render and light each object one by one after eachother) you would look for the lights which would affect your object (for point and spot lights you would check whether the renderable object falls within their light volumes, being a sphere for points lights and a cone for spot lights. Plain directional lights will always affect each object), and you send each light's data to an appropriate shader. You'll have to make sure you have shader permutations which can handle these setups though.
If you're in a situation where you have a lot of lights you might want to set a limit on how many lights can affect an object at once, and you'll have to apply some optimization tricks like only uploading the nearest n lights, with n being your light limit per object, or merging some more distant lights together until you get an acceptable light count.
Another solution would be to use deferred rendering/shading which effectively decouples geometry from lighting, allowing for an incredible amount of lights at the cost of memory usage and material complexity.

Forward shading? Is there any other techniques? (Guess so). I think I understand what you say, and it looks like how I thought it would work. However Directional light doesn't affect every object no? The light could be blocked by a wall for exemple.

Do you have any tutorials you could recommand me on this? I'm not sure I understand the concept or what your trying to explain.

I'm not up to date on the latest tutorials on these subjects, so I'm afraid I can't directly recommend you anything. I'm sure that a google search for "shadow mapping" will get you some valid results though.

I Sure will thank. (Meanwhile if someone else has a recommended article I will read it)

I'll pass this one for now ;) and try to understand the basic concept. It was a question to understand how shaders could communicate between each other or impact your game in a way.

Remember that shaders are completely able to read and write data, and that data can be (re-)used by other shaders as well. When talking about pixel/fragment shaders this writing of data will mostly be in the form of textures (not considering advancements made in newer graphics APIs which allow some shaders to write to random access buffers as well), and textures can be used as buffers to store calculation results.
So to establish 'communication' between shaders, one shader could do some sort of calculation and write its results to a texture (which is bound as a render target), while another shader can use that texture afterwards as input to do its own calculations.

Yes I forgot that a Shader can output data. So I could forward this data to another Shader. But I guess it gets very complicated since you also need to calculate the other objects that it will impact...

[Radikalizm]

Forward shading? Is there any other techniques? (Guess so). I think I understand what you say, and it looks like how I thought it would work. However Directional light doesn't affect every object no? The light could be blocked by a wall for exemple.

Yes there are plenty of other techniques, deferred rendering and deferred shading (also known as light pre-pass rendering) are examples of these, like I mentioned. There are a whole bunch of variations or hybrids of these techniques as well though, each with their own benefits.

Forward shading? Is there any other techniques? (Guess so). I think I understand what you say, and it looks like how I thought it would work. However Directional light doesn't affect every object no? The light could be blocked by a wall for exemple.

Yes, light can be blocked by objects like walls, but that's not a problem you want to solve on the CPU as the GPU is much more effective at solving these problems in this situation, you want to use a shadowing technique for that (like shadow mapping, as mentioned).

[deathwearer]

Forward shading? Is there any other techniques? (Guess so). I think I understand what you say, and it looks like how I thought it would work. However Directional light doesn't affect every object no? The light could be blocked by a wall for exemple.

Yes, light can be blocked by objects like walls, but that's not a problem you want to solve on the CPU as the GPU is much more effective at solving these problems in this situation, you want to use a shadowing technique for that (like shadow mapping, as mentioned).

When I thought I understood, it's absolutly the contrary. So it is NOT my game that decide if I pass the light information to my Shader.

Let's make a simple ASCII exemple so we understand each other It's a scene view from the side

(Light source) (Wall blocking the light) (You facing the arrow direction) (Another wall that shouldn't be impacted by the light source)
O | X ------------------------------------> |

When I prepare to render the last wall, I thought you had to check if "Light source" was block by something, and if not send as a parameter to the Shader. (Let's say it's a light that move, so it's not pre-calculated.)

The way I read what you say, it's all done by the GPU, but how since in the Shaders you don't have all the World objects/light source informations etc...

[Radikalizm]

Seeing your reply I guess you haven't looked up shadow mapping yet, have you? ;)

I'll try to explain it in its simplest form:

Shadow mapping is basically a technique to solve exactly the problem you posed of shaders not knowing everything about the scene they're rendering. What you basically do is you render the scene for each light your want to calculate occlusion for (ie. each light you want to cast shadows for) from the light's point of view (so the light becomes your camera), but instead of rendering all the details of each object you just render out their distance from the light itself, giving you a grayscale texture containing depth values. This is called a shadow map.
Once you have shadow maps for your shadow-casting lights you can fully render your objects from your camera's point of view. You would light everything as usual, but you add one more factor to your lighting equation, which is occlusion. You do this by reprojecting your current pixel's position into light-space and comparing it with the value stored in your shadow map. Based on this comparison you can determine whether the pixel you're rendering should be lit or whether it should be in shadow, effectively giving you the occlusion you were looking for.

[deathwearer]

Seeing your reply I guess you haven't looked up shadow mapping yet, have you? ;)

I'll try to explain it in its simplest form:

Shadow mapping is basically a technique to solve exactly the problem you posed of shaders not knowing everything about the scene they're rendering. What you basically do is you render the scene for each light your want to calculate occlusion for (ie. each light you want to cast shadows for) from the light's point of view (so the light becomes your camera), but instead of rendering all the details of each object you just render out their distance from the light itself, giving you a grayscale texture containing depth values. This is called a shadow map.
Once you have shadow maps for your shadow-casting lights you can fully render your objects from your camera's point of view. You would light everything as usual, but you add one more factor to your lighting equation, which is occlusion. You do this by reprojecting your current pixel's position into light-space and comparing it with the value stored in your shadow map. Based on this comparison you can determine whether the pixel you're rendering should be lit or whether it should be in shadow, effectively giving you the occlusion you were looking for.

No I haven't yet! But I'm still at work and don't really have time for that but I promise I will read about it the whole evening.

This has to be the most clear explanation I'v read on the subject ever. Thank for that. I'v been reading on Shaders for a while already (Many, many article) but these are always demo project and never real world integration (Obviously).

I know how a Specular light is calculated and could (barely) redo it in a Shader but never understood how it would plug in a real game with more than just a mesh in an empty scene...