OpenXcom Forum
Contributions => Programming => Topic started by: Volutar on January 26, 2011, 04:34:09 pm
-
It's a first patch from me.
Conjuction point of poles have had some issues with shading because of all vertexts used for shade estimation.
This patch make shading function skip pole vertexes since they dont have actual longitude.
Also I'm aiming to make world.map patch for more detailed poles and other rough terrain locations, for better lighting.
Method - make world.dat->world.obj exporter and world.obj->world.dat importer. And use any obj editor to fix some details.
-
North pole vertex shared only by 3 polygons, so it's not strange it looks ugly.
As I see for the moment lighting calculated for bounding squares for each polygon.
I don't think it's good approach, since bounding squares could be heavily overlapped and lighting could look ugly. I'll try to use polygon middlepoint and will see how it come.
-
Is that world viewer application (shown above) available for download (and play with?)
-
Sure, but it's just a viewer. It doesn't allow to change anything...
Here (https://volutar.eu5.org/worlddat.zip)
-
Nice.
Did you write that? If you don't mind me asking...what was it written in?
Do the coloured terrain polygons simply map (spatially) over a blue globe?
-
In Delphi7.
Yep. Blue circle/rectangle (depending on mode) + colored polygons.
-
I've slightly updated my viewer by adding "site" display functionality (you can select particular area in the second list at right side, current area marked as red, whole site as pink; displayed as X.Y.Z where X is zone, Y is stage and Z is location).
In short: xcom uses list of "random" areas (720 entries, file randomsites.dat: {shortint x,y,width,height}).
Alien activity divided upto 12 earth zones (described in ufopaedia (https://www.ufopaedia.org/index.php?title=ZONAL.DAT)).
These 60 areas divided to 6 "stages" so every stage have only up to 10 locations. These stages used for UFO trajectory calculation.
For example, research mission. They've scripted 3 levels of progression.
<ct_SmallScout, 1, 0, 300>
<ct_MediumScout, 1, 2, 260>
<ct_LargeScout, 2, 4, 300>
Values are: CraftType, NumberOfUFOs, Trajectory_Type, Timeout.
So they're using trajectory_types 0,2 and 4.
0:
dw 5 ; UFO_Waypoint_count
dw 5, 0, 0, 1, 5, -1, -1, -1; UFO_Waypoint_Site
dw 4, 3, 1, 1, 2, 0, 0, 0; UFO_Waypoint_Altitude
dw 100, 74, 28, 47,100, 0, 0, 0; UFO_Waypoint_Speed
dw 3000 ; Ground_Timer
2:
dw 5 ; UFO_Waypoint_count
dw 5, 0, 0, 1, 5, -1, -1, -1; UFO_Waypoint_Site
dw 4, 3, 2, 1, 0, 0, 0, 0; UFO_Waypoint_Altitude
dw 100, 57, 26, 50,100, 0, 0, 0; UFO_Waypoint_Speed
dw 5000 ; Ground_Timer
4:
dw 8 ; UFO_Waypoint_count
dw 5, 0, 0, 2, 0, 0, 2, 5; UFO_Waypoint_Site
dw 4, 2, 2, 1, 0, 2, 1, 0; UFO_Waypoint_Altitude
dw 100, 67, 52, 40, 30, 20, 30,100; UFO_Waypoint_Speed
dw 7000 ; Ground_Timer
So obviously UFOs starting at site5 and "lost track" through site5.
site0 often covers whole land area, while site2 is located at number of really narrow areas over land, and site1 is something between site0 and site1 (you can watch them through selecting area in viewer).
When UFO is moving towards next waypoint, it has fixed altitude and speed. When it reaches next waypoint, it "calculates" where's it want to fly next (it peeks random location from next Zone->Stage area set). Altitude==0 means ground level, when it reaches this point, it landed, and turned into green cross, which will stay there for around Ground_Timer*5secs.
P.S.: Site3 is often a CITY layer, with area width==0 and height==0, and this location chunks used when starting terror missions.
-
For example, research mission. They've scripted 3 levels of progression.
<ct_SmallScout, 1, 0, 300>
<ct_MediumScout, 1, 2, 260>
<ct_LargeScout, 2, 4, 300>
Values are: CraftType, NumberOfUFOs, Trajectory_Type, Timeout.
So they're using trajectory_types 0,2 and 4.
0:
dw 5 ; UFO_Waypoint_count
dw 5, 0, 0, 1, 5, -1, -1, -1; UFO_Waypoint_Site
dw 4, 3, 1, 1, 2, 0, 0, 0; UFO_Waypoint_Altitude
dw 100, 74, 28, 47, 100, 0, 0, 0; UFO_Waypoint_Speed
dw 3000 ; Ground_Timer
2:
dw 5 ; UFO_Waypoint_count
dw 5, 0, 0, 1, 5, -1, -1, -1; UFO_Waypoint_Site
dw 4, 3, 2, 1, 0, 0, 0, 0; UFO_Waypoint_Altitude
dw 100, 57, 26, 50, 100, 0, 0, 0; UFO_Waypoint_Speed
dw 5000 ; Ground_Timer
4:
dw 8 ; UFO_Waypoint_count
dw 5, 0, 0, 2, 0, 0, 2, 5; UFO_Waypoint_Site
dw 4, 2, 2, 1, 0, 2, 1, 0; UFO_Waypoint_Altitude
dw 100, 67, 52, 40, 30, 20, 30, 100; UFO_Waypoint_Speed
dw 7000 ; Ground_Timer
Found the numbers interesting, so I thought I'd help make them a tiny bit more reable :)
Keep up the good work!
-
I've found formulas of direction vector toward particular alt/long globe location. So folowing this direction each "tick" you will get to destination point by shortest distance (along great cirle).
It is also possible to use it for drawing globe route to destination point.
x:=sin(long2-long1)*cos(lat2);
y:=cos(lat1)*sin(lat2)-sin(lat1)*cos(lat2)*cos(long2-long1);
1 is source coordinate, and 2 is destination
latitude is 0 at equator, -pi at north pole and +pi at south pole
This vector (x,y) is not normalized, so it become almost 0 near target location and on the other side of globe (thus it should be normalized).
I think there might be some problems when passing pole (latitude near +-180 degrees), it requires some tests
-
Formula above works well.
Another thing needed for proper globe path tracing is longitude scaling (according latitude) of vector:
new_long_offset/=cos(new_lat);
-
Viewer application (https://volutar.eu5.org/worlddat.zip) updated and uploaded.
Now it draws "shortest path" in 2D and 3D and can reassign destination location by left mouse click. Trajectory start location is in Siberia Middle click will set source location. You can see how strange "shortest path" may look in 2D.
-
is possible to use different cord for poles?
if points on patch are too close pole, you change your cord to {x,y,z} and you simple create line from one point to another. after that you can go back to 2d cords or to alt/long.
-
Why should we use different coord for poles?
-
because your patch get crazy when you set it though poles. if we would use different cords we could have straight patch there.
-
My patch? do you mean this patch of near-pole lighting correction or what?
Jumping of trajectory near pole is a side-effect of having trajectory granularity of 111km "jumps".
-
My patch? do you mean this patch of near-pole lighting correction or what?
Jumping of trajectory near pole is a side-effect of having trajectory granularity of 111km "jumps".
He means path. :P
-
yes :D 1 `t` made no difference :D
-
I should start spamming here, not in `Android port` (its because my code cant be ported to Java :D ) and this topic is about improving globe :D
I made progress on my globe shadowing. its still `work in progress` but on full zoom out work in 100% without any glitches.
I can use it to shading lands too, this could fix some bugs from current version.
this method have some drawback. I loose around 20 fps form 140 and increase memory usage (but this is `static` memory, allocate only once).
[ps]
my github fork is updated, if someone want see my ugly code, can do it now :)
I need some refactoring to merge it with current OpenXcom.
-
Yankes, looks very nice.
I suggest you to post globe in lesser resolution (640x400 is enough). And post some "whole-earth" shaded shots (with land shaded same way as ocean).
-
Looking good. Can't wait to see it in the official builds.
Keep it up!
-
Sure is looking pretty, hopefully the code won't ruin the illusion. ;)
-
ok I finished it :)
now work with every zoom level and shading lands too.
when i get some free time I will move my code to current version of xcom.
[ps]
btw is possible to made this shadow to behave as real one (aka polars days and nights)
-
new complicity useless feature! we can have polar night! :D
btw who want fix now Battlescape? because now it can have wrong brightness on battlefield :)
[ps]
I indeed buged battlescape :D now it crash in my build :D
-
new complicity useless feature! we can have polar night! :D
Useless indeed, but I won't mind having it in an "openxcom custom settings" page somewhere. Good job.
Does it behave like the real deal? Meaning that at the poles it's slowly drifting between night and day over the course of six months?
-
new complicity useless feature! we can have polar night! :D
I don't think so. :) Your job is really great!
-
Yankes, very nice. Polar nights is realistic, and could be a gameplay feature, but actually will look ugly when globe is rotating.
About time-fixing for battlescape... Yankes, can you shrink or enlarge terminator semishaded area width? Or it's hardcoded?
PS. Btw, if you have per-pixel calculations, you may use something like dithering, to make shading smoother.
-
Useless indeed, but I won't mind having it in an "openxcom custom settings" page somewhere. Good job.
Does it behave like the real deal? Meaning that at the poles it's slowly drifting between night and day over the course of six months?
yes, if you switch to 1day speed you will see moving shadow :)
Yankes, very nice. Polar nights is realistic, and could be a gameplay feature, but actually will look ugly when globe is rotating.
About time-fixing for battlescape... Yankes, can you shrink or enlarge terminator semishaded area width? Or it's hardcoded?
PS. Btw, if you have per-pixel calculations, you may use something like dithering, to make shading smoother.
yes I can easy change size of transition without any problems, its one number per zoom level, it can be easy any number.
smoother? I think better is made palette smoother, I made 32 strips of different shadow values, but I get strips anyway.
-
smoother? I think better is made palette smoother, I made 32 strips of different shadow values, but I get strips anyway.
Oh, if you draw them by strips, it doesn't matter.. Only per-pixel manipulation allow "dithering" technique.
Battlescape light intensivity can easily be taken from terminator position. Though you can keep old one.
BTW at north and south poles there always be dim light :) (Because XCOM Earth doesn't have inclanation angle).
P.S.: Pole "hard" terminator line bug will be vanished with this shading used for whole globe...
-
new complicity useless feature! we can have polar night! :D
btw who want fix now Battlescape? because now it can have wrong brightness on battlefield :)
[ps]
I indeed buged battlescape :D now it crash in my build :D
Battlescape gets the light shade from the polygon the mission is on through Globe::getShade, if your shading is no longer polygon-based you probably have to rewrite the code to get the light shade off a specific lon/lat position.
-
Oh, if you draw them by strips, it doesn't matter.. Only per-pixel manipulation allow "dithering" technique.
Battlescape light intensivity can easily be taken from terminator position. Though you can keep old one.
BTW at north and south poles there always be dim light :) (Because XCOM Earth doesn't have inclanation angle).
P.S.: Pole "hard" terminator line bug will be vanished with this shading used for whole globe...
I probably didnt say this clearly. I get this stripes from per-pixel manipulation. I dont draw them directly.
I tried add some sort of dithering by some random values but effects wasnt good enough. My system have one limitation, I cant get any information about pixels around current one. I have some ideas how to get effect similar to dithering but now I dont have time to implements it.
-
you probably have to rewrite the code to get the light shade off a specific lon/lat position.
Getting the shade from the polygon was actually a quick and easy method I used back in those days and is not really the way to do it. It was just waiting to be broken one day.
If I can believe ufopaedia, the original game calculates the local time for the given position, and with a lookup table converts the time of day into the battlescapes' brightness. 6:30-16:30 is full light, 19:00-4:00 is full dark, and something in between for morning and evening hours.
Source: https://www.ufopaedia.org/index.php?title=BGLOB.DAT
I will fix this in the master branch.
-
Yankes, that would not be a problem. If you build shade pattern via pixel manipulation, dithering could be easily achieved. Floyd-Steinberg (https://en.wikipedia.org/wiki/Floyd%E2%80%93Steinberg_dithering) will be fine.
Daiky, yeah, but XCOM used bad shade formula. They haven't payed any attention on the fact, that at the pole point there will always be twilight, because it's always at terminator line. And anyway, it would be real advantage over original, if battlescape shading will be 100% appropriate for shadng observed at globescape.
-
Well... I agree that the shading on the globe must match the one on the battlescape exactly, I do it often, waiting for site to appear in daylight and then land, it would be frustrating if the two don't match. With the polygon check there is now, it is always 100% correct...
I'll let it be as it is for now, until the globe is not officially changed, the polygon check works. There are more important things, like for example "the medikit" to implement first :)
-
to get correct shade in battlescape we only need 2 things.
a) normed position of landing site in 3D cords
b) normed vector pointing to sun
now we can easy calculate it by:
if(norm(landing_pos - sun_direction)> sqrt(2))
night();
else
day();
this is simplest version, more accurate can have more tests.
Yankes, that would not be a problem. If you build shade pattern via pixel manipulation, dithering could be easily achieved. Floyd-Steinberg (https://en.wikipedia.org/wiki/Floyd%E2%80%93Steinberg_dithering) will be fine.
this will not work, simple because `find_closest_palette_color(oldpixel)` is always equal 0 in my case. I create 32 shades values and I convert them to 32 colors of ocean (in case of lands its 16 colors). Creating more shades is very costly. I could reduce numbers colors of ocean to 16 and then use it but i dont know if effect will be good enough.
I will try hack palette, maybe this at least fix strips on ocean.
-
Yankes, ocean strips btw dont actually need to be dithered, since there are twice more than land shades.
'is always equal 0 in my case' - mean you've got algorithm wrong. You probably should push what you've made, and we'll see how to make dithering and battlescape light.
-
You probably should push what you've made, and we'll see how to make dithering and battlescape light.
Just my 2 cts... maybe a question to SupSuper, but pushing this now means that the interesting stuff that was in the roadmap for beta release 0.4 will be delayed to get this improved globe shade? With interesting stuff I mean the geoscape AI, like the UFO missions :)
-
Daiky, how's that? Shading change won't interfere anything except for visual appearence of globe!
BTW, Anotheer question to SupSuper... What about great circle shortest globe trajectories? :)
-
https://www.youtube.com/watch?v=TsgwgH5nVtU
my system in work :)
-
I can say that i finished globe shading. 100% mechanic is done. I used random noise to fuzzy shadow edges.
SupSuper and Daiky, what changes I should do before merging it with rest of code (different than splitting "SurfaceShader.h" into couple of headers, because I will do it anyway)? Is something that you dont like in my code (e.g. naming varabres using 4 different languages :D)?
-
Looks more like you fuzzied everything :P not sure if that effect is good, despite looking nicer, it makes it much harder to tell how dark an area is at a glance, compared to the flat shades.
Edit:
Daiky, how's that? Shading change won't interfere anything except for visual appearence of globe!
BTW, Anotheer question to SupSuper... What about great circle shortest globe trajectories? :)
In my TODO...
-
@SupSuper: +1
Yeah, the effect is kinda dicey... I wouldn't quite go with it for the final version....
-
SupSuper, kkmic, have you tried this?
I doubt you've made this assumption after trials.:)
I understand you've used to ugly XCOM globe view, and have some misgivings about usability of such smoothness. But, a) terminator line actually is narrower (about 1/66 of circle or 5.5 degrees), comparing to XCOM, so getting into "twilight" zone is not that easy b) Accidental unwanted battle time is happened in original XCOM too, no matter how accurate you're trying to avoid twilight or night.
Yankes, I've noticed, you added noise to all shade areas, to whole night side, which is wrong. Why so? Only terminator line needs to be "smoothed". BTW, width of this line should be tighten and probably corrected. And I noticed, noise doesn't look like being somehow smooth, I can clearly see strip borders. I suggest you to discard idea of "noise-smoothing" and release straight strips. It will be more than enough for the moment :) And after a while probably improve this with noise smoothing.
(https://chamorrobible.org/images/photos/gpw-200702-85-NASA-AS11-44-6692-Earth-from-space-night-terminator-day-Apollo-11-mission-July-1969.jpg)
It's about 5.5 degrees on both sides of night.
Full light is 180 degrees, and night zone is about 169 degrees of globe.
(https://upload.wikimedia.org/wikipedia/commons/thumb/9/99/Types-of-twilight-en2.svg/500px-Types-of-twilight-en2.svg.png)
Also...
Can you "smooth" only strips inside of terminator line and with night shade, while keeping "hard" border between terminator line and day light? This would make obvious picture, while it stays smooth and nice.
Pictures are too large, again
-
Volutar why you dont like my big screnshots? :D its easer to me to work with that resolution, because I can see every pixel without problems.
and about noise on dark side, its side effect of my method. I dont have any good solution for that (but I have couple bad ones :D ) and for me it didnt look that bad, I simple leaved it without any change. From comets I see that I need find that better solution :)
And thax Volutar for info about shadow position :)
-
Volutar why you dont like my big screnshots?
because they dont fit 1280x1024 :P
and about noise on dark side, its side effect of my method. I dont have any good solution for that (but I have couple bad ones ) and for me it didnt look that bad, I simple leaved it without any change. From comets I see that I need find that better solution
Hey, why don't you want to share with what you have? Four eyes see better than two :)
Anyways, I can't give any good suggestions relying only on these shots.
-
No, I do not want the stripes back. They are ugly as hell 8)
But if you look at the screenshots, the twilight was done by dithering. Even the night makes use of this system. And to be honest, it does not look nice.
What I would like to see in the final version is a linear "gradient" used for calculation.
Can't you apply an per pixel alpha blending effect depending on it's position in the twilight?
-
kkmic, dithering is needed to avoid sharp borders between different light levels. But as Yankes said - it was done by random noise, and I don't think it's a good idea. Noising night side isn't good either. It is definately subject to improve.
Can't you apply an per pixel alpha blending effect depending on it's position in the twilight?
It's technically impossible in 256 paletted color mode.
-
Isn't dithering rather slow to do real time (fps drop)?
I'd rather have the banding as in the original, it has a nice retro look to it ;)
-
Nah, it's not.
Either you're using Ordered dithering (https://en.wikipedia.org/wiki/Ordered_dithering)
(https://upload.wikimedia.org/wikipedia/commons/e/ef/Michelangelo%27s_David_-_Bayer.png)
or simple error-diffusion (https://en.wikipedia.org/wiki/Floyd%E2%80%93Steinberg_dithering)
(https://upload.wikimedia.org/wikipedia/commons/c/c1/Michelangelo%27s_David_-_Floyd-Steinberg.png)
or random noise
(https://upload.wikimedia.org/wikipedia/commons/c/ce/Michelangelo%27s_David_-_ruis.png)
(which Yankes used, as I suppose - he haven't released his sources) - you have to process almost whole image pixel-by-pixel. Original XCOM draws globe pixel-by-pixel - and that's not a problem at all :)
The only difference between these algorithms is either the image is stable or not. Ordered dithering is prefferable just because it won't "flicker" as others.
-
https://github.com/Yankes/OpenXcom/blob/master/src/Geoscape/Globe.cpp#L987
i released it ;P it would be strange if I did do that and ask SupSuper and Daiky to judge my code :) I try keep my fork up to date with my current version.
BTW i probably throw away half of this code soon :) I find out that more "brutal force" approach is better and faster.
current solution is more scalable, ugliest version is faster than "brutal force" but if you want get good looking globe it will take lot of more FPS to get it.
old solution was testing intersection between spheres, new one is comparing 3d normals of pixel in earth surface with sun direction.
additional new solution work much better with noise.
-
Testing sun vector for each surface pixel???
Did you compare fps for those 2 methods?
-
yes, and with current form openXcom.
using lowest rez and rotating globe i get:
orginal openXcom: ~1150 FPS
prev version (pretty, 32 different shades): ~600 FPS
prev version (ugly, only night and day without twilight): ~1200 FPS
new version: ~1150 FPS
Cord temp = earth;
https://diff
temp.x -= sun.x;
temp.y -= sun.y;
temp.z -= sun.z;
https://norm
temp.x *= temp.x;
temp.y *= temp.y;
temp.z *= temp.z;
temp.x += temp.z + temp.y;
temp.x = sqrt(temp.x);
temp.x -= sqrt(2)*rad;
if(temp.x > 0.)
if(temp.x>8.)
return 64;
else
return temp.x*8.;
else
return 0;this is all thing I need compute to get it, `earth` is 3d normal of pixel in earth globe that is seen in display, `sun` is direction where sun is (relative to screen). return value is value of shade in that pixel. this code is bit raw now and need some tweaking.
-
ok now I can say `I finished it` :D
soon I will update my git fork.
-
I think you should keep classic Earth inclanation at 0 degrees.
And.. i cannot compile it with VS :) nevermind.
-
what error you get?
-
It's technically impossible in 256 paletted color mode.
I don't know much about graphics, but can't it be faked? I mean, this is not a state of the art engine with countless shaders and post-processing effects, shadows and what else.
Since Yankes is already doing the calculation per-pixel, how much overhead would this type of faked shadow will add?
-
kkmic, no it can't be, until going 24bit mode.
So only those colors can be used in Geoscape mode:
(https://www.ufopaedia.org/images/1/14/1_GeoScapePal.Png)
-
What I see there is the full range of colors available, grouped into gradients (more or less)
As I understand it, each pixel has a "daylight color" and a "night color" (the start and end of a specific gradient) and a twilight pixels' color is calculated depending on the position in the twilight, and then, the appropriate color from the palette (in between those pixels) is used.
Did I get i right?
So, by using this algorithm, the original Xcom created those"bands" of shading, because only that set of colors were available.
Then... this sucks :)
Anyway, any plans on increasing the depth? After 1.0 I mean. I'm pretty sure that there will be quite a lot of people out there who would like to give Xcom a facelift. Higher resolution/redone graphics and maybe audio. That would require a 24/32 bit depth.
-
Did I get i right?
Yeah. Textures of globe are simply paletted textures, and when they are shaded - each pixel just shifted forward to darker version (with clamping on "darkest").
Terrain textures use 16 intensity palette parts, while ocean have 32 intensity levels, so ocean looks smoother than land (in original XCOM).
-
I get final version to git. additional I get correct shade for Battlescape. In couple of days I will try merge it with main version.
-
Your version doesn't compile in VS2003.. :( look into PM.
-
beta version of my shading is done, commit waiting for approval.
Volutar new version should avoids this errors you get, at lest I hope so :)
-
I like the new system. I now realized that what I really did not liked was that the night was also dithered somewhat.
Great job Yankes!
-
will be my commit accepted/rejected any time soon?
-
Yankes, have you fixed all errors which popping up in VS?
-
yes, I rewrite everything, and now every thing should work (but I could made new errors :D)
-
I found one. Zoom level stuck sometimes for border lines and city layer.
I've turned off "noise" thing and found it looking much better.
-
I've turned off "noise" thing and found it looking much better.
And those ugly bands are back ;)
-
I disagree. They are less ugly than notorious noise.
Plus, if it will be dither-smoothed, you will hardly recognize where twilight starts.
I tried to make shade little more intense, to make globe more contrast.
-
I prefer my random noise but it can be easy toggled by one variable. One person want its off (Volutar) another want it on (me)
-
Yankes, random noise is a bad idea. If you want to get rid of banding you need to dither, not just add some random noise.
-
Maybe its because im not a programmer but i think it looks good with and without the noise ::)
-
I found one. Zoom level stuck sometimes for border lines and city layer.
I've turned off "noise" thing and found it looking much better.
That bug is in the original globe too, I never found the cause.
And I prefer the noiseless look too but I've never liked noise/dither smoothing anyways. :P
-
That bug is in the original globe too, I never found the cause.
Oh!! Okay then.
Watching how this bug appears, I may conclude it somehow connected with coord caching things (if any). I can try to figure out how to fix this.
And I prefer the noiseless look too but I've never liked noise/dither smoothing anyways. :P
Dither is nothing like noise in this case. It should be looking much better. But due to the nature of this "shader" technique I can hardly imagine how to integrate dithering algorithms into this shader.
Dithering requires access to whole "undithered" image with 256 intensity levels of shade.
Actually I see only one way - using 8-bit shade mask on "unshaded" globe image, like post-processing.
-
I made some tweaks to my random `noise` by reducing it amplitude. Effects now are more closely to dithering.
-
Looking good.
I like it, as it is less disruptive than the previous settings.
Stupid question: is there a build available so that I can do a quick test?
-
my build is available on https://github.com/Yankes/OpenXcom `test` branch (`master` is obsolete)
[ps]
I made some test and i get something like this. Volutar this version is good enough or you will prefer true dither?
-
Yankes, neighbor stripes should be "smoothed" but not overlapped through each other. Unfortunately this depends on zoom level. While this picture is quite acceptable, zoomed out picture will look more "noised" at twilight zone.
I suppose you've set rand()%8 value? I prefer %4, though %8 is much better than %20 which was at first. Flaw of this "smoothing" approach is indistinguishable "full night" and "full day" line.
I've attached vs2003 built version. Which is, I suppose, quite old (in terms of git branches).
-
By the way, quality of picture greatly depends on display you're using. I have S-IPS display at home and IPS+TN at work. And I have noticed that ocean blue seems to bee more "smoothed" (despite on noise) because of falling into dark on TN more, than on IPS.
-
Another try.
I've slightly modified palettes.dat file to make globe terrain shade more solid and realistic (ocean part kept intact).
This modification doesn't affect on other parts (they are used only for earth textures).
It might become too dark, but day parts become more distinguishable from night.
-
Its look better that standard palette.
-
New version of shading makes polar iceberg zone "normalized", comparing to original.
Ocean color is lighter than texture of mixed polar/water.
On a screenshot contours of "non processed" area above and at the right side. So you can see how "smoother" and nicer new lighting looks.
https://www.fourmilab.ch/cgi-bin/Earth?imgsize=320&opt=-l&lat=22.875&ns=North&lon=65&ew=West&alt=1000000&img=learth.evif
On the second image is Earth view from initial point (openxcom) with timestamp above. I think it should be used as fine example for terminator line position and size at particular moment.
So there are some mistakes in inclination calculation.
-
Okay.
I was experimenting with making twilight zone more realistic.
There's some results.
Outsize "main" terminator line is a twilight zones - wide area where there's no full night (terrain is slightly illuminated by atmosphere) and not so wide area of sun near horizon (it's not full day).
Some noise pattern also present, it is more noticable on ocean surface, and less on land.
-
https://www.youtube.com/watch?v=sqmpNWExKmo
Video demonstration. Though it looks weird, smoothed slightly + encoding artifacts.
-
Just FYI, Yankes' patch is now officially in the codebase. :)
-
That's good to hear.
GG Yankes ;)
-
today globe, tomorrow rest of OpenXcom :D
SupSuper how about adding skin color to battlescape? dont change much but increase immersion :)
-
i second his skin colour suggestion
-
today globe, tomorrow rest of OpenXcom :D
SupSuper how about adding skin color to battlescape? dont change much but increase immersion :)
Sure, just throw me a pull request, they're easier to manage than poking around your various repositories. ;)
-
Is there any chance to tweak new geoscape lighting, and make the noise more "smooth", or completely remove it? It reminds me of low shadows samples when using area lights, or area shadows/skylight (scanline renderer) :P
-
Is there any chance to tweak new geoscape lighting, and make the noise more "smooth", or completely remove it? It reminds me of low shadows samples when using area lights, or area shadows/skylight (scanline renderer) :P
That was something I asked about some time ago (https://openxcom.org/forum/index.php/topic,156.msg2671.html#msg2671) in this very thread. That and the next two posts should explain it.
-
easy :D only need some options in config and one `if` :)
BTW Volutar did some tweaks to this my globe shading, is possible his version will look better :)
-
There is additional patch for Yankes' globe, which I made before pull request was added. I have changed gradient alittle (there are wider zones of almost-day and almost-night), very little noise, option "globeSeason" which switches Earth inclanation (it's off by default, like in original), so you have to write "true" in options file to turn it on. Also sun position was improved to match astronomical position. And battlescape lighting level also matches what you visually see on the geoscape (it was LUTed with loosing intermediate levels).
Another thing that should be done is showing light level on equipment screen or before battlescape loading (on the briefing screen). I must say it's kinda logical and informative for the battle. And very weird why noone suggested that.
-
There is additional patch for Yankes' globe, which I made before pull request was added. I have changed gradient alittle (there are wider zones of almost-day and almost-night), very little noise, option "globeSeason" which switches Earth inclanation (it's off by default, like in original), so you have to write "true" in options file to turn it on. Also sun position was improved to match astronomical position. And battlescape lighting level also matches what you visually see on the geoscape (it was LUTed with loosing intermediate levels).
Sounds good, Volutar. I like that wider zones between full night/day (if I get it correctly :P), and geoscape = battlescape lighting level thingy.
Another thing that should be done is showing light level on equipment screen or before battlescape loading (on the briefing screen). I must say it's kinda logical and informative for the battle. And very weird why noone suggested that.
Fly-by over the battlefield perhaps? :P Player is using crafts to get over there after all. Note: it's just a silly idea with that fly-by ;)
-
Yeah, but a 'time of day' info could be added to the briefing screen easily. And indeed, as the soldiers fly there, that info is already available to the Commander, right? So this is not some kind of cheating....
-
Yeah, but a 'time of day' info could be added to the briefing screen easily. And indeed, as the soldiers fly there, that info is already available to the Commander, right? So this is not some kind of cheating....
I can't even begin to count the amount of times I forgot whether I was going into a day/night mission, so I'll definitely consider this. :)
-
Ok Volutar's patch is up, though I hope you guys aren't dedicating all the posible CPU and brain power just to create SimGlobe. :P
-
Wow, it's been a long time since I've been here. Looks like some nice progress on this.
Will have to check out the code later and see what I've missed
-
I hope you still find your way in the code and welcome back :)
-
I hope you still find your way in the code and welcome back :)
Thanks. Is there a ToDo list these days? Hopefully when I've caught up to date, I'll try and assist as and where
-
I could try to compile a todolist for the battlescape, and post it in the battlescape development thread.
-
For some reason in last versions Radar toggle (r) changes random pattern too. That looks not nice. Is it possible to get stable noise pattern back?
-
<disclaimer>
a) I know this is bordering on necroing a thread
b) I am happy with the current globe as it is
c) I remember all the troubles and hardships the team went through in creating the current working globe
d) I am aware that some of this touches work that has in more-or-less great parts been done by a member who has since fallen away for several reasons
</disclaimer>
that being said, does anybody think it would be possible to allow for a more flexible globe? I think that "regions" (as in almost-but-not-quite-countries) are still hardcoded, right? as is the general topology of the globe. for several reasons (including but not limited to TFTD/UFO combined play) it would be nice to have a little more flexibility. I'm not sure if there is an easy or even at-all-possible way of achieving this with the current system... any of the programming specialists have an idea?
@Warboy: I don't know the background story of your "war" mod, but in my mind I always see it as a less covert and more open-war game, where the alien invasion has truly started, with world war III being fought across the globe, playing ground missions to "capture" or "defend" countries, expanding your territory, like in the good old days of "Dune" and "Command & Conquer" (or, even more basic, Risk (https://en.wikipedia.org/wiki/Risk_(game))). for this, of course, you would need dynamically changing territories... and I could see several interesting uses of dynamically-changing topology, too (alien-triggered asteroid impact, global sea levels rising due to T'leth activities...) :)
the way I see it, there are three options:
1) we keep the current system, although unhardcoded and more easily accessible: a big list defines triangles by three freely-placed corner points and assigns each triangle a "terrain". regions are defined somewhere else
2) we expand on this system, increasing the number of triangles, each triangle has a "terrain" and a "region" (and possibly a few other properties like "owner", "impassable by unit of type x", "value" (for funding), whatever you can think of). I don't know how high the number of tris can be before the game starts lagging terribly, but if this is added in an openGL kind of way, you can probably go pretty high. of course, setting up the globe would be terribly inconvenient unless there is some kind of easy editor which allows you to "paint" properties onto the globe, adding them to the tris where applicable
3) we throw everything away and change it to a bitmap that is wrapped around a 3D sphere. the bitmap uses pre-defined color coding, which is translated into "terrain" in-game. regions are either defined as before, or with a second bitmap, adding the future possibility of allowing the game to change the bitmap
4) ...? I don't know. I'm not a programmer - I don't know about hardware use of the different approaches... :)
-
None of it is hardcoded, countries and regions come from the ruleset and topology comes from WORLD.DAT. We do plan on moving it all to rulesets eventually.
In the meantime you can check out this thread regarding previous efforts of modding the globe and a WORLD.DAT editor: https://openxcom.org/forum/index.php/topic,530.0.html
-
SupSuper, you do realize that about one third of the later posts in the thread you linked to were from me, don't you? ;)
I didn't realize that the regions were already moved to the ruleset... but they are still "rectangles", right? meaning you define a minimum and maximum latitude and longitude, right?
-
SupSuper, you do realize that about one third of the later posts in the thread you linked to were from me, don't you? ;)
Hey the thread is from last year, my memory isn't that good. :P
I didn't realize that the regions were already moved to the ruleset... but they are still "rectangles", right? meaning you define a minimum and maximum latitude and longitude, right?
Yes, but you can make them out of multiple rectangles. The only thing that I think is still hardcoded are the border lines you see on the Geoscape, but those are just eyecandy and not actually representative of the actual area.
-
None of it is hardcoded, countries and regions come from the ruleset and topology comes from WORLD.DAT. We do plan on moving it all to rulesets eventually.
In the meantime you can check out this thread regarding previous efforts of modding the globe and a WORLD.DAT editor: https://openxcom.org/forum/index.php/topic,530.0.html
That editor needs more work :(