|
||||||||||||||||||
Add Forum to Favorites | Send Topic To a Friend | View Forum FAQ | Track this topic |
Last Thread Next Thread ![]() |
| Dynamic 2D Soft Shadows |
|
![]() Cipher3D Member since: 8/12/2001 From: Irvine, CA, United States |
||||
|
|
||||
| Great article! One i'm going to read for years to come However, I am a noob and some of the things I don't get...but...I'll get it eventually. I'm making a 2d shooter, and I'm rendering it using ortho mode, so I'm not sure how I'll implement these lights if they are dependent on the depth buffer. Anyways, to reiterate myself, "Great Article" :-P. |
||||
|
||||
![]() krez GDNet+ Member since: 10/10/2001 From: NJ - The Garbage State |
||||
|
|
||||
| wow. that is sooooo much cooler than what i was working on recently (lighting in a 2D game). |
||||
|
||||
![]() Cipher3D Member since: 8/12/2001 From: Irvine, CA, United States |
||||
|
|
||||
| Yeah I was considering using lightmaps (????) to do lighting effects in my game, but there was the problem of clipping them to irregular-angled walls, this is a good method. The problem is, i'm using sprites and not square objects or objects with 10 or less vertices...maybe i'll generate a vertex list in real time based on outlining the pixels in the sprite? hm...what should i do???? can u post some code too? i would like to see the convex hull implementation thingy ma jigger [edited by - Cipher3D on January 4, 2004 7:07:35 PM] |
||||
|
||||
![]() joelmartinez Member since: 1/15/2003 From: Orlando, FL, United States |
||||
|
|
||||
| Looks great ... good to see some good ol' 2D stuff still floating around. That last sample reminds me of a Soldat level ... that game rocks! Joel Martinez http://www.codecube.net/ |
||||
|
||||
![]() aftermath Banned Member since: 3/9/2001 |
||||
|
||||
| Great article, my hat goes off to you! I have always wanted to know how to do this. Funny thing is, I thught that dynamic and soft shadows need a lot of CPU power to generate without slow framerate - I dont know why, maybe because I have always thaught about software rendering shadows (like in demos.) Good job anyway. Next time I need to know how to implement these, I will know where to look. |
||||
|
||||
![]() vrihai Member since: 7/19/2002 |
||||
|
|
||||
| This is so cool! Wonder why no one came up with something like this before.. |
||||
|
||||
![]() Pipo DeClown Member since: 2/16/2002 From: Amsterdam, Netherlands |
||||
|
|
||||
| I-WANT-A-DEMO-NOW!! -- You're Welcome, Rick Wong - sitting in his chair doing the most time-consuming thing.. |
||||
|
||||
![]() OrangyTang GDNet+ Member since: 3/19/2002 From: London, United Kingdom |
||||
|
|
||||
| Thanks for all the comments. I've a few things to add (optimisations and tweeks) but I'm in a rush, so I'll just point you at a thread of mine where you can play a small demo which has this system working in it. ”We hate to see a corporation of this country promote the U.N. when we know that it is an instrument of the Soviet Communist conspiracy.” —San Francisco Chronicle |
||||
|
||||
![]() OrangyTang GDNet+ Member since: 3/19/2002 From: London, United Kingdom |
||||
|
|
||||
| Various little snippits that people may find handy: - I use a full screen quad to clear the alpha component of the framebuffer between lights. Being lazy I originally set this to +/-Float.MAX_FLOAT and it worked fine. However I later found that some graphics cards or drivers really don't like this and tend to screw up pretty badly (particularly ATi cards, TNT cards and every single Mac system I tried it on). Its easy enough to just calculate the proper coords to surround the camera, or tinker with the view matrix but its something to be aware of. - A great optimisation is using the scissor test to reject fragments outside of the current lights range. The scissor rectangle gets set to tightly fit around the light at the beginning of the lights rendering and stays set until the next light is set or the frame is finished. Since no fragments outside the lights range need to be changed this gives identical results but can hugely reduce the number of fragments needed to be processed by the graphics card. - The article doesn't cover the case when a light intersects an object. At first I didn't expect this to be a problem, yet in a proper game it happens often and breaks shadow generation because of several assumptions made. My current solution is to detect when an object is getting close to a light and fade the entire light out the nearer it gets (via a full screen shadow quad). However if you've played S-Type you'll notice this seems a little odd at times. A better idea would be to fade the intensity of the shadow out at close range. This shouldn't be too difficult (just manipulation of the shadows vertex colours and the fins texture coords) but what with one thing and another I havn't got round to it yet. |
||||
|
||||
![]() Anonymous Poster |
||||
|
||||
| "Also note the line of white pixels along the right side, this prevents blending artefacts along the vertical edge" Why not just set the wrapping mode to clamp? |
||||
|
||||
![]() OrangyTang GDNet+ Member since: 3/19/2002 From: London, United Kingdom |
||||
|
|
||||
quote: 1. Because I'm lazy, and don't like changing rendering states when I can solve it this way. 2. Because different drivers keep surprising me with various ways of behaving with texture clamping, and I get fed up telling people to upgrade their drivers constantly. Feel free to use clamping though, its probably just a personal phobia. |
||||
|
||||
![]() BlabberBoy [disabled] Member since: 8/18/2000 From: Canada |
||||
|
|
||||
| Awesome tutorial, but I'm having a bit of a problem... I'm working on the hard shadows right now, using C++ and OpenGL. What's happening is that when two convex hulls are overlapping at the same depth (z coordinate), they blend together like so: http://punkhectic.tripod.com/overlap.JPG As you can see, where the red and blue rectangles overlap, they blend together to make pinkish... It's almost as though the alpha channel is not being updated when I draw the rectangles even though I've made sure alpha writing is enabled, and I'm passing 1.0 as my alpha value in glColor4f... Anyways, is there something I might not be doing properly, or am I just going to have to give everything that might overlap separate depth values? EDIT: stupid tripod and their non-remote linking things... [edited by - BlabberBoy on March 22, 2004 10:46:18 PM] |
||||
|
||||
![]() phibermon Member since: 6/18/2005 From: Cannock, United Kingdom |
||||
|
|
||||
| Hello All. I've developed a working implementation of this method in Object Pascal (Free Pascal) if anyone is stuck following this article or just want to check out my dirty code then PM me. Awesome tutorial! Thanks. |
||||
|
||||
![]() LonelyStar Member since: 12/2/2002 From: Heidelberg, Germany |
||||
|
|
||||
| Firstly: Great article! Thanks a lot! I have a question: What if I have sprites (non-quadratic) and uses blending for nicely antialsing them (glBlendFunc(GL_SRC_ALPHA,GL_ONE_MINUS_SRC_ALPHA)) and blending them out. Then I have a problem whith this shadow technique, because the areas behind half-transparent areas are not lightned correctly, right? Is there a sollution to this problem? |
||||
|
||||
![]() Anonymous Poster |
||||
|
||||
Great article! I did something vaguely similar for one of my programs. I have a few thoughts to add. (BUT I'm a bit new to openGL so keep that in mind for the rest of this post..) One thing you don't seem to note is that when drawing the penumbra, you should set glBlendFunc(GL_ZERO, GL_SRC_ALPHA) (unless you found something different??) Another thing I tried when developing my program was by using glBlendEquation(GL_FUNC_REVERSE_SUBTRACT) (by extension only) with glBlendFunc(GL_ONE,GL_ONE) to subtract the shadow alpha from the alpha value in the framebuffer. It worked too, though it is a bit messier (more state changes necessary). It actually yeilds a different result: It is an additive shadow, while the article's method is multiplicative shadow (assuming you use glBlendFunc(GL_ZERO, GL_SRC_ALPHA) as mentioned above). I think the additive way is slightly more physically realistic, but it a bit messier and the difference is barely visible. In fact I have a feeling the multiplicative shadow looks better. Anyway, nice article. I found something to add to my program as well! Thanks! -A (PS. why didn't you use glClear to clear the alpha channel instead of the full-screen quad? Is it faster your way? I didn't see anything about this with a quick google search) (PPS Hey, I've seen you on the java forums! though sadly I am using C++) |
||||
|
||||
![]() Anonymous Poster |
||||
|
||||
| Excellent tutorial! I'm curious if you have released your code anywhere? Even though you spell out your method here, I'm under the idea of "why reinvent the wheel" if it's already around. I could certainly write this myself, but it would take a while and I wouldn't be object to just throwing someone else's code into my program. |
||||
|
||||
![]() pyr0kar Member since: 11/21/2006 From: Karlsruhe, Germany |
||||
|
|
||||
| Some reference source code would be so nice :/ I guess i won't succeed in implementing this until i have some code to look at. nice article though. |
||||
|
||||
All times are ET (US)![]() |
Last Thread Next Thread ![]() |
|