[Solved] Let there be light

[SupSuper]

I wouldn't worry too much about the accuracy of the light at this point, probably better to move on to more pressing issues first.

Okaydoke, back to textures...

Also there's an SDL function for duplicating surfaces which is probably more efficient than just re-blitting it from scratch.

Ah, even better. I'll be honest, it's been a while since I properly played with SDL (and that was when I was looking to make my own XCOM style game)

Edit: I commited your progress to the SVN. One thing to note, your "s" variable went all the way up to 8 while the array is only 0..7. I increased the array to fix it.

The s variable wasn't in patch 2. Hmmm, maybe I should have made it obvious that they are my patch revision numbers, not that you need to apply them both.

I did only put in patch 2, here's the line:

Code: [Select]

s = (int)(( sin( (curTime * 2 * PI) + ((minLon + maxLon)/2) ) - 1 ) * -4);

[pmprog]

lol, yeah, ignore me 

[pmprog]

Getting ever closer, still need to do the water. I'm also wondering if the south pole polygons are right, as the original seems to have plenty more polys there.

https://www.youtube.com/watch?v=8adPaE0pK1I

[pmprog]

Finished

https://www.youtube.com/watch?v=Hnfhf-6xkM0

[SupSuper]

Getting ever closer, still need to do the water. I'm also wondering if the south pole polygons are right, as the original seems to have plenty more polys there.

https://www.youtube.com/watch?v=8adPaE0pK1I

It should be loaded exactly like the original. It might look different because due to the "spherical projection", the polygons on the poles end up overlapping each other and might come out differently depending on the order they're rendered in.

Finished

https://www.youtube.com/watch?v=Hnfhf-6xkM0

Wow!

I mean, really, wow, I'm glad it works but by now your code looks like nothing more than a huge blob to me.

Some criticism compared to the X-Com lighting:
- The shading between light/dark on the ocean is a lot wider and "unsmooth" than it is in X-Com.
- The shading in the poles seems a bit off, though I suppose they'll always look off. Theoretically, the poles should always be half-lit, and sometimes they seem to be full-lit/non-lit.

Btw, you don't need to declare every variable in the beginning of a block unless you actually plan to use it throughout the whole block.

[pmprog]

It should be loaded exactly like the original. It might look different because due to the "spherical projection", the polygons on the poles end up overlapping each other and might come out differently depending on the order they're rendered in.

I tried reversing the rendering order although I don' remember much difference.

Wow!

I mean, really, wow, I'm glad it works but by now your code looks like nothing more than a huge blob to me.

Do you want me to tidy it up and comment it? It was kinda hack'n'slash last night; I'm not feeling 100% (think I've got a cold or something), so I've been really lethargic.

- The shading between light/dark on the ocean is a lot wider and "unsmooth" than it is in X-Com.

That's pretty easy to tweak, just narrowing the bands will make it look smoother. In fact, I've done this for you in the attached patch

- The shading in the poles seems a bit off, though I suppose they'll always look off. Theoretically, the poles should always be half-lit, and sometimes they seem to be full-lit/non-lit.

This was why I was wondering if we were missing some polygons at the south pole. The North Pole looks okay. I'll be honest, I'm not really sure what else to do with the South Pole.

Btw, you don't need to declare every variable in the beginning of a block unless you actually plan to use it throughout the whole block.

Sorry, force of habit. I've become accustomed to always declaring my variables at the top that I always do it this way, regardless of language

Oh, and if you move the backFace check before doing the 4 polarToCart functions, that'll speed you up a bit  


Edit: Whilst I've refined one light/dark edge, that last patch screwed up the other side; and I don't know why (yet)


Edit 2: Fixed patch (5a), refined gradient more. Although the more you want to refine it, the more performance degradation you're going to get (at least using this algorithm as is)

[SupSuper]

Edit 2: Fixed patch (5a), refined gradient more. Although the more you want to refine it, the more performance degradation you're going to get (at least using this algorithm as is)

I'm guessing you're splitting the map into a huge series of quads and shading each accordingly, which makes sense in a 3D way, but not as much since this is simulated simplified 3D lighting. Most of the ocean will only have one shade.

My approach would be to simplify. At any point, the globe is half-day and half-night (ergo, half-brightest and half-darkest), so render that first:


Then apply the intermediate shades to the edges to smooth the transition:


And that's it. Then you just have to "shift" those polygons along the map according to the time (this should also make the effect look smoother without negative performance issues, as the "light" will actually move along the globe as opposed to just shifting shades in predefined quads). You might need to split them into multiple pieces depending on how you do the clipping (I presume you do clip them at the circle edges), but it should still turn out to be a lot less to render than now. Since the ocean is mostly flat and featureless, we should take advantage of it.

Mind you, I still wouldn't know how to implement this, so I'm just posting in case it gives you ideas to optimize your algorithm.

[pmprog]

Unfortunately, it's not that simple, or at least from my primitive understanding of rotation and translation.

As you can see from this

You can't simply just draw the quad, because you'd effectively get no world.

To counter this, you have to calculate a number of points within the quad to get their 3D world x,y screen points. This gives you a 2D flat map of where you should fill.  This will be much faster than my version, however, this map however does not cater for front/back facing portions, and you will end up painting segments that should be on the hidden part of the sphere over the other.


That said, attached is a patch to speed things up a bit... and an explaination
Draw the circle as previous in either daylight or nighttime colours (nighttime is probably better), then once the sea shade has been calculated, if it is night (or day), skip the drawing of the polygon. This reduces the number of rendering calls made.

I'll be honest, if you're hoping for that really nicely drawn lines like the ones in the original UFO that renders quickly, you're going to need a smarter mathematician than I.

[SupSuper]

Sorry if I wasn't clear enough. I get that you can't just draw a huge quad across the globe. From what I gathered, your algorithm for rendering the ocean basically splits it into teeny tiny pieces and shades it accordingly with the help of a shades array (the images are not accurate, just really crude representations):



(if that's not how it works, then you can ignore the rest of it. )

So the shading is uniform across the map and easy to update. But if you need to make it smoother, you need to make every division smaller, incurring a performance problem:



So my thought was: most of the map is of the same shade (full lit or full dark):



So we take those constant shades, and split them into the biggest quads we can, kinda like you're already doing:



So we have the day/light effect, but the edges look ugly, obviously. But, we don't need to make the shading smoother across the whole map. We just need to smooth the edges. So we'd apply this separate, smaller, smoother in-between polygon shades just on the edges:



Then as time moved on, you could just move those tiny smooth-shaded polygons along as you change the shade on the bigger ones behind like you do now (or a mix, I'm not sure).

That way you could have smooth tiny polygons on the edges without impacting the whole map, because the map isn't this big long gradient. It's mostly the same two colors, with a small smoothing in-between them. Make sense?

If it doesn't then don't worry about, I don't really care too much about how nice or how efficient it is as long as it works. This is just the idea I had when I first thought of lighting the globe and I'd like to know if it actually has some merit.

[pmprog]

You're correct in understanding how it works (well, I no longer render the night sea as polygons as of patch 6), and I see what you are trying to say, but if you reduce the "resolution" of the solid areas by increasing the size of the quads, you will affect the edges of the globe, and that is the area where you really need the def, otherwise you get this


One possible way I can think to speed it up, is after you've calculated the shade, if it's 0 (or you could group all the shades if you wanted too, remember there could be two sets of the intermediary shades), you add it to a "master polygon", and paint the polygon at the end, you would still need to process a refined set of points over the globe though


Edit: Another way to speed it up is to reduce the tmpLon/tmpLat loops to the displayed hemisphere, then you don't even need to check for backfacing.

[SupSuper]

Oh well, don't worry too much about my method then. You can keep on optimizing if you have nothing better to do, but otherwise it's not really worth wasting time on.

Anyways I've committed v6 to SVN so sync up when you can. Sorry for always tweaking your code to match my style, I just like keeping it all consistent.

[pmprog]

Oh well, don't worry too much about my method then. You can keep on optimizing if you have nothing better to do, but otherwise it's not really worth wasting time on.

If I think of a way, I will

Anyways I've committed v6 to SVN so sync up when you can. Sorry for always tweaking your code to match my style, I just like keeping it all consistent.

lol, feel free to modify it any way you see fit