 |
|
|
|
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|||||||||||||||||
Add Forum to Favorites | Send Topic To a Friend | View Forum FAQ | Track this topic |
Last Thread Next Thread |
| 'Slope Lighting' Terrain |
|
 |
Anonymous Poster |
|||
 Posted - 7/9/2001 12:16:50 PM |
||||
| wont this crash in the first iteration of the loop when either x or y == 0. Because you reference maptile[x-1][y-1] on the first line in your loop. |
||||
|
||||
|
Dog_Food Member since: 5/30/2001 |
|||
|
Posted - 7/9/2001 3:33:35 PM |
||||
| I came up with something like that about 4 years ago. Instead of precomputing the lighting, it is feasible to do it on the fly. This allows the light source vector to be taken into acount. A square lookup table can be used which has cosine computed for distance from center. Represented with grayscale, the lookup table would look like a softly shaded circle. The center is whitest. The delta for the heightmap height difference in the horizontal and vertical direction can be used to offset from the center of the lookup table. Also, the light vector direction can be used to offset the position in the lookup table. This produces very realistic, quick dynamic shading. If anyone wants more explanation, email me. |
||||
|
||||
 |
benjamin bunny GDNet+ Member since: 11/26/1999 From: Norwich, England |
|||
|
Posted - 7/9/2001 4:32:13 PM |
||||
| What's wrong with just calculating face normals? |
||||
|
||||
|
Dog_Food Member since: 5/30/2001 |
|||
|
Posted - 7/9/2001 4:50:16 PM |
||||
| This should be much faster than traditional lighting (in software), also this allows dynamic terrain without recalculating normals. But you are right, face normals are way to go on modern hardware. |
||||
|
||||
|
LoreKeeper Member since: 6/11/2000 From: Stellenbosch, South Africa |
|||
|
Posted - 7/11/2001 10:36:28 AM |
||||
| Instead of doing the calculation as you suggest, it is more accurate and more versatile to use a simple 2D bump-mapping procedure (or embossing procedure) to generate the light-map on the fly. You don't need the hyper-powerful bumpmap procedures found in painting packages, just a straightforward version will do. I've implemented a good embossing procedure at some stage that allows any angle of light to be cast onto an image. That way you get around the 45 degree issue. If you're not sure where to start... look-up on per-pixel-based bumpmapping or embossing - itZ actually very very simple. Works like a charm...  On optimized (assembler) procedure is certainly fast enough to use in real-time per-frame... but a simple high-level procedure is fast enough to use as well, since the lighting only needs to be re-calculated every 15 - 30min in-game-time. Henri aka A-Lore |
||||
|
||||
|
ProgramMax Member since: 3/26/2000 From: Ohio, USA |
|||
|
Posted - 7/14/2001 3:36:28 AM |
||||
| Perhaps I missed it, but I don't see anywhere in there where the sun's angle is calculated in. It looks like a random hill would be shaded on all sides. This is just from glansing at the code and not testing it or what not. Anyway, is there a way to compute the lighting every scene so that I could put in the location of my sun (which moves) as well as other lights we will use and get out some accurate and pretty lighting? If so, is there anyway we could put the T&L engine to use on this or is that not going to work? I am still kinda learning. Please email me some info if you could. Thanks! |
||||
|
||||
|
Thr33d Member since: 6/24/2000 From: Portland, OR, United States |
|||
|
Posted - 7/25/2001 7:29:30 PM |
||||
| Hey, one more note, you can cast shadows in a similar fashion, I hope this will help some peoples: (Please note, it's in VB (my native tounge) hopefully it won't be too hard to convert to c, if someone can do so, feel free to post the conversion, thanks) ----------------------
Dim sh As Integer 'Current Shadow Height
Dim x as Integer, y as Integer 'Looping Variables
Const MAP_RES as Integer = 128
Const SunHeight as Integer = 1 'Sun Slope Value, in this case, slope of 1, 45 degrees
For y = 0 To MAP_RES
sh = 0
For x = 0 To MAP_RES 'Flip this around to cast from the right, or switch order of For loops to cast from north or south
If sh < Heightmap(x, y) Then 'Terrain higher than current shadow height
Shadowmap(x, y) = 1 'Fullbright
sh = Heightmap(x, y) 'Cast shadow from current terrain height
Else
Shadowmap(x, y) = 0 'Shadowed
End If
sh = sh - SunHeight
Next x
Next y
------------------------------- As I said before, I hope this is helpful to someone(s)  if so, please tell me, if it's already been beaten to death before, again, please tell me!Thanks all, -Michael Edited by - thr33d on July 25, 2001 7:37:02 PM |
||||
|
||||
|
d000hg Member since: 1/21/2002 From: Durham, United Kingdom |
|||
|
Posted - 2/21/2003 6:53:11 AM |
||||
| You don't want to generate face normals on the fly becuase of having to lots of sqrts. For a 2d grid of vertices all the vector stuff (cross-products etc) reduces to like 2 multiplies and 3/4 adds but its the sqrt which kills you! Read about my game, project #1 NEW (18th December)2 new screenshots, one from the engine and one from the level editor John 3:16 |
||||
|
||||
|
Chaucer Member since: 7/12/2002 |
|||
|
Posted - 3/25/2003 3:03:00 AM |
||||
| So do the floating point values that are caluclated here used to modify the color of the vertex? How is the lightmap actually applied? |
||||
|
||||
|
RAZORUNREAL Member since: 1/18/2004 From: Auckland, New Zealand |
|||
 Posted - 1/19/2004 12:45:08 AM |
||||
| This is great. As far as I can tell this will give me the complete dynamic vertex lighting for terrain solution. From what I can see, if you halve the performance, it's not even limited to 45deg (correct me if I'm wrong). Just look through the terrain using a good line algorithm (good so you dont miss any) in the direction the sun is pointing (atarting from all the vertices along the 2 closest edges to the sun), for every vertice you come across you look at the 2 heights in the sun direction, and for each of them multiply by the x or z of the suns direction respectively. Thats if they pass the shadow test (the way I came up with is very similar to the one mentioned above I think, though I didn't read it very carefully). Edit: I found that this doesn't actually light the terrain accurately, so I'm developing a method that does. Heres my aim, ambitios as it may be (I've got a bit working though, as far as I can see it's possible): To light terrain from almost any angle with it looking like proper diffuse (yes, looking like, not actually the real thing, but close) completely dynamicly, with shadows. I think I've already beaten this method. I'll be writing an article on it soon. [edited by - RAZORUNREAL on January 21, 2004 5:28:36 AM] [edited by - RAZORUNREAL on January 27, 2004 6:19:40 AM] |
||||
|
||||
|
dawidjoubert Member since: 1/28/2004 From: London, United Kingdom |
|||
|
Posted - 12/14/2005 2:14:17 PM |
||||
| I tried to send you an email but nooo u changed ur addy.. any ways here is me email. Hi there, I read your article and tried out your idea, i have attatched a link for the download if you would like to see it for yourself. You are free to put it up with the tutorial as a demo however it is part of a larger project and thus i cannot provide you with source.. Im sorry. Anyways, for credits my name is Dawid Joubert and my webpage is www.geocities.com/DJSpy187/ at www.geocities.com/DJSpy187/stretch.zip NOW: Lets discuss whats wrong with this method of lighting. Although the terrain looks nice from far away artifacts can be seen close up due to the fact that the terrain in essense is a 2d bitmap Array heightmap. [Image]http://www.geocities.com/djspy187/temp.jpg[\Image]  These artifacts are less notice able from far  (64x64 Tiles, with a tesselation of about 30 000 Quads) Now the one method of solving this problem is by applying some gausian blur to the 2d array that is create (in my case light[x][y]). I will try this now, expect to here from me soon! Regards Dawid Joubert ----------------------------------- EDIT Okay so i applied a double filter box thats a 3x3 filter twice (it would be nice to try a 9x9 but i dont have that much time). I has been appended to the download. Regards [Edited by - dawidjoubert on December 14, 2005 2:14:09 PM] ---------------------------- http://djoubert.co.uk |
||||
|
||||
|
dawidjoubert Member since: 1/28/2004 From: London, United Kingdom |
|||
|
Posted - 12/14/2005 2:22:47 PM |
||||
| I thought about it a bit: I have approx 1048576 tiles in my engine! Because the sun in a game is considered to move slowly you only need to update 250 tiles per frame, at 85fps, to change the sun's direction every minute. Now if the sun changes at a rate of 2 Degrees per minute then this is acceptable, (Provided that you use directional light). Thats 2 Additions & 1 multiple + 2 IF Checks per tile, results in 500 adds+ 250 mults + 500 checks. This isnt much if you compare it to cross & sqrt stuffies. Further you only need to update on screen tiles which on average on my engine will be 13 000. So it should be possible for this to be real time without much speed loss. The problem still lies in the fact that you will need filtering otherwise the shadows will look blocky! ---------------------------- http://djoubert.co.uk |
||||
|
||||
|
dawidjoubert Member since: 1/28/2004 From: London, United Kingdom |
|||
|
Posted - 12/16/2005 1:33:31 PM |
||||
| Progy update, it still uses slop lighting but now it also uses multitexturing for the terrain. Get it here if you wanna see www.geocities.com/djspy187/Stretch.zip *Same file just appended another .exe ---------------------------- http://djoubert.co.uk |
||||
|
||||
| All times are ET (US) |
Last Thread Next Thread |
|
