46
Coding / Re: mouse control of battlescape camera rotation
« on: April 16, 2010, 11:05:42 pm »
.....right. Anyway. Anyone with actual feedback?
News:
New board
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.
47
Coding / Re: mouse control of battlescape camera rotation
« on: April 16, 2010, 11:02:05 pm »
All the old keyboard-based camera controls are still there; this just adds an extra way of controling the camera pan/tilt in a way that's a bit more natural relative to other 3D games. You don't *need* to use this feature, though how are you playing the game at all without a mouse?
48
Coding / mouse control of battlescape camera rotation
« on: April 16, 2010, 05:11:06 pm »
I've implemented a quick-and-dirty version of mouse-based camera control for the battlescape. If you hold down the middle mouse button and drag, it will control camera pan/tilt (in the way common to many other 3D games).
I've attached the patch, but I'm not sure the patch should go into the trunk in its current form; right now, there's no way to turn the feature on/off, control the speed of rotation, re-bind the control, etc. except to change the source code. It may also be brittle; I haven't tested it extensively, and I don't know if it will introduce any undesirable interactions with existing code. If people want to play with the patch and give me feedback, though, that would be great. In particular, thoughts about how this feature should actually behave, and how (or if) the user should be able to control it from the in-game options menus (ie. speed, binding, etc.).
I've attached the patch, but I'm not sure the patch should go into the trunk in its current form; right now, there's no way to turn the feature on/off, control the speed of rotation, re-bind the control, etc. except to change the source code. It may also be brittle; I haven't tested it extensively, and I don't know if it will introduce any undesirable interactions with existing code. If people want to play with the patch and give me feedback, though, that would be great. In particular, thoughts about how this feature should actually behave, and how (or if) the user should be able to control it from the in-game options menus (ie. speed, binding, etc.).
49
Artwork / Re: New Feature: "Glow" textures
« on: April 16, 2010, 02:56:48 am »
That depends on what you mean by "glow maps." If you just mean "emissive materials", that's easy, but they won't have bloom-effects around the edges. You can also create one-off transparent textures that you slap on top of an object which create a type of bloom-effect (this is what has been done for the sun's "rays" on the geoscape), but that solution doesn't scale very well, as well as not being able to handle occlusion gracefully.
Doing bloom-effects as a post-processing step is, indeed, moderately expensive (just how expensive is dependent on how smooth a result you require), but there are several advantages. First, you don't need an extra "halo" texture for everything-that's-supposed-to-glow-ever, which saves compute time (in calculating where in 2D space the textures should be placed, as well as in drawing them), memory, and artist's time. Second, occlusions are handled naturally, and you wind up with bloom-edge-effects that look a lot more like camera images. Finally, while the postprocessing step is costly, it only needs to be done once per frame; it's essentially a fixed cost regardless of how simple or complex the scene is. Adding more models, textures, animations, etc. to the scene doesn't change the cost of the postprocessing step, so it's a very scalable solution.
"True" HDR relies on the same postprocessing as the glow/bloom features I've implemented; the only difference is that where I've got two separate render buffers (one for "normal" and one for "glow"), standard HDR uses a single buffer of half-floats, which allows values greater than 1.0 (or 255, depending on interpretation), which can then be used to determine what things are brighter than the screen can display, and draw bloom around those things.
Doing bloom-effects as a post-processing step is, indeed, moderately expensive (just how expensive is dependent on how smooth a result you require), but there are several advantages. First, you don't need an extra "halo" texture for everything-that's-supposed-to-glow-ever, which saves compute time (in calculating where in 2D space the textures should be placed, as well as in drawing them), memory, and artist's time. Second, occlusions are handled naturally, and you wind up with bloom-edge-effects that look a lot more like camera images. Finally, while the postprocessing step is costly, it only needs to be done once per frame; it's essentially a fixed cost regardless of how simple or complex the scene is. Adding more models, textures, animations, etc. to the scene doesn't change the cost of the postprocessing step, so it's a very scalable solution.
"True" HDR relies on the same postprocessing as the glow/bloom features I've implemented; the only difference is that where I've got two separate render buffers (one for "normal" and one for "glow"), standard HDR uses a single buffer of half-floats, which allows values greater than 1.0 (or 255, depending on interpretation), which can then be used to determine what things are brighter than the screen can display, and draw bloom around those things.
50
Artwork / Re: New Feature: "Glow" textures
« on: April 15, 2010, 02:00:03 am »
Okay, I think I fixed the bug that was causing the "offset" issue; it seems to work at all resolutions here. Let me know if anyone has issues with this after updating to the latest svn version.
51
Artwork / Re: New Feature: "Glow" textures
« on: April 14, 2010, 03:01:01 pm »
I'll take a look at the "wrong size renderbuffer" issue, though I'm rather perplexed at first glance, since I'm using viddef.width/height as the size for creating the renderbuffer. Is there some way that the viddef info could be wrong? It seems to work fine for resolution switching in the geoscape; is viddef only applied to the geoscape or something?
As to the glow "through" other models, that's simple to fix if you're rendering the models using GLSL, but much more of a pain otherwise (you would effectively have to render all models twice, once to the render buffer and once to the glow buffer, and making them all black for the second of the two if they were supposed to block glow). It wouldn't be difficult to implement, but it seems inefficient. If you're using shaders, you can just render to both buffers simultaneously (using gl_FragData[0] and gl_FragData[1] after calling R_EnableGlow), so there isn't any performance hit.
As to the glow "through" other models, that's simple to fix if you're rendering the models using GLSL, but much more of a pain otherwise (you would effectively have to render all models twice, once to the render buffer and once to the glow buffer, and making them all black for the second of the two if they were supposed to block glow). It wouldn't be difficult to implement, but it seems inefficient. If you're using shaders, you can just render to both buffers simultaneously (using gl_FragData[0] and gl_FragData[1] after calling R_EnableGlow), so there isn't any performance hit.
52
Artwork / Re: New Feature: "Glow" textures
« on: April 14, 2010, 04:36:15 am »
Okay, I've added some simple functions that allow (very limited at the moment) types of postprocessing for the battlescape. The only visual change the patch I just committed makes is that all "shell" effects will now have a basic "glow" effect (if postprocessing is turned on). There are several functions now that allow different ways of rendering "glow;" if you just want to render only to the "glow" buffer, you can do that with R_EnableDrawToGlow(). There's also the more general R_EnableGlow() which allows you to render to both the "standard" renderbuffer and the "glow" buffer at the same time. This is mostly only useful if you're using shader programs, in which case you can specify separate colors for gl_FragData[0] ("normal" buffer) and gl_FragData[1] ("glow" buffer). This is more efficient, because you can render to both buffers in a single pass, but is overkill for simple things like the shell effect example I've included.
Let me know what you think; Mattn, in particular, are the "R_Enable" functions I wrote the kind you had in mind?
Let me know what you think; Mattn, in particular, are the "R_Enable" functions I wrote the kind you had in mind?
53
Artwork / Re: New Feature: "Glow" textures
« on: April 12, 2010, 06:20:08 pm »
In terms of "number of textures loaded," it is possible to use an un-used channel of an existing texture to specify glow information (ie. the way I used the alpha channel of the globe textures for nighttime illumination). Do the standard textures make use of the alpha channel? Do the normal maps? If not, we could use one of those channels to specify glow. We would sacrifice the ability to specify glow color (we would just have to assume that the glow color was whatever color was present in the underlying "standard" texture), but it would mean we wouldn't have to store an extra texture in memory. The other potential downside of this method is that it requires us to use image file formats that support an alpha channel, and it can make it a pain to work with the images, since you have to separate the color channels from the alpha channel every time you want to edit the image, and then re-combine them when you're done. Just using extra image files for the "glow" textures is a lot more straightforward and will make like easier for everyone, but it does come at the cost of having to load the extra textures into memory.
54
Artwork / Re: New Feature: "Glow" textures
« on: April 12, 2010, 05:11:26 pm »
The two techniques actually differ most in terms of what types of visual effects they allow for. The HDR method allows for things like very brightly illuminated objects to "glow" when the lighting model calculates that the "correct" output value for a pixel is a higher value than can be displayed (ie. is greater than 1.0). The Tron method allows for specific objects (or parts of objects) to glow regardless of lighting conditions, simply because an artist specified that they should (ie. the glow is an innate part of the object, not a result of illumination).
For the Tron-style glow, how much work would be required would depend entirely on how much stuff we wanted to have glow
Essentially, for any object that should have glowy-bits, you would need a new texture associated with the "standard" texture for that object. Basically, this would work the same way that a normal-map works; just an optional extra image file with the proper suffix on its name. That extra image would specify glow in the same way that the "standard" texture specifies diffuse reflections.
The work I did in the geoscape is actually a mish-mash of the two types; the earth itself glows using the HDR method (if you rotate the planet right, areas like ice caps or deserts will show a slight "bloom"), but the glowing borders for the nation overlay uses the Tron method, and the atmosphere uses some of each.
BTW, I'm not that familiar with the battlescape rendering system, but I don't think we should really need to add support for new meshes or brushes or anything; all we need to do is allow matterials to be associated with a glow-map the same way they currently get associated with a normal-map.
For the Tron-style glow, how much work would be required would depend entirely on how much stuff we wanted to have glow
Essentially, for any object that should have glowy-bits, you would need a new texture associated with the "standard" texture for that object. Basically, this would work the same way that a normal-map works; just an optional extra image file with the proper suffix on its name. That extra image would specify glow in the same way that the "standard" texture specifies diffuse reflections.
The work I did in the geoscape is actually a mish-mash of the two types; the earth itself glows using the HDR method (if you rotate the planet right, areas like ice caps or deserts will show a slight "bloom"), but the glowing borders for the nation overlay uses the Tron method, and the atmosphere uses some of each.
BTW, I'm not that familiar with the battlescape rendering system, but I don't think we should really need to add support for new meshes or brushes or anything; all we need to do is allow matterials to be associated with a glow-map the same way they currently get associated with a normal-map.
55
Artwork / New Feature: "Glow" textures
« on: April 12, 2010, 04:23:57 pm »
I figured I'd post this over here, rather than in the coding forum, since it's really more of an art question.
I'm planning on introducing the ability to have real-time glow/bloom effects in the battlescape, similar to what I've done for the geoscape (see screenshot). The coding I can handle, but before that code is useful, it will require some decisions about how to use it with the artwork.
There are essentially two different ways that we can do glow. The first is to do HDR (high-dynamic-range) rendering, in which case things will "glow" when they're brighter than the maximum brightness that can actually be displayed by your monitor (ie. if the value for the red channel is greater than 255, the "extra" red will spill over into neighboring pixels on the display). This is how things work in the newer Halflife2 games, for example (though they do some other more complicated things as well, like adjusting the centering of the visible-dynamic-range on the fly). New art wouldn't be required immediately, but this would wind up changing the appearance of things that were already in the game. Given that the current textures weren't designed for HDR, this could create some issues that would require fixing textures and/or lighting to get things looking right again.
The other option is to do glow in a style that has come to be known as "Tron" style glow, since it was pioneered by the game Tron 2.0. The idea here is that you can associate an optional extra texture with a model, much like you would a normal-map, which specifies what regions of the model should glow (along with color and intensity). This wouldn't change the look of the game initially, but would require new art to define what should be changed and what should be left the same.
My personal preference is for the second option, at least initially (I may implement them both eventually), because it allows a much greater degree of artistic control, and I think it will fit well with the atmosphere of the game. Having the "bright green" portions of UFOs glow, for example, seems like a natural extension of the current artistic style. It would probably even be possible to have simple animations in which the glow-texture was varied over time, allowing things like pulsing or other fun visual effects.
The caveat, however, is that this would require new art. Any model that didn't have an associated "glow" texture simply wouldn't glow. This would mean that glow textures could be added slowly; the game wouldn't break because they weren't there, but new textures would have to be created before the new effects actually appeared in game.
Thoughts?
I'm planning on introducing the ability to have real-time glow/bloom effects in the battlescape, similar to what I've done for the geoscape (see screenshot). The coding I can handle, but before that code is useful, it will require some decisions about how to use it with the artwork.
There are essentially two different ways that we can do glow. The first is to do HDR (high-dynamic-range) rendering, in which case things will "glow" when they're brighter than the maximum brightness that can actually be displayed by your monitor (ie. if the value for the red channel is greater than 255, the "extra" red will spill over into neighboring pixels on the display). This is how things work in the newer Halflife2 games, for example (though they do some other more complicated things as well, like adjusting the centering of the visible-dynamic-range on the fly). New art wouldn't be required immediately, but this would wind up changing the appearance of things that were already in the game. Given that the current textures weren't designed for HDR, this could create some issues that would require fixing textures and/or lighting to get things looking right again.
The other option is to do glow in a style that has come to be known as "Tron" style glow, since it was pioneered by the game Tron 2.0. The idea here is that you can associate an optional extra texture with a model, much like you would a normal-map, which specifies what regions of the model should glow (along with color and intensity). This wouldn't change the look of the game initially, but would require new art to define what should be changed and what should be left the same.
My personal preference is for the second option, at least initially (I may implement them both eventually), because it allows a much greater degree of artistic control, and I think it will fit well with the atmosphere of the game. Having the "bright green" portions of UFOs glow, for example, seems like a natural extension of the current artistic style. It would probably even be possible to have simple animations in which the glow-texture was varied over time, allowing things like pulsing or other fun visual effects.
The caveat, however, is that this would require new art. Any model that didn't have an associated "glow" texture simply wouldn't glow. This would mean that glow textures could be added slowly; the game wouldn't break because they weren't there, but new textures would have to be created before the new effects actually appeared in game.
Thoughts?
56
Coding / Re: Improved 3D Geoscape Rendering [was: Nightime city lights in 3D geoscape]
« on: April 11, 2010, 08:23:04 pm »
Yeah, in those screenshots I agree; it looks less bright in mine. I guess maybe I should hard-code a value instead of using the standard "ambient" light as a baseline. I'll add a patch to the SVN in just a minute.
57
Coding / Re: Improved 3D Geoscape Rendering [was: Nightime city lights in 3D geoscape]
« on: April 11, 2010, 07:38:14 pm »
Here's another small patch; this one offers an improvement on rendering the earth's atmosphere, including both specular and diffuse styles of reflection/refraction. It also fixes an issue with the positioning of the moon.
58
Coding / Re: Improved 3D Geoscape Rendering [was: Nightime city lights in 3D geoscape]
« on: April 10, 2010, 05:06:05 pm »
@Mattn: I'll try to keep shader "varying" variables capitalized; I hadn't realized that was the style. With respect to the "convolution" shaders, you're correct that the current version only uses one of them. The others are there in case you want to play with the FILTER_SIZE macro; basically, using the larger filters gives better quality at the cost of performance. Actually, I think that probably the best way to do it would be to generate the shader code procedurally based on the FILTER_SIZE, which could possibly then be made into a user-changable option. I haven't done that yet, though, so I just included the extra shaders in case people wanted to try them out.
@Destructavator: Sorry about that; I hadn't realized that style of for-loop syntax was only introduced in C99. My compiler doesn't give me any sort of warnings at all, so I hadn't given it any thought. In the future, I'll be sure not to declare my counters in my loop statements.
Let me know if anyone runs into any other bugs or issues; in the mean time, I'll see if I can't do something about the sun specularity...
@Destructavator: Sorry about that; I hadn't realized that style of for-loop syntax was only introduced in C99. My compiler doesn't give me any sort of warnings at all, so I hadn't given it any thought. In the future, I'll be sure not to declare my counters in my loop statements.
Let me know if anyone runs into any other bugs or issues; in the mean time, I'll see if I can't do something about the sun specularity...
59
Coding / Re: Improved 3D Geoscape Rendering [was: Nightime city lights in 3D geoscape]
« on: April 10, 2010, 02:43:07 am »
Okay, a new version is now up at the patchtracker; I think it should fix the issue with different screen resolutions. Also, in the process of fixing that, I discovered that it didn't handle changing the screen resolution without a restart, so I fixed that, too. Now you can turn the post-processing on and off and/or change resolution, all with out restarting
Be sure to re-download the "common" textures, as one of them has changed; you shouldn't need to re-download anything else.
Be sure to re-download the "common" textures, as one of them has changed; you shouldn't need to re-download anything else.
60
Coding / Re: Improved 3D Geoscape Rendering [was: Nightime city lights in 3D geoscape]
« on: April 09, 2010, 08:18:32 pm »
I'll go ahead and disable specularity for now; to be honest, I don't really like the way it currently looks either. I think it looks nice from an oblique angle, but when the specularity is right in the middle of the view it looks wrong.
In terms of "earth from space has no specularity," it depends on the images you look at. For some examples of earth from space with specular reflection:
http://www.losgazquez.com/blog/wp-content/uploads/2007/12/earth-from-space.jpg
http://www.daviddarling.info/images/Earth_living_planet.jpg
http://researchpark.arc.nasa.gov/lecture%20series/images/Earth.jpg
http://www.softpedia.com/progScreenshots/Earth-3D-Space-Tour-Screenshot-5607.html
Also, note the atmospheric scattering in this one:
http://multimedia4everyone.com/faith_science_commentary/media/photo_earth-from-space.jpg
At some point, I'd like to improve the atmosphere rendering. I'm also not totally happy with the way the sun looks right now, but I can continue to work on those things; I don't think it's worth delaying this patch for them, I'll just make another smaller patch for them when I get around to it.
In terms of auto-detection, it should already handle the "unsupported" case; it's the "supported but unusable" case that I'm not sure how to test for automatically. If anyone has suggestions, I'm open to them.
In terms of "earth from space has no specularity," it depends on the images you look at. For some examples of earth from space with specular reflection:
http://www.losgazquez.com/blog/wp-content/uploads/2007/12/earth-from-space.jpg
http://www.daviddarling.info/images/Earth_living_planet.jpg
http://researchpark.arc.nasa.gov/lecture%20series/images/Earth.jpg
http://www.softpedia.com/progScreenshots/Earth-3D-Space-Tour-Screenshot-5607.html
Also, note the atmospheric scattering in this one:
http://multimedia4everyone.com/faith_science_commentary/media/photo_earth-from-space.jpg
At some point, I'd like to improve the atmosphere rendering. I'm also not totally happy with the way the sun looks right now, but I can continue to work on those things; I don't think it's worth delaying this patch for them, I'll just make another smaller patch for them when I get around to it.
In terms of auto-detection, it should already handle the "unsupported" case; it's the "supported but unusable" case that I'm not sure how to test for automatically. If anyone has suggestions, I'm open to them.