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 ... 3 4 [5] 6 7
61
It's certainly easy enough to just get rid of specular reflection entirely if we want.  I can rip out all the specularity code entirely if you want, or I can just disable specular rendering for the moment.  I'm inclined to do the latter, but let me know what you think.

In terms of the "overwriting textures" issue, part of the reason I did things the way I did was so that users could actually switch which textures they were loading without having to deal with actually deleting or re-naming files.  Unless I don't understand the way that the pk3 files work, if you have the high-res 1geoscape.pk3 file on your system, there's no way to tell the game to use the low-res 0geoscape.pk3 without actually removing the 1geoscape.pk3 file from the search path.  It's still entirely feasible to have different pk3 files for the different texture resolutions the way I've done it, but if you have several of them on your system, my method uses the correct one based on the in-game options settings, rather than automatically using the highest resolution one that exists.  This way, you could (for example) include 0geoscape.pk3 *and* 1geoscape.pk3 in the "standard" download, and then have 2geoscape.pk3 as an "optional" addon with the very-high-res textures.  You could even include all three .pk3 files in the "standard" download without having to fear that you would be forcing people to use the high-res textures.  It would make a difference in terms of hard-drive space and download bandwidth, but that would be the only difference for players with low-end systems.

I'll take a look at the issue with the sun effects being in the wrong place; I didn't try running the game at different resolutions, which I'm pretty sure is causing that problem.  I don't think it should be too hard to fix.

I'll also go ahead and make the post-processing switchable at runtime.  In terms of the "default" behavior, I'm not sure how easy it would be to enable/disable things by default based on auto-detection; is there an easy way of doing that?  It will disable things if the system can't handle the new features at all (ie. the graphics card doesn't support the opengl extensions we need), but I'm not quite sure what to do beyond that.  Though once I make it possible to turn post-processing on or off on-the-fly, it may not matter that much.

I'll let you know when I've got a new patch; in the mean time, let me know if anyone runs into any other issues.

62
Okay, a new patch has been posted to the patch tracker (https://sourceforge.net/tracker/index.php?func=detail&aid=2977653&group_id=157793&atid=805244 ); it works well on my system, but it's a large enough patch that it's pretty unlikely that it will work flawlessly for everyone.  If you run into issues, please let me know.  In addition to the patch, you will also need a number of new files; they can be obtained from (http://cs.jhu.edu/~ben/graphics/ufoai/).

After the discussions here about texture file size, I have introduced a system with several different versions of each texture in different sizes.  The game will automatically load the images with the size that best matches the setting for "texture quality" in the graphics options menu.  If those images don't exist (ie. you ask for high-res textures but you haven't downloaded them), it will automatically fall back on the best match it can find.  For this reason, the lowest resolution textures should always be present, but these are quite small.

I've also changed from having one texture per month to having one texture per "season" of winter, spring, summer, fall.  This means we only need 4 textures rather than 12, which reduces the size of the download by a factor of 3, and still provides pretty good visual quality in terms of being able to watch the seasons change.

The new post-processing effects are pretty, but also relatively demanding, so if you're not happy with the framerate, simply turn off the postprocessing effects in the graphics menu.

63
Also, for those who are saying we can't include high-res textures because old systems can't handle them, I have to admit I'm kind of confused.  The game already includes an option in the "graphics" menu that lets you pick what you want to cap the maximum texture resolution at; if you're having problems with high res textures, can't you just force the game to use scaled down versions?  The original data file size has nothing to do with the size of the texture in system/graphics memory, which is controlled entirely by the resolution of the image, so how big the files are on disk is really only relevant when you're downloading them.  Is there something about this that I'm missunderstanding?  Because I just don't get the "large textures won't work on older systems" thing.

64
Actually, that is helpful; I haven't really tried playing the game with the new features yet, since I've been too busy coding them.  I haven't played much with going back and forth between the new geoscape and the battlescape, so I'll definitely give it a look.  As long as I can replicate the problem, I'm sure I can fix it.

65
I'm not certain which day/night issue you're referring to, but I'm pretty sure that they're all fixed in my personal latest version.  However, there are some other things that need to be dealt with before I'm ready to release this version.  I'm sorry that the current svn version isn't working for you, but it is the unstable branch ;)  All will be fixed in time, I promise.

66
Just a quick update; I've solved the cursor bug, and improved the efficiency.  It's still not "finished," but I'm making good progress.  Here are some screenshots from the latest version.

67
Kildor: if you could provide a save with XVI active, that would be helpful.

In terms of topographic rendering, I had been going more for the "classroom globe" look than "earth from space."  Changing the ocean bumpmap is easy enough; we can tone down the amount of topographic depth for the land as well, if people want more realism.  I'd like to introduce clouds/weather systems eventually, but that's likely to be a fairly complex and involved project, and I'm not sure how feasible it is at the moment.

There are no oceanic missions right now anyway, so the ocean rendering is purely aesthetic.  On land, mountains/plains generate different battlescape maps, so there is an actual gameplay effect.

68
Nation borders and day/night work the same way as they always did if you disable the new features.  I haven't even looked at the XVI overlay, though I don't think any of the changes I've made should have affected it.  Did you have specific thoughts about changes you'd like to see in the XVI overlay?

69
Just a couple screenshots of the "glow" effect for the sun I'm working on; the first one is just real-time bloom, the second is real-time bloom combined with a static texture for the "rays of light."  It still needs some work; the current implementation is inefficient (my 9800gt is only getting 30FPS), and also screws up the cursor image (for reasons I have not yet been able to figure out), but at least now you have some pretty pictures to look at while you wait :)

Also, as to image formats, I personally am a big fan of lossless compression; I think Mattn calculated that we could save something like 100Mb by converting the .TGA images to .PPM, so my personal preference would be to use half of that savings to include decent looking globe textures.  Though I might be a bit biased, given that I made them ;)

70
Hey guys, sorry I haven't been around for a bit.  I am still working on this stuff, but I'm continuing to add new features and improve the way things are implemented, so it doesn't really make sense to put lots of temporary stuff into the SVN, which is why I haven't been posting patches.

The issue with the nighttime illumination is caused by the fact that JPGs can't handle transparency.  We'll need to use .PNGs or .TIFFs or something instead.  I'm still working on trying to make textures which are relatively small on disk but also look pretty; I've thought of several things I could potentially do to improve the texture file size, but haven't had time to implement them yet.

Also, don't worry about the nation borders; the way I did it before was the quick and dirty version (which was fast to implement).  Right now I'm working on adding proper real-time glow/bloom effects, which should negate the need for having a separate "glow" texture for the nation overlay.

Finally, in terms of this game running on different systems, I'm making an effort to implement everything in such a way that all the new features are "optional," and can be disabled on systems with lower specs.  None of the old rendering code is going anywhere, and new rendering code will have menu options to disable, as well as being automatically disabled on graphics cards which don't support the required features.  This way, we should be able to get the game to look pretty on new systems without changing the "minimum" system requirements.

In terms of texture size, there are essentially two completely distinct issues, and I'm still not sure how important each one is.  First, there's the size of the image files on disk.  This is important to how long it will take people to download UFO:AI, and how much hard drive space it will take up.  Frankly, I don't think an extra 30Mb of disk space will make that big a difference for any system that's modern enough to run the game at all.

The second issue is how much memory the textures take up at runtime; this is both an issue of system memory (RAM), and of dedicated graphics card memory.  Here, the size of the textures *will* make a difference in terms of framerate on systems with different levels of graphics hardware.  If this is the real concern, however, it should be relatively straightforward to allow the user to select what size textures they want to use, again allowing the game to be played on both high-end and low-end systems.  This would still require us to have the high-res textures in the distributable, however.

Finally, as to bump-maps for ocean floors, they're easy enough to remove if people don't like them; once I'm done improving the rendering code I'll look at working on the textures.  Do other people have thoughts about whether oceans should have topographic depth or not?

71
Are you sure that the new textures are being read rather than the old ones?  My guess would be that it's reading the old versions of the "season" textures, which would account for the all-white behavior.  Either download the full set of new textures from www.cs.jhu.edu/~ben/graphics/ufoai/ or make symlinks/copies from the season_00 texture from the forum post to all the other season_XX files.  Also, the game seems to prefer .PNG files over .JPG files; if there are files with the same name but different extensions, it loads the .PNG one and ignores the .JPG; if you've got versions of both, this might be why it's not loading the image you were expecting.

Honestly, though, you might not want to put that patch into the SVN; feel free to play with it, but there's still a bug in the way that specularities are calculated.  I'm still trying to figure out exactly what's going on with the view vector to get it "right"; it's close in that patch, but the specular highlights just aren't quite right.  I'll let you know when I get it fixed.

72
Okay, I'm glad it got fixed.  I started trying to fix something else, and got bogged down; I'm having trouble fixing specularity properly because things like vertex and light positions don't seem to be relative to view coordinates, or the view isn't where it should be, or something.  Anyway, I'll let you know when I get it figured out; I suspect it's an issue that's being caused by the fact that we're not using a projective system, which means the "view location" doesn't have the same meaning it normally would.

73
Is this error only with the newest patch, or with any version of the GLSL shaders?  Can you post any info about their graphics cards?  It works fine for me, so it's a little difficult to debug; I suppose it might be some sort of difference between what version of GLSL their cards support, though I thought the dot product operator was always available.

74
Okay, the patch is posted over at the patchtracker, though I'll post it here as well.  I have to post the texture-images here because the patch-tracker will only accept 256k of attachments.

I've only included one season texture in this tarball; just use symlinks (or copies on windows) to make all the season map names point to this file, or go grab updated versions of all the season textures from http://cs.jhu.edu/~ben/graphics/ufoai/ (the new files aren't there yet, but the links are; the files will be there in a little bit, when I'm done converting/compositing/resizing them all).

75
Just a quick status update; here's a couple of screenshots from my latest version.  I've toned down the specularity a bit, and worked on the glow texture.  I've also made some less visible improvements, including making my GLSL code not need so many texture units, reducing memory footprint, and having a proper tangentspace for calculating bump-map lighting.  I'm going to take a look at trying implement post-processing effects like rendered glow (as opposed to "glow" which is actually a hand-painted texture, which is what I've been using up to now). 

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