OpenGL API Specifications
Documents and Learning ResourcesSupport Libraries and FrameworksFunction Libraries and GeneratorsThis list contains some basic resources for getting started with, and developing for, OpenGL 3.0 and onwards. Contact your forum moderator if you want to contribute to the list or have any comments.Subscribe to GameDev.net Direct to receive the latest updates and exclusive content.
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.
Posted 19 September 2011 - 10:46 AM
Posted 19 September 2011 - 11:38 AM
Posted 19 September 2011 - 11:50 AM
Posted 19 September 2011 - 11:55 AM
Posted 19 September 2011 - 04:35 PM
Follow my RTS game ICBM
https://twitter.com/dpadam450
http://www.gamedev.net/blog/2202-dpadam450s-journal/
Posted 20 September 2011 - 02:10 AM
Posted 21 September 2011 - 09:34 PM
Posted 22 September 2011 - 03:58 PM
However, as expected, performance is terrible when the number of lights increases, as every light is currently being rendered as a full-screen quad.
Follow my RTS game ICBM
https://twitter.com/dpadam450
http://www.gamedev.net/blog/2202-dpadam450s-journal/
Posted 22 September 2011 - 04:20 PM
What you're describing is using stencil testing, right? Correct me if I'm wrong, but isn't that just another method of doing the same thing as screen-space scissor testing? I don't understand why you would need both. Stencil test would show you exactly where to render based on the "shadow" created by the sphere geometry, but requires an extra pass to render the sphere geometry. Scissor test limits rendering to a particular rectangle on the screen, with no extra pass, but requires some fancy math to calculate the extent of the light on the screen. End result should be roughly the same either way.Drawing spheres as we suggested IS scissor testing. Just draw a sphere, where your light is, and the only pixels that will be be lit are the ones that the sphere projects to on screen.
However, as expected, performance is terrible when the number of lights increases, as every light is currently being rendered as a full-screen quad.
I think you missed the deferred rendering memo. You draw a sphere for each light. When you really need to optimize, you draw portions of your screen with multiple lights at once using scissor tests:
Posted 22 September 2011 - 09:01 PM
I've started trying to read the "Scissor Optimization" chapter from the <a href='http://www.gamasutra.com/view/feature/2942/the_mechanics_of_robust_stencil_.php?page=6' class='bbc_url' title='External link' rel='nofollow external'>Mechanics of Robust Stencil Shadows</a> article on Gamasutra, which deals exactly with the problem I'm having of using scissor regions to limit light rendering. However, I so far haven't been able to follow along very well. The article makes assumptions and pulls in equations that I don't know about, and doesn't really explain what its doing or why the equations are important.<br /><br />I really want to understand the "why" of what I'm doing, and not just copy/paste math equations, so I'm still searching for solutions...<br />
I work on this stuff: The 31st | Tombstone Engine | Foundations of Game Engine Development | Game Engine Gems | OpenGEX
Posted 22 September 2011 - 10:16 PM
I have no doubt that the article is sound, I'm just having a hard time understanding it. For example, it mentions that, in order to calculate the coordinates for the planes bounding the light, the following two equations must be satisfied:That article is self-contained. The only assumptions it makes is that you know what a plane is and what a dot product is, and it does not pull in equations from out of nowhere. If you really want to understand how to calculate the proper scissor rectangle for a light source, then that article is the right place to look.
Posted 22 September 2011 - 10:40 PM
I work on this stuff: The 31st | Tombstone Engine | Foundations of Game Engine Development | Game Engine Gems | OpenGEX
Posted 22 September 2011 - 11:03 PM
Wow... awesome, thank you for that explanation! That is the first I've read of a dot product doing that. I will start through the article again with that in mind.The dot product between a normalized plane and a point gives you the signed perpendicular distance from the point to the plane. The equation T * L = r means that the distance between the tangent plane T and the light position L is equal to the radius r of the light source. The equation Nx^2 + Nz^2 = 1 just means that the normal to the plane is unit length, where we left out the y coordinate because it is known to be zero.
Posted 23 September 2011 - 01:06 AM
No. I think deferred is a bit over your head. In no offense, the reason your not getting a lot of stuff is that your skipping from beginner to advanced with no intermediate.What you're describing is using stencil testing, right?
Follow my RTS game ICBM
https://twitter.com/dpadam450
http://www.gamedev.net/blog/2202-dpadam450s-journal/
Posted 23 September 2011 - 08:23 AM
glm::mat4 view_matrix = camera->GetViewMatrix(); glm::mat4 projection_matrix = camera->GetProjectionMatrix(); glm::vec3 right_vector = glm::normalize(glm::vec3(view_matrix[0][0], view_matrix[1][0], view_matrix[2][0])); glm::vec3 up_vector = glm::normalize(glm::vec3(view_matrix[0][1], view_matrix[1][1], view_matrix[2][1])); for (unsigned int i = 0; i < light_count; i++){ light = lights[i]; glm::vec3 light_position = light->GetPosition(); float light_radius = light->GetRadius(); glm::vec3 right_side = projection_matrix * view_matrix * (light_position + (right_vector * light_radius)); glm::vec3 up_side = projection_matrix * view_matrix * (light_position + (up_vector * light_radius)); float scissor_left, scissor_right, scissor_up, scissor_down; scissor_right = right_side.x; scissor_up = up_side.y; scissor_left = up_side.x - (right_side.x - up_side.x); scissor_down = right_side.y - (up_side.y - right_side.y); }
Posted 23 September 2011 - 09:15 AM
The reason for my confusion is that I've already tried restricting light rendering to small regions of the screen using scissor testing, and achieved better performance. This article on deferred shading uses scissor testing, but never mentions rendering spheres around the light sources. All lights are rendered as fullscreen quads, but the scissor test limits shader execution to the portion of the screen where the light is located.As I said and the whole optimization of what everyone here including you are talking about is: For each light, I dont want to run a pixel shader on pixels that are not affected by the light. How do you do that? Simplest way, know how big of a 3d area in the world your light effects. So draw a sphere in your world, any surfaces that collide with that sphere (use GL_DEPTH_TEST as GL_GREATER), the sphere ("light") will actually be hitting a surface. Since the sphere is drawn right over the screen those are the exact pixels you need to light. So while you draw your sphere, you arent drawing the sphere, you still run your pixel shader and pass the light position etc, but the pixel shader only draws the triangles being sent (The ones from the lights sphere that collide and hit surfaces).
look up some more tutorials, i swear every one i read talked about that. Your scissor test is going to do NOTHING faster than the first method I posted UNLESS you actually figure out and do method 2 and compute lighting in grid regions for each light in 1 pass for multiple lights. Just do the method we told you and ur fine. All you have to do is draw a 3d sphere at the lights position and scale it big enough. If its a small desk lamp draw the sphere like 3 units, a streetlight 50 units etc.
Posted 23 September 2011 - 03:26 PM
Which do you think would be faster, drawing a 16 triangle sphere where each vertex has to be multiplied by a set of matrices?
I'm certainly not opposed to trying the sphere method, as it sounds fairly simple,
Follow my RTS game ICBM
https://twitter.com/dpadam450
http://www.gamedev.net/blog/2202-dpadam450s-journal/
Posted 23 September 2011 - 03:32 PM
Follow my RTS game ICBM
https://twitter.com/dpadam450
http://www.gamedev.net/blog/2202-dpadam450s-journal/
Posted 26 September 2011 - 06:56 AM
Posted 26 September 2011 - 11:00 PM
After this explanation and a bit more reading, I am having a much easier time understanding the math used in the article. The only question I have at this point is more abstract.The dot product between a normalized plane and a point gives you the signed perpendicular distance from the point to the plane. The equation T * L = r means that the distance between the tangent plane T and the light position L is equal to the radius r of the light source. The equation Nx^2 + Nz^2 = 1 just means that the normal to the plane is unit length, where we left out the y coordinate because it is known to be zero.
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.
GameDev.net™, the GameDev.net logo, and GDNet™ are trademarks of GameDev.net, LLC.