project-navigation
Personal tools

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - arisian

Pages: 1 ... 4 5 [6] 7
76
First off, yes, you will be able to turn it on/off; it works the same way the nation overlay always has, except that the colored patches for nations now have glowing borders.

And I will work on improving the specularity and adding other rendering features, but that might take me a bit longer to have time for (the nation borders don't actually require much work).

77
Here's a screenshot of a first attempt at glowing nation-overlay borders; is this what you had in mind?  It requires all of about 3 lines of extra code, and an extra texture.  The texture I've used here could probably use some work, but I'd like feedback on what direction people want to go with it first (ie. should glowing borders be more/less bright? more/less wide? more/less opaque? etc.).

78
Sounds good; I'll let you know when I've got something.  Incidentally, is it better to post such things here, or to the tracking system, or both?

79
Ah, sorry, I'd missed that post.  In any case, yes, it should be fairly straightforward.  Are you looking for edges that always glow, or only at night?  Also, do you just want the edges to glow, or the whole overlay? (the latter is actually easier to implement; I suspect the former will require either an extra texture or some real fancy GLSL).

80
What about the nation overlay; has it stopped working?  I admit I haven't checked since a few versions back, but I thought that the new rendering system hadn't affected it.  If it's broken, I'll take a look at, though I probably won't have time to do anything about it until tomorrow.  It shouldn't be hard to fix, given that I know it was working with the new renderer just fine the other day.

81
FYI, the "high-res" textures that I started with are, in fact, .pngs; with optimized lossless compression, the "season" images are ~20MB each at 8192x4096.  The gloss and night_lights maps can be losslessly compressed to 280Kb and 600Kb respectively.  The issue is less how much space they take up on disk, and more how much space they take up in system memory when the game is running.  The amount of compression doesn't affect runtime memory useage much; the only thing that's really important at runtime is the resolution.

Also, if you haven't yet downloaded the high-res textures from the link I posted, wait another 24 hours and I'll have replaced them with versions that are the exact same quality, but smaller on disk (fully optimizing PNGs takes a long time, but it's worth it for lossless compression; the season images are being reduced from ~30Mb each to ~20Mb each).

In terms of what winds up in the SVN trunk, I think it should be somewhere in the middle.  The versions that I attached to my post yesterday were *extremely* low quality because of the fact that I could only attach 1Mb total to the forum post.  I think we can probably afford more than 60Kb per globe image in the "final" version ;)

Feel free to mess with the specularity; there's the specularExp variable that defines how "tight" the spot is, and then there's map_earth_gloss.jpg which defines how shiny different parts of the globe are.  Currently, water is maximally shiny, which should probably be tuned down.

82
The high-res textures are now available at:

http://cs.jhu.edu/~ben/graphics/ufoai/

83
Okay, here's another new-and-improved version; it integrates better with the existing systems.  Also, for the record, you don't actually need more than 4 texture *units*, you just need more than 4 texture addressable *coordinates.*  The major problem I was running into earlier, as it turned out, was that the code in r_program.c was refusing to give me the texture references I was asking for because it was capping them at the 4 units that my card has.  The code now checks both GL_MAX_TEXTURE_UNITS and GL_MAX_TEXTURE_COORDS, and uses the latter when deciding whether functions like R_SelectTexture succeed or not.

It would also be easy to get rid of the changing seasons, which would require fewer texture units, less memory, and so forth.  It seemed like a nifty feature, but it may not be worth the resources required.  It would also be fairly easy to do the rendering of the city lights as a separate pass, which would mean another texture address that wouldn't be required, but it seemed better to do it all in one pass.  Besides, I had just learned GLSL, so I wanted to flex its muscles a little :)

In terms of the light textures, the light is actually off-white at the moment (slightly yellow looks more correct).  It would be easy enough to simply use a grayscale image, which would certainly mean a smaller file on disk, but I don't think it would help much in terms of graphics card memory (someone correct me if I'm wrong).

84
I'm working on integrating my code with the functions in r_program.c; if I'd known they were there, I probably would have used them in the first place.  Oh well, this is what comes of working on a totally unfamiliar codebase while simultaneously teaching myself openGL and GLSL ;)

I'll post another version of the patch once I've got things working properly using existing functions.

85
In terms of terrain maps, it's really just an issue of expanding cold/arctic regions during the winter.  I can do it myself, but I'm unclear as to the difference between "cold" regions and "arctic" regions, and also on the overlap between either of these and "mountain" regions.  The current texture image (map_earth_day.jpg) seems to have been taken sometime around March.  There are clearly "mountain" regions that have snow on them, and the "cold" region overlaps both green and snow-covered areas.

I can just make it up as I go, but if there are actual conventions I'd rather follow them.

Also, if anyone is still having issues compiling from the latest posted patch, please let me know.

86
Coding / Re: Nightime city lights in 3D geoscape
« on: March 23, 2010, 04:03:50 pm »
The "smooth change" is really just so that there isn't a visually abrupt change at the end of the month; there are still only 12 discrete maps, it's just that the change from one map to the next is gradual rather than instant.

87
Coding / Re: Nightime city lights in 3D geoscape
« on: March 23, 2010, 04:01:14 pm »
Hmm, looks like you're using a different build environment; are you building on Windows by any chance?  I run Linux, so I appreciate feedback from those on other platforms.  In any case, try this version; hopefully it will be more friendly with non-gcc compilers (the only difference is using slightly longer forms of names in a few places).

88
Coding / Re: Nightime city lights in 3D geoscape
« on: March 23, 2010, 03:08:00 pm »
I decided that if I'm actually going to be the one to implement this feature, I want to do it right, rather than just the proof-of-concept I posted before, so this is a new, vastly improved version.

Now the city lights only show up where it's actually nighttime, and are prettier to boot.  Also, I've implemented bump-mapping and specularity-mapping and texture-blending as well.  This means that the 3D geoscape now has topographic rendering with lightsource-dependent shadows, and sunlight reflects off the water.  It also means that the visuals now correctly represent seasonal changes with smooth, seamless changes over the course of the year.

These new rendering features are all handled by a GSLS shader program, but the older rendering methods all still work the way they always did (ie. there's no change to the way that nation overlays and the like appear).  There is also a new option in the "options->game" menu that lets you switch between the new globe renderer and the old one (though you need to restart the program after switching the option before it will take effect).

This is particularly important because the new version has higher requirements than the old one.  If your graphics card doesn't have the features required, it will automatically fall back on the old rendering system, but I think that any reasonably modern graphics card should work (if anyone has issues, please let me know).  It also requires more system memory, especially if you use the high-res textures.

Speaking of textures, I've been using higher resolution images for the globe surface, which look much crisper and prettier when you zoom all the way in.  The disadvantage is that they are, well, bigger.  This means that they take longer to load into memory, and they take up more memory once loaded.  It takes several extra seconds on my system to bring up the geoscape, with an additional ~3 second pause near the beginning of a new month while it loads the texture for that month.

That said, I can't upload the high res images here because they're ~25Mb a piece, and there are 12 of them.  I have therefore uploaded lower resolution versions so people can actually see the system working, but I really think the high-res versions are prettier; I just don't know what the best way to distribute them is.

The current season system consists of one texture image per month; the images I'm using come from NASA's Blue Marble project (as did the images I started with when making the bump map, city lights, and gloss textures, though those required some modification).  The system blends two textures, one associated with the beginning of the month, and the other associated with the end of the month (ie. the beginning of the following month).  The two textures are combined according to how far through the month it is, so things change slowly and smoothly.  If you want to see it in action, I recommend modifying the campaign.ufo to set the "minimum happiness" to something negative; otherwise, you'll generally loose after just a few months if you don't do anything but watch the globe spin, and you really need to speed things up to the fastest speed and watch for a few months to get the full effect :)

I've attached a diff relative to the current svn, along with a zipfile that contains the new images needed (extremely low-res versions only, I'm afraid, since the forum only  accepts up to 1Mb of attachments; if someone wants to give me svn access so I can upload the high-res versions, my sourceforge username is "arisian"...;)).

Please let me know what you think, or any issues you might have, especially if you experience anything that looks "wrong;" I've only been able to test this on my own system.  It looks very pretty for me, but I'm not 100% confident that it will look the same on other brands of graphics cards (my current one is an nvidia geforce 9800gt).

89
Coding / Re: Nightime city lights in 3D geoscape
« on: March 19, 2010, 01:32:54 am »
Hmm, looks like my previous patch didn't follow all the guidelines; I hadn't read them because I wasn't really expecting it to get put into trunk without revision.  It won't be hard to fix though (mostly things like tabs vs. spaces, comment style); I'll try to post a better version tomorrow.

90
Coding / Re: Nightime city lights in 3D geoscape
« on: March 18, 2010, 07:15:55 pm »
Actually, this the first time I'd done any openGL coding (I'm a fairly experienced C/C++ coder, and I've done a decent amount of graphics work, just not with openGL).  That's why it took me all afternoon; I was learning the relevant parts of openGL as I went :)

I'd also like to state again that the patch I posted is a somewhat brittle way of implementing the feature, and has the downside of making the cities look white-ish during the day (ie. everyone keeps their lights on 24/7).

Anyway, I've certainly got interest; I like the ideas behind ufoai a lot.  Time, on the other hand, is not something I'm exactly swimming in.  I might be able to do small things from time to time, but I'm just not in a place where I can claim I'll be reliable in doing things in a timely fashion.

The other trouble is that the things that I'd most like to fix/improve about the current development version are things which would require re-writing substantial portions of the codebase (for example, .50 caliber sniper rounds bouncing off rice paper dividers, or allowing missions to be fought in pseudo-realtime a la the UFO:After* games as well as the turn-based mode.  I love turn-based, but it makes thing so darned *slow*, especially given the frequency of terror missions.  I find myself using the "auto-resolve" frequently just because I'm sick of trying to balance good tactics with the desire to explore the map and find the enemy before my hair turns gray).

That said, I may have time to occasionally implement some small feature or other; do you use any formal feature/bug tracking system that I could look at to see what things are awaiting implementation/fixing, or should I just use the wiki? Nevermind, I found the sourceforge tracking systems, though things there seem more like random feature requests than an ordered list of things that need doing.

Also, what's the best way of submitting changes?  I'm currently using SVN anonymously, so I assume I can't do commits that way, and posting patches in the forums seems sub-optimal if I'm going to do this more than once.

Pages: 1 ... 4 5 [6] 7