Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. Game Development
  4. How are shadows computed with a basic(non realism) lighting?
Forum Updated to NodeBB v4.3 + New Features

How are shadows computed with a basic(non realism) lighting?

Scheduled Pinned Locked Moved Solved Game Development
4 Posts 2 Posters 898 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • D Offline
    D Offline
    DaShubWubDub
    wrote on last edited by DaShubWubDub
    #1

    Hey everyone,
    I wrote a shader and was wondering how shadows are determined; The closer the to the light position that the vertex is then it mixes brighter with a white color.

    my question is if this shader is applied to a cube on top of a ground which is a square, how would I compute shadows? It isn’t clear within other shader code how shadows know where to appear. My only thought is enabling all required vertex by executing the bind function to all the vaos. Then that gives the graphics card a “collision data” for raytracing(function) to determine if light or shadows should appear.

    Note: I’m not finished with this shader; this shader is only applied to any vertice that is within “1” distance.

    
    "#version 330\n"
            "in vec4 color;\n"
    				"in vec4 vertex_position;\n"
    				"float light_intensity_factor(in float light_source_distance)\n"
    				"{\n"
    				"	float result = 0.0;\n"
    				"	if((light_source_distance * 1000000) < (1.0 * 1000000))\n"
    				"	{\n"
    				"		float initial_intensity = 0.1;\n"
    				"		result = initial_intensity - (initial_intensity * light_source_distance);\n"
    			  "	}\n"
    				"	return result;\n"
    				"}\n"
    				
            "void main( void )\n"
            "{\n"
    				"vec4 light_color = vec4(1.0, 1.0, 1.0, 1.0);\n"
    				"vec3 light_position = vec3(0.0, 1.0, 0.0);\n"
    				"float light_distance = distance(vertex_position, vec4(light_position, 1.0));\n"
    				"float light_intensity = light_intensity_factor(light_distance);\n"
    				"vec4 mixed_color = mix(light_color, color, 0.7);\n"
            " gl_FragColor = mixed_color;  //vec4(color.x * light_distance, color.y * light_distance, color.z, 1.0);;\n"
            "}\n";
    
    
    1 Reply Last reply
    0
    • D Offline
      D Offline
      DaShubWubDub
      wrote on last edited by DaShubWubDub
      #2

      One piece of the proverbial puzzle has been discovered, according to this tutorial they are saying execute draw calls with “gl_nodraw” to produce the shadow maps then draw normally, hinting at binding everything in order to allow for ray tracing. The tutorial didn’t make it clear if shadow mapping was intended for real time shadow updates or if all objects computed with the map had to be stationary for the computed shadows in order to visually “make sense”.

      https://learnopengl.com/Advanced-Lighting/Shadows/Shadow-Mapping

      1 Reply Last reply
      0
      • D Offline
        D Offline
        DaShubWubDub
        wrote on last edited by
        #3

        So it seems although this article doesn’t discover how raytracing is done when seen in places like shadertoy; However, effects like bloom are accomplished using a frame buffer to proverbially and literally save progress which can be mixed together within the final frame.

        I will be using this technique to create shadows, instead of color data, it would be instead store how many lights(and how far away) collided, then during normal drawcalls input that information into the shader. Assuming I can use structures and framebuffers(and or uniform storage buffers).

        https://learnopengl.com/Advanced-Lighting/Bloom

        1 Reply Last reply
        0
        • Chris KawaC Online
          Chris KawaC Online
          Chris Kawa
          Lifetime Qt Champion
          wrote on last edited by
          #4

          That last one -bloom is a postprocess effect and it has nothing to do with shadows. Also there's no raytracing involved in the shadow technique described in the previous link.

          In the shadow-mapping technique described there you render the scene multiple times.
          For each light you set up a model-view-projection matrix to match the light source point of view i.e. you render the scene from the position and direction of your spotlight, so that it's a circle that fills the framebuffer. Each light gets its own depth buffer like that. You don't need a color buffer in that pass, only the depth information is what's of interest here. This basically "encodes" the distance of each object to each light in the depth buffer. That depth buffer is called a shadowmap.

          Then, in the second pass, you bind these shadowmaps as input and when you draw your scene to the actual framebuffer you reproject the 3d position of the pixel you're currently drawing to the light space coordinates and compare the resulting depth value with that in the shadowmap. If it's smaller then pixel is in the direct light. If it's larger it's in the shadow.

          For the shadowmap you use a square depth texture and as for the size of it games usually have shadow quality preset for that e.g. low/medium/high. The bigger the texture the less jaggy the shadows will be but also it's gonna be slower because there's more depth information to write. Games usually use shadowmaps somewhere in the range 512x512 to 2048x2048 (remember that power of two sized textures are much faster on the GPU). Some types of games can get away with smaller ones, but you have to experiment what looks good for you.

          As for when are the shadowmaps rendered - it depends. If your scene is static and your lights don't move you can render them once at the start and reuse. If you want the lights to move or have moving objects in the scene you'll need to re-render shadowmaps more often.

          Games usually do multiple different optimizations to make the shadowmaps rendering less costly. First of all limit the maximum number of dynamic light sources i.e. render shadows only for a couple of the closest lights. Detect if anything in the light cone changed (i.e. something moved into or out of the light cone) and only re-render that shadowmap then. Limit the amount of moving lights. Render only the most important objects into the shadowmaps and don't include those that contribute little to the whole image.
          But these are optimizations for later. For starters I suggest to try and do a single closest light shadowmap and render whole scene to it so you can learn how to do it.

          1 Reply Last reply
          1

          • Login

          • Login or register to search.
          • First post
            Last post
          0
          • Categories
          • Recent
          • Tags
          • Popular
          • Users
          • Groups
          • Search
          • Get Qt Extensions
          • Unsolved