UFO:Alien Invasion
Development => Artwork => Topic started by: arisian 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 would vote for hdr - but i don't know the latter technique at all. if we decide to use the latter we can add support for the mesh models very easy, and for the brushes this should go via material system.
-
oh.. the reason why i would prefer the hdr stuff is that we don't require new artwork - we are already low on artists. so we should try to do things in a way that the existing people around this project can achieve to handle it. (again, i don't know what the latter render technique would need in terms of artwork to work and look good)
-
I vote for control over implementation rather than automated implementation (which is what I take the first method to be). I think such effects are great when used appropriately, but can be overused (http://www.playerzblog.com/wp-content/shadowgrounds_survivor_2007_06_12_shot02_800.jpg), like this (http://www.playerzblog.com/wp-content/shadowgrounds_survivor_2007_06_12_shot02_800.jpg), when every light starts to give off a ridiculous, un-natural glow. Such effects are, IMHO, best used for abstracted visuals, like the geoscape overlays. As I said, they can be used for cool effects in the battlescape, which is not supposed to have an abstracted sense of space (at least as much of one), but only in the right situations.
It's worth nothing that my opinion comes from someone who won't see the effects anyway, since I don't have a gfx card that supports that sort of stuff.
-
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.
-
I do not agree on this, Mattn :-[ ;)
Have you seen the pictures of how this tron 2.0 style looks like ?!
I think it looks great.
It is true that we do not have many graphic artists currently active, but we do not need everything glowing like in tron 2.0.
IMHO we should use this just for specialFX, Alientech & other futuristic stuff, but most of the stuff currently on the maps would not glow. Adjusting some textures to make glow-texture-overlays should not be such a hard task with those few high-tech textures we currently have. I am speaking out of experience here, just having created 3000 animation frames ;)
Also these maps should not be to complicated to make IMHO, because as I understand they wouldn't even need to be seamless as long as the glowing is happening somewhere 'inside' of the overlay...
I do not know how it looks with our models though ::)
I think this would fit to the new animations & we should think about how to best combine all this stuff ;)
& regarding the lacking forces helping this project out I already wrote a feature request, but this is offtopic here ;)
arisian could you please take a look @ the animations I made & tell me how we could combine our workforce ::)
-
btw, I think one very important feature regarding the battlescape is currently missing - the models do not have shadows, this bugs me a lot, because sometimes they just look like 'copied in'. If you could take a look @ this issue also, arisian, that would be a big hit IMHO...
-
@Mattn: You told me something about 1024 texture slots for the whole game including geoscape. I do not know about those limits, maybe you could elaborate on this, because I think I am running into some kinds of limits with the animation frames already & with additional overlay-textures we would fill our available slots pretty fast... ::)
-
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.
-
AFAIK the normalmaps use the alpha channel to store the height information & my animation frames all use the alpha-channel, but just to 'hold the overlays in the correct position' (meaning the alpha channel is more or less empty)...
-
The standard textures do not make use of the alpha channel @ all ;D
-
Maybe we could define the color of the glow via the material system, like Mattn already suggested, just like we currently define the color of a flare ::)
-
btw, here is a link to the game arisian mentioned, showing the gfx fx quite nicely:
http://www.youtube.com/watch?v=P0tSo1xldRc&feature=related 8)
-
I wanna note here that these are quite impressive effects even without detailed textures (this is rather old stuff), you have to imagine this style combined with normalmaps & highly detailed textures & animations ::)
I think this could upgrade our graphics in a massive way, when used wisely (just for future-, alien- & spacetechnology), but I also can imagine tuning the coming modern 2084 cities with these glow effects to make them look more futuristic ;)
-
'I Am A User !' ;D
Some more from Tron 2.0 & its lightFX:
http://www.youtube.com/watch?v=OiLA1q4ky-c&feature=related
-
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.
ok, go for the second option then. also see about the shell effect in r_state.c - this is already something like that and could be extended a little bit to add a glow imo.
-
ok, go for the second option then. also see about the shell effect in r_state.c - this is already something like that and could be extended a little bit to add a glow imo.
Juhu !!!!!!!!!!!!!
Sorry, I meant YEAH !!! ;) :D ;D :)
-
The standard textures do not make use of the alpha channel @ all ;D
Standard textures can use an alpha channel now. The rendering at distance is a bit odd (doesn't seem to blur properly), but I assume this will be fixed some day and having the alpha channel will be important for things like hanging wires, metal wire fencing, etc.
-
Standard textures can use an alpha channel now. The rendering at distance is a bit odd (doesn't seem to blur properly), but I assume this will be fixed some day and having the alpha channel will be important for things like hanging wires, metal wire fencing, etc.
But do our standard textures we have @ the moment use the alpha-channel ?! I know that the ufo*.* textures do not use it.
You are very right regarding the things you mentioned, but when we use the material system to define the textures which should glow, there should be no problem with having other textures, which have an alpha channel used for transparency for example or for other things on the same map without interfering ?!
But I am not an expert on this. Maybe arisian could answer this, so we can be sure...
-
arisian, if you are implementing this, please try to add it for brushes at first, and incorporate it into the material system. so we can define it on a per-texture basis. skip it for meshes first, i have a pending patch for some kind of shader/material system for meshes, too. your interface should be generic enough to handle both cases. see the existing stuff in r_state.c those R_Enable* functions - please try to keep that pattern.
-
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?
-
yes thanks, the R_Enable* stuff is what i had in mind, it should be quite easy now to get this into the material system, too
but please always test different resolutions - it's not working for 1024x768 - the render buffer is too small and the position of the glowing entities is wrong, too.
-
noticed another small bug, glowing models are shining through other models - but not through brushes.
-
I realize we're still talking about general implementation technicalities and not about actual use, but I'd still like to point out that civilians should not glow red. Red is associated with enemies (a good example of this is Assassin's Creed's eagle vision). Aliens should glow red, civilians blue.
-
Good idea, BTAxis, I agree.
But I suppose this will be no technical problem @ all.
I just wanna also note here that it 'feels' a little unnatural if we have IR-googles, which should enable us to look through walls, but the shell effect does not shine through...
Maybe it should shine through the walls somehow ?!
-
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.
-
in general all screen width and height should be based on 1024x768 - and videf.rx, viddef.ry should be used to get the correct values. in the shaders we already have r_width and r_height as defines (see r_program.c line 276ff) - more could be added as needed.
about the rendering order or not used depth buffer (or whatever the cause is) - skip it maybe for now - the other bug is more important ;)
@BTAxis about the color - this is work-in-progress.
-
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.
-
I've not read the whole thread but glow maps are really really easy to make and I think they are a lot less performance killing than any sort of HDR.
-
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.
-
Okay, I've got a basic proof-of-concept for glowing textures associated with meshes. SVN r29460 contains the new code, along with a new image, base/models/weapons/plasrifle/plasrifle_gm.png. The texture I've included was made very simply; I just copied the standard texture, did a color-select on the blue parts, and painted everything else black. I also reduced the intensity somewhat. I'm sure that our artists can do better than this, but my goal was just to demonstrate what was possible, and how easy it should be for the artists. All you need to do is have a glowmap texture associated with any standard mesh texture. If the mesh is called <modelname>.jpg, you just need an image called <modelname>_gm.jpg (or .png or whatever) in the same directory. It will automatically be loaded and interpreted as a glowmap, in much the same way that a normalmap would work. Currently, glow-maps will only get renderd when they're associated with meshes, but it should be fairly straightforward to extend the system to other types of surfaces as well.
Again, adding a glow texture doesn't require any changes to code, or the model, or anything; just drop an image with "_gm" at the end of the object's name ("gm" for "glowmap"; we can change the abberiation if people don't like "gm"), and everything else should be handled automatically.
-
Great News !!!
-
Pretty slick. There are a bunch of meshes that could benefit from this.
-
Looks good Arisian. I've got a non-mesh texture that I'd like to use this on (http://ufoai.ninex.info/forum/index.php?topic=4686.msg36904#msg36904) in the future when (if?) it gets extended to the material system for map textures. Would it help you if I supplied a test map/textures to work with for this?
-
Maybe it is my fault, but I compiled the latest rev & now all models seem to glow ?!
-
MCR, are you getting any abnormal output in the log? It works fine for me, but I only have one system to test on. Have you tried doing `make clean` and then re-building everything?
Oh, also, I've just noticed that using the IR goggles seems to de-activate the mesh-glow, though the mesh-glow resumes as soon as the IR-goggle effect stops. I'll look into why, but it shouldn't be a show-stopper in any case. Should be fixed now.
-
I recompiled (now 29465, before 29460), but only tested this on one computer also. I did not compile the maps.
& yes, I have a strange output in the ufoconsole.log:
R_ProgramVariable: Could not find GLOWMAP in program mesh (some hundreds of lines of this error)
I hope this helps...
-
MCR, could you attach the file "base/shaders/mesh_fs.glsl" that you have right now?
-
Here:
-
It doesn't look like your copy of mesh_fs.glsl is the latest version. Have you made any modifications of your own to that file? If not, try deleting it and then doing an "svn update" to make sure you've got the latest version.
-
Okay, but I did not modify anything there ???, somehow the svn update did not update that file... Thanks for helping.
-
i suppose it shouldn't look like this :)
-
Um...wow. How on earth did you get that? It's actually kind of pretty...I've got no idea how that "rainbow" effect is happening. Is it constant, or do the colors change? Are you getting anything in the log? And are all the shaders up to date?
-
LOL! looks like the commander is TRIPPING! ;D
EDIT: Also, RAINBOW COW! :D
-
I would just like to say it's looking fine here.
-
Now my version also works perfectly... :)
The problem was that I had decompressed old versions of the shaders in base :-[
Looks very nice.
IMHO this glow could help us push this game into 2084 big time ;D
Top Work, arisian, & btw. all my questions seem to be answered ;)
-
Easy way to test this is to use the weapon-set of alien soldiers 1 ;)
-
Okay, glowmap textures should now be used for materials and surfaces as well as meshes. Screenshot attached; note the glow from the top rack of magazines, and the glowing spot on the grass texture. Note that I have not added these two glow textures to the SVN, as they are not at all useful or appropriate; they were just a proof of concept. I'll attach them to this post, along with a screenshot, in case anyone is interested. Now it's up to the artists to start making glowmaps (and everyone else to beta-test and report bugs in the new features) :)
-
Thanks Arisian. That's great, and easy to implement from the mapper's side.
-
Shouldn't the material system documentation (http://ufoai.ninex.info/wiki/index.php/Mapping/Materialsystem) be updated?
-
At the moment, this isn't really integrated with the material system; glow-maps are associated with textures, not materials. Being able to specify more detailed things about glow in the material system would probably be useful, but I haven't done that yet.
The material system docs should probably be updated, as should the modeling docs. Also, most of the code I've added has some comments, but could use more, and in general would probably benefit from some cleaning and/or refactoring in places, both for clarity and for optimization. I wouldn't call any of it "production-ready" code at this point, but it should be enough to let people start figuring out what they can do with it, and what needs to be changed/added so the system accomodates their needs better. If you want to document things, be my guest ;) otherwise, I'm inclined to wait until I'm more confident that the code has stabilized before doing lots of documentation.
Artists, modelers, and mappers; if you'd like to be able to do something related to post-processing and can't figure out how, let me know and I'll see how difficult it would be to add. I welcome feedback about what you do/don't like about the new system; now is the time to comment, while it's still new and flexible.
-
Hey arisian !
Thanx for this great addition here...
Great effect !
Have to experiment & figure out how to combine the glow with the animations of the material system in the best way now... ;) ::)...
-
Materialsystem-animations still working & are fully functional, so both fx can be applied @ the same time... 8)
-
The problem with the animations is just that they 'disappear under the glow'...
I am sure there is a possibility to make the glowmaps glow less with manipulating the glowmap with GIMP, but what I really would like to see would be an addition to the material system to make 'glowmap animations' instead of using the normal property textures...
I hope this is somehow understandable here... ::)
If you look @ tex_ufo/ufo2_06a0 (currently in trunk) for example. The glow looks great, but it would be nice to make the animation with the glow-map instead the property texture, because now the glowmap 'swallows' the button animation...
This would also add enourmously to the graphical quality of the animations if not only standard but glowing ones would be possible too (not only pseudo-glow with removing lightmaps from property textures) ;)
I will attach some pictures to explain what I mean ;)...
-
I hope you understand what I mean, arisian... ::)
When we have separated button-animations for example already finished (without the 'skins' around them), we already would have perfect glowmap-animations available if the possibility would exist to define those animation frames themselves as glowmaps...
I hope you understand & make this possible ;)
Here an example of a 'already finished' glowmap animation:
-
I'll work on trying to integrate the glow-maps better with the matterial/animation system, though it may take me a bit to get around to it. I'm not familiar with the animation system or how it works, so I'll have to learn how it works before I can effectively modify it.
-
btw, I do not feel like a artist, modeler or mapper, but just like someone who wants to use his allround-talents & skills to improve this project on all fronts...
But I still felt like I had to answer your call for feedback ;)
Thanx again for all those features, I tell you the geoscape looks so great in addition with the ultra mod ;), I still do not know if I do not want all 12 seasons back ;)
Mattn, I have not written this :-[ ::) ;) :D ;D
-
I'll work on trying to integrate the glow-maps better with the matterial/animation system, though it may take me a bit to get around to it. I'm not familiar with the animation system or how it works, so I'll have to learn how it works before I can effectively modify it.
YEAH, sounds good to hear that.
I would like to help you, but I just can tell you stuff you already know for sure, so I will :-X
Just one thing, I am sure you already know of is that doxygen stuff:
http://ufoai.killfile.pl/doxygen/
I find that nice.
-
Okay, I think that the frame-based animations should work with glow now. Each frame of the animation can have its own glow-map, which will be applied when that texture is used (based on the animation sequence/timing parameters). Transform-based animations (eg. rotate, pulse, stretch, etc.) aren't implemented yet. I haven't done extensive testing, though, so let me know if you run into issues.
-
Arisian, that is important !
IMHO we do not need extra glowmaps for each frame of the animation !
With the layered animations we can make the animation frames BE the glowmaps IMO...
Don't you think so ?
When we have a base texture with a screen & buttons for example & we have property texture animations that are separated from each other we can have a normal screen overlay animation for the screen & use the buttons overlay animation frames as glowmaps themselves...
Or is this not better than having to load all the additional glowmaps into memory ?
-
At least some of the transformations should now work; I briefly tested rotation, scrolling, and pulsing, and they seemed to do more or less what was expected. I'm going to bed now; I'll work on it some more another day.
-
Here is a small glow patch for the U.F.O.-Fighter:
1st Picture=Screenshot In-game
2+3=base/models/aircraft/ufo_fighter
-
Here the last ones for the fighter...
-
Engine Upgrade for the Supply Ship or 'Glowing In The Snow'...
First 2=base/models/aircraft/ufo_supply
Picture 3= Screenshot in-game
-
Proud To Present:
'The Glowing Scout'
-
At first — wow and thanks.
At second, will this work without GLSL? I can`t enable it and can not switch any of hardware because it is computer at work.
At third — MCR, your scout and fighter is very bright, you should make it less intensive.
-
I think I love this Tron 2.0-Oldschool-Style-Glow... :D ;D 8)
-
@Kildor: These are raw first versions, now that everything is cut out they are easy to manipulate & experiment with...
Feel Free To Do So ;)
-
IMHO our small U.F.O.-models should be upgraded not only with new textures in the long term...
-
shit, torrents of flood and nothing more.
-
Um...wow. How on earth did you get that? It's actually kind of pretty...I've got no idea how that "rainbow" effect is happening. Is it constant, or do the colors change? Are you getting anything in the log? And are all the shaders up to date?
recompiled (clean build, no changes in svn) - up-to-date shaders, colors are changing. nothing in the logs - all in all no useful bugreport ;)
i will try in the evening with the latest changes.
-
it would be nice if the GLOW in the shaders would be a float and would be controllable via material system parameter - because the mapper might want to decrease or increase the glow strength on a per-map-basis without changing textures. would that be possible?
-
I agree with Kildor, MCR, it would probably be best if you made the glow a little less bright.
-
No problem, I just cut out the glowing parts from the original textures here & did not change anything, to change the brightness is a job done in a few minutes when having the cut-outs. I have not time to do this right now, but I can try to do the adjustments in the evening if that is okay...
-
arisian: By the way, is there any way to control the extent of the glow itself, i.e. how far outside the glowing pixels the pixels will get shaded?
-
it would be nice if the GLOW in the shaders would be a float and would be controllable via material system parameter - because the mapper might want to decrease or increase the glow strength on a per-map-basis without changing textures. would that be possible?
I think indeed that is the best idea regarding the glowing-strength ;)
Maybe it would be nice also to be able to have the glow-strength fluctuate a little bit over time, so the effect would be even better...
-
Another question. Could the glow post processing be applied to particles? I think the plasma and PBW particles could benefit from glow postprocessing.
-
Well, I feel bad throwing another feature request at you now that everyone's got another request for the glow system. But that's a sign that everyone really likes your work arisian (including me).
The request I'd like to add is to be able to specify the intensity via the material system (as Mattn describes using a float), but to have separate values for day and night. Things glow depending on the relative light value of things around them, so I'd like to be able to specify a big glow for night but just the tiniest glow for day.
Thanks again arisian.
-
Wouldn't that effect already be there what with the lightmap?
-
Well, I feel bad throwing another feature request at you now that everyone's got another request for the glow system. But that's a sign that everyone really likes your work arisian (including me).
The request I'd like to add is to be able to specify the intensity via the material system (as Mattn describes using a float), but to have separate values for day and night. Things glow depending on the relative light value of things around them, so I'd like to be able to specify a big glow for night but just the tiniest glow for day.
Thanks again arisian.
that's not something for glow in particular, that's something i will implement for all material settings.
-
Wouldn't that effect already be there what with the lightmap?
I have to admit I don't understand what lightmaps do. The materialsystem documentation on the wiki is kind of sparse for the non-techie. I don't know what "statically computed lighting information" is, where it's computed from or what it's meant to do. Mattn told me to remove the lightmap from my adverts to make them light up, but from the description it sounds like it the lightmap stage should be there to make them light up.
that's not something for glow in particular, that's something i will implement for all material settings.
Great! I was hoping for this.
-
I have to admit I don't understand what lightmaps do. The materialsystem documentation on the wiki is kind of sparse for the non-techie. I don't know what "statically computed lighting information" is, where it's computed from or what it's meant to do. Mattn told me to remove the lightmap from my adverts to make them light up, but from the description it sounds like it the lightmap stage should be there to make them light up.
the lightmap is computed on a per-surface base for your map. think about it as a second texture layer that is added to those textures you've applied to surfaces via uforadiant. the normal surface texture and lightmap data (which is a special encoded image) is blended onto each other. in most cases the lightmap will add shadows to surfaces. thus in a dark area you can make one particular surface standing out a little bit brighter if you don't blend the lightmap onto the texture.
If this makes things clearer for you, please extend the wiki with your own words - others might have the same problems with the existing description - and if you have more questions or problems with this explaination, please don't hesitate to ask.
-
the lightmap is computed on a per-surface base for your map. think about it as a second texture layer that is added to those textures you've applied to surfaces via uforadiant. the normal surface texture and lightmap data (which is a special encoded image) is blended onto each other. in most cases the lightmap will add shadows to surfaces. thus in a dark area you can make one particular surface standing out a little bit brighter if you don't blend the lightmap onto the texture.
If this makes things clearer for you, please extend the wiki with your own words - others might have the same problems with the existing description - and if you have more questions or problems with this explaination, please don't hesitate to ask.
Possibly, let me see if I've got it: To generate the appearance of light on a surface, it blends an image of light and shadow onto the existing texture. By removing the lightmap from any material stages, it makes the staged texture appear with no lighting on it (because it's usually shadows, therefore, it usually brightens the texture). Is that correct?
One more question, then I'll edit the wiki and stop sidetracking this thread: If I have a material definition without any other texture blending going on, should I still include the lightmap parameter in the material, or does this only effect the blend stages? (ie - if a material without any stages doesn't have the lightmap parameter, will no lighting appear on it? I ask because many of my materials don't have the lightmap parameter but I haven't noticed that they "lack" any lighting...)
-
depends - for normal texture blending this isn't needed, but it's e.g. needed for terrain and dirtmap afaik (but i might be wrong here)
if the wiki isn't clear about this i will have to extend it i suppose ;)
-
Wow, glad to see all the interest here!
I'll try to answer the questions I've spotted:
1.) None of the real-time glow stuff will ever work without GLSL. There's just no way to implement those features without using shader programs (in particular, for the postprocessing step itself). The only thing you can do without shaders is make sprite-style "glow," by slapping a transparent texture with pre-rendered glow effects on top of an object (this is the way the halos around lights are done now, as I recall).
2.) Having a parameter that lets you control intensity in the material shouldn't be too difficult; "pulse" animations already adjust intensity on the fly, and it shouldn't be too hard to add a parameter to control the "base" intensity to the .mat file. By the way, the "pulse" effect should already allow glow to fluctuate over time. The stretch, rotate, and scroll effects should work with glow-maps, too.
3.) There's no reason glow couldn't be applied to the particles. Essentially, if you want something to glow, you just need to make sure the "glow" part gets rendered to the glow buffer, and everything else is taken care of by the existing post-processing code. I know nothing about the particle system, so we'd have to figure out how glow should be specified there.
3.) The glow "radius" is something which can be adjusted in the code, but not on the fly (at least, not at the moment). Reducing the intensity will reduce the effective distance that it spreads, though. In terms of what the glow radius is, there's a tradeoff between performance, quality, and size. You can adjust any one of those three parameters, but doing so will affect the other two. For example, right now there's a sort of "sparkle" effect to the glow when you move the camera, particularly if you have small, bright spots of glow. This is essentially an aliasing artifact; it's easy to reduce, but doing so would either decrease the glow radius, or increase the computational cost of doing the postprocessing. If you want to play around, look at the DOWNSAMPLE_PASSES and DOWNSAMPLE_SCALE macros in r_state.h, as well as the FILTER_SIZE macro in r_program.c
4.) I'm disinclined to decouple glow-maps from normal textures too much, so I don't want to have one-to-many mappings (ie. one "normal" texture with several "glow" textures for animation frames). However, I think it should be possible to add a material parameter that would cause the "standard" textures to be rendered to the glow-buffer. This would let you have only the textures you needed for your animation frames, if I understand what you're asking for.
5.) Mattn, I've got no idea what's going on for you; let me know if you figure anything out, or want help.
If I've missed any other questions, I appolagize; there were a lot of them :)
-
Wow, glad to see all the interest here!
5.) Mattn, I've got no idea what's going on for you; let me know if you figure anything out, or want help.
that's because we all like what we are seeing from your work ;)
i'll try to recheck in the evening when i'm in the hotel and let you know about any problems (if there are any left after your latest changes).
-
Okay, glow-map intensity can now be scaled in materials. The parameter "glowscale" is what you want to set; it will be multiplied, so 1.0 is the default. 0.5 will mean half intensity, and so forth. The glowscale parameter can be applied either at the material level or at the stage level; if it appears in both, they will be multiplied to get the value used for a given stage. As an example, in the following material, the texture "grass_gm" will be multiplied by 0.1 (since 0.5 * 0.2 = 0.1) when it is being rendered to the glow-buffer. Note that this only works for materials; this won't let you scale the glow on models or surfaces, for example.
{
material tex_nature/grass001
hardness 0.2
specular 0.2
glowscale 0.5
{
texture tex_nature/grass
dirtmap 1.0
lightmap
glowscale 0.2
}
}
-
please also add that information here: http://ufoai.ninex.info/wiki/index.php/Mapping/Materialsystem
-
Great, easy to use.
-
retried latest revision - same result (or better, even worse, because now all brushes (regardless whether they have a glowmap or not) are now glowing. no warnings on the console, shaders compile fine.
it's an ati card (mobility radeon hd 4670), gl version 2.1, glsl version 1.4 - fglrx driver.
-
Mattn,
Try applying this patch, and then post the output for me. I'm thinking that maybe somehow the glowmap pointers that should be NULL are winding up pointing to arbitrary memory on your system; that would account for everything being glowy (since the pointer is used to check if a glow texture exists), and it would also account for the rainbow-colors (since the contents of that memory segment would be arbitrary). I'm not sure exactly how that's even possible, but that would be my best guess at a cause. Actually, why don't you post your copy of r_image.c while you're at it, just so I can make sure nothing odd is going on.
-
here is the log
-
oh, and no local changes here - so my r_image.c is the one that is in the svn
btw. did you revert my changes for glow map loading for it_world and it_skin intentionally?
-
Yes, I did revert those changes because they were preventing the loading of other types of glow-map images that we wanted. Also, as I recall, the way it was written it didn't actually load glowmaps for it_world images, either (because it was an "else if" clause after one that had checked for it_world). At the moment, I don't see the harm in testing for glowmaps for all images; we might want them eventually. If you'd like to add some restrictions back in, we can do so.
And your logfile seems normal as far as i can tell, which means I'm still stumped by your magical-rainbow glow.
-
i will try to run valgrind on a map with postprocessing activated - will keep you informed
-
I made a (decent) glowmap for the interior of the Herakles dropship (base/models/aircraft/drop_herakles).
Attached is the 'posterized % color-palette reduced version' of the glowmap already (reduced size from 6.62 to 1.83 kb):
-
Some other important information for the glowmap makers out there ;):
If you want to influence the glow via the glowmap texture it makes no difference which brightness the colors have there (on my computer).
You can influence the color of the glow though with the colors you choose in your glowmap...
If you want to make the glow less intense via the texture you have to delete some pixels in your glowmap or make the glowing areas smaller...
Here a example of this:
1st picture: appearance in-game
2nd picture: glowmap of the fighters engines
-
I will adjust the glowmaps of ufo-fighter & ufo-scout for the default glow-strength of 1.0 to make them glow less intense & more detailed & will also use the method described in the post below to optimize their filesize ;)...
-
Important Information II:
Everyone making glowmaps should use the posterize function of his/her image-editor to reduce the colors effectively used by the glowmap.
As the brightness of the colors does have no effect in-game on my computer @ all, even the most complicated (rainbow) glowmaps should never have to use more than 256 colors...
So after posterizing your glowmap you should reduce the color-palette used to @ least 8bit = 256 colors.
This will help us reducing filesize needed by our glowmaps in a massive way.
Most of the glowmaps will use less than 10 different colors I suppose, our green fighter-engines glowmap for example can be reduced from 24 to 2.78 kb (!) using this method without changing the effect in-game...
With this optimization our glowmaps will be loaded into memory real fast ;)...
-
Actually, the brightness of your texture *will* affect the brightness of the glow. As an example, take the following two screenshots; the only difference was which version of the plasrifle_gm texture was used. As you can clearly see, the glow is brighter in the second screenshot, due to the fact that the colors in the glowmap are brighter in the second version of the texture.
It should still generally be possible to reduce the colorspace, given that the majority of models shouldn't have that many different colors of glow (Mattn's computer aside). If you're using PNGs, there are even automated tools that will do the colormap for you (eg. pngrewrite).
-
Hey arisian,
really great work you delivered here. Fun to play with. ;)
Sorry if I misinterpreted my first test results... :-\ But this is my experience on my computer here.
I did not fake those pictures here, I swear ;):
http://ufoai.ninex.info/forum/index.php?topic=4674.msg37078#msg37078
:-[
Nevertheless I am sure that you are right, but IMO it is still a good idea to reduce the colorpalette of the glowmaps to make them small & fast to load & this automated tool you mentioned can be very interesting. I will check that one out...
Now I do not know what to do with my previous posts regarding this, because I do not want to create false myths about this here ::)...
-
I downloaded your plasma-rifle glowmap pngs to check them out & they do not have an alpha channel ?!
-
arisian, it would be very nice if you could test the fighter_engines_gm.png from my above post on your computer, then I will know for sure that something is wrong here :-\
-
Glowmaps don't need an alpha channel. The brightness of the texture is the glow intensity (so black is no glow).
-
Here is the latest version of the U.F.O. Scout (color-reduced, palette-reduced ultrasmall filesize glowmaps).
I also looked @ the suggestions that came from BTAxis & Kildor & reduced the glow to make it less intense...
Also I deleted the glow from several buttons to make the glow effect look more diverse & interesting there...
It would be nice if someone could test this:
-
Thanks for the info, BTAxis, good to know that...
Here those glow-maps in-game:
-
I do not know what I did wrong ???, but these glowmaps are used by the game for sure (when I rename them the glow is gone), look real fine in-game & have together less than 4kb (to make the whole ufo-scout glow(!))...
So arisian, you promised a cheap effect (ressourcewise) & imho you delivered that ;)
-
BTAxis is right, there's no need for an alpha channel for the glowmaps. MCR, it's possible that the alpha channel is the reason that you thought that the color intensity didn't matter. If you're using the alpha channel to change the "intensity," then the actual color values of the pixels haven't been changed at all, which is why it doesn't look any different in game. If you just work in RGB (instead of RGBA), you won't have that problem.
-
Arisian, please do not misunderstand me. For me this is no problem @ all. I just want to find the best method ressourcewise to build these glowmaps. So if the small color-reduced glowmaps are working fine in-game, I will continue to make such & if we can save additional space by removing the alpha channel I will do so also...
Could someone here do me a favour & test those scout glowmaps I posted, because maybe they somehow just work fine here on my machine...
-
Color-mapped PPMs work fine for me (your new scout-glowmaps work just fine).
-
Color-mapped PPMs work fine for me (your new scout-glowmaps work just fine).
I am so glad to hear that. Thank you very much for testing it.
BTAxis, is the intensity of the scout glow & overal appearance okay in your opinion ?
-
Here comes v2 of the Fighter (reduced glow, small files):
-
Here in-game:
-
& The Supply Ship:
-
I must say those seem to have turned out very very nice.
-
;D
The Supply Ship needs 1.09 Kilobyte of glowmaps to glow :) :D ;D
-
Somehow i think that the glow effect is still to bright(?)
-
i love this kind of very discreet aircraft. Maybe nobody can detect them in the sky, especially the night.
-
@bayo: The aliens only turn the lights on when landing somewhere & turn them off while flying ;)
-
Alien Barrel & Alien Battery:
-
Alien Panel & Seat:
-
Personally, I think that some of those textures may still be too bright, while others are looking good. The "seats" looks like a nice subtle effect from the screenshot; the ship exteriors are probably still a bit too bright (the fighter in particular). The issue is not so much what the maximum intensity is, but that the intensity is so uniform across the ship. I think it would be more interesting to have, for example, the engines be fairly bright, with the rest of the green parts having a more subtle, dull glow; maybe weapons could be intermediate, or something. But this is all really just a matter of aesthetics and personal opinion. As you said, anyone can edit the textures to change brightness, distribution, etc. In fact, I may poke at some of the textures myself at some point; just not tonight.
-
May be we should pause feature-additions? We *must* release 2.3 in near future. May be mattn has other opinion, but I guess we need branch 2-3-stable and only after that add this major functional to the trunk.
-
It is only textures, right? then its only a polishing. Designers can validate it easily.
-
not only textures but also renderer itself. And whole GLSL system.
PS: btw, I`ve got an repeated error in console when start a mission (2010/04/21 15:20:27 R_ProgramVariable: "GLOWMAP" - No program bound.
)
-
May be we should pause feature-additions? We *must* release 2.3 in near future. May be mattn has other opinion, but I guess we need branch 2-3-stable and only after that add this major functional to the trunk.
/offtopic on
there are still texts missing for the ufopedia - i've asked for them a few weeks now but got no feedback from Winter or BTAxis, as long as they aren't there we can't release 2.3. And adding some eye-candy features that can be deactivated by cvar is a good thing imo. Also due to the new features (glow) some shader bugs were fixed. I don't like the idea to branch until we are feature complete (in terms of missing content/ufopedia articles) - because time is already something i don't have much of in the last few weeks, i don't want to waste even more for merging in-between branches.
and new textures are not really new features. once we have the content we have to give the translators a few weeks to finish the translations, but i will create the branch once this is done. merging the translations back into a branch is an acceptable "waste" of time.
@kildor, this is something we should discuss on the mailinglist and not here by hijacking other threads imo.
/offtopic off
-
@bayo: The aliens only turn the lights on when landing somewhere & turn them off while flying ;)
That would actually be against what I'm guessing they are (and what is the most logical conclusion for what they are IMO): heat radiators, designed to keep the ships critical parts (engines, weapons, cockpit) from overheating. In other words, they have to keep them on while flying, otherwise their ships would just melt. On ground they don't have to glow but you can easily say that they keep the ships electric systems online (engines need cooling then) and radiators are also precooling everything to lessen the load on take-off. Crashed ships on the other hand shouldn't have them on or have them very dim.
And as arisian said, have the engines and their immediate radiators shine brightly and the further you go from there, the dimmer the color will be. Weapons should have fairly bright radiators too, as melting particle beam cannons can be rather dangerous and, at the very least, inaccurate.
PS. They look great! :)
-
/offtopic on
Have you ever seen thiz before ? ;D
There were some errors regarding filenames & also errors in the ufo scripts, I will correct this & prepare a patch ;)
/offtopic off
The glowing eyes are for this topic :-[ :D :) ;) ;D
-
are those glowing eyes a bug? i like them =).
btw. i like all your new textures and "glow"textures. good work mcr and arisian.
-
One who already glows & another one who could need some (very decent ;)) glowing...
-
I agree with Bayo - I like these glowing effects very much, as long as they're cool "accents", so please don't misuse (overuse) it!
Glowing engines - great, may be additional some small (!) spots related to the weapon systems, but that should be mostly all for the UFOs.
-
hm... until now i like all glow-effects (as i said). just some are maybe a bit too bright, but mcr is getting better with that.
there are many things that can use glow even police cars. there can hardly be too much glow - i think only the brightness makes a glow "bad" or "good" (the game tron is an very very good example of bad =)).
to be safe a slider like gamma-correction would be great but not really a must have.
edit: the idea to make the barrel glow is more than great btw. - makes "the other" textures look really old =).
-
Thanks, bartleby.
/offtopic on
Has someone of you ever seen Ortnoks in light or medium armor in-game like in those posts above, or has someone ever seen one-eyed Ortnoks in-game ?
/offtopic off
-
I am currently preparing a (very decent & subtle ;)) weapons glow update patch & wanted to share some impressions with you folks...
Comments are very welcome !
Please do not forget to also answer my question if you have ever seen Ortnoks with light & medium armor or one-eyed Ortnoks in-game !?
I will post a pk3 for the weapons-update as it will be easier for Mattn to integrate the files ;)
I will also try my best to look @ all the suggestions presented here to make v3 of the U.F.O.-models-glow perfectly (less uniform & generally more decent glow) & will prepare a patch for those also, but this might take some time... ;)
Here some screens of actual glow-textures-work:
-
Ammunition, MedKit, IR-Googles & some more weapons...
-
i don't think that everything should glow - e.g. who would take a medikit into a battle that is given the position of the solider because it's glowing?
-
Medikit glow will be deleted ;)!
-
all i wanted to say is "just because you can .... you maybe should not in every case ;)"
-
I know, Mattn. If you believe it or not. ;)
Now that I know how I can control this glow almost perfectly from the texture side my experiments are beginning to get professional ;)
You can add so much to those textures if you make just some leds (pixels) glow...
-
I also reduced the glow from the particle beam & plasma weapons already in trunk (thanx BTAxis for the cutouts) to make the glow more detailed & subtle there...
I hope this is okay for you BTAxis... :-\ :-[
-
A glowing gun ought to increase the chances of being hit from a distance. They look very nice, I just don't think anyone would ever build a tactical weapon like that. The army does whatever it can to eliminate muzzle-flash, for instance. Being aliens though, maybe they haven't read Sun Tsu's Art Of War and all the old tricks are new again. Maybe that's the way to beat them, we could build a giant wooden rabbit...
-
A pk3 patch for the weapons has been sent to Sourceforge.
I hope you all like the new, upgraded weapons like I do, although they might not be 'realistic' whatever that may mean in a game with plasma blasters, laser pistols, particle beam cannons, U.F.O.s & aliens ::)...
Here are the raw & unedited cut-outs (maybe incomplete) in xcf file format, if someone wants to play around with them... ;) :
http://www.mediafire.com/?yiienjyjm4h
http://www.mediafire.com/file/yiienjyjm4h/WeaponsGlowmapsXCFSource.7z
(doublechecked, should work...)
-
MCR, can you make the glowmaps that are along the barrel/muzzle flare brightly when the weapon is fired? Since, if following my heat radiator explanation, those glowy parts on plasma and particle weaponry that are along the barrel would glow because they are working to prevent the meltdown of the weapon. So, when fired, they would do extra work when they try to remove the heat from the discharge.
Think of it as an alien version of muzzle flash.
Being aliens though, maybe they haven't read Sun Tsu's Art Of War and all the old tricks are new again.
I doubt they have read any of their own warfare books either, if they have even written any. Maybe that's why we humans are beating them.
-
Maybe that's the way to beat them, we could build a giant wooden rabbit...
XD good one dude lets do it
-
i've reworked some parts of the glow management, looks like i broke the material glow with it, but at least it's no longer glowing everything now, the mesh glow looks fine now on my hardware, geoscape, too.... feedback is welcome. are you getting brush glows?
-
I'm getting some brushes that glow and some that don't in the latest version, though you and I have been messing with a lot of the same stuff in our parallel efforts to fix the same problems, so I'm not confident that the issue isn't on my end. Out of curiosity, what did the issue turn out to be? That way I can be aware of it in the future.
-
some state related bugs, some stuff wasn't deactivated properly - that's why i was trying to put it into one function. but it looks like i still didn't fix it in a clean way for the material system. will try after your patch from the tracker (shader merge) to fix that issue, too. (i you aren't faster ;) )
-
Upgraded Firebird dropship:
-
MCR, can you make the glowmaps that are along the barrel/muzzle flare brightly when the weapon is fired?
No (not yet).
-
@Mattn:
The reduced glow looks better because it prevents flickering when moving the camera... :)
But imho it could be a little bit stronger...
Don't worry about the strong glowing UFOs - I am working on v3 of this...
-
Updates ;)
-
For the record, I can basically eliminate the flicker (and improve the overall smoothness of the glow to boot), but there's a performance cost to doing so. On my system, the framerate drops from 60fps to 30fps when I use the flicker-free version (due to vsync, there isn't any middle ground, so that's not actually quite as bad as it sounds; it just means that it crossed below the threshold at 60fps). I've attached a patch if you want to try it, but I'm not sure we want to put it into the SVN because of the performance issues. We could add an option to the graphics menu that let the user select what level of glow-smoothness they wanted (ie. low, med, high) or something, if people think it's appropriate, at which point I would be more comfortable including the patch, since it would effectively be optional anyway.
-
We could add an option to the graphics menu
Well, my opinion is that we should put every shiny feature that may not work or slow on old hw/sw on switches one-by-one.
I liked the geoscape features you did on screenshots very much but actually I lost every other GLSL features we had before too just because my driver (the open-source radeon driver) doesn't support FrameBuffer Objects... so for me (and probably for some other players) your features are regressions at the moment. :(
Would it be possible to separate the features and link them to cvars? I can help with menuscripts to have an UI for them. Thanks!
-geever
-
@geever, I thought we had done that; there are already separate menu options for GLSL and postprocessing. If you disable post-processing, it shouldn't use any framebuffers. Can you tell me what, exactly, breaks on your system so I can try to fix this? Actually, go ahead and open a bug in the bugtracker for this and assign it to me, and put your info there.
-
I am always FOR additional graphic options to let the user customize everything, but there also should be a reasonable default chosen for each system also, because many users won't bother going to a graphic options submenu...
There were also suggestions (very good idea) to make a submenu to the normal graphic options where all the details could be configured... We could name it something like 'Advanced Graphic Options', a feature available in countless other games also...
I cannot tell you anything about why Mattn actually changed the glow-strength & how he removed or reduced the flicker effect, I even was a little surprised as I was adjusting the glowmaps to the default glow we had...
The new glow looks good in-game also, but could imho be a little bit stronger like I already wrote before...
-
I think I just made the most important of all glowmaps ;) :D ;D
Take a look:
-
Man, it's a good thing the aliens don't really understand the concept of a "sniper"...
-
Man, he needs his cigar, otherwise his hands are shaking too much & he is not able to zero in on the target... ;)
-
MCR, thats what diazepam is for. ;D
Now, whoa... All this awesome glowing is making my dizzy...
-
I dont quite understand what it issue is for animated glow maps. Cant it be done in just the same way as the regular animated textures?
-
For the most part, yes. In the places where we have animated textures now, you can use animated glow-maps. I think the issue is more that currently you can only have animations associated with materials, which means things like soldiers, aliens, weapons, dropships, etc. can't have animated textures (with or without glow). Mattn and I are in the process of trying to make the rendering system more uniform so that there are fewer things than only work for certain types of objects, but it's a fairly major project, so I expect it will take some time before we really get everything the way we want it.
-
I almost forgot to post a screenshot of the most important glowmap for the girls out there :-[...
So here it is. :o
Our black beauty with the most important accessory for girls to have on the battlefield... ;)
...Aliens won't shoot @ her, because she is so beautiful ;) :D ;D 8)
-
btw., the dropship in the background is showing the ongoing work of arisian & mattn who are upgrading our 3d engine here big time...
RESPECT !!!
-
I am quite sure you will not like that one >:(, but I have to tell you it really looks great, 8) & creepy to the maximum in-game, so I'll share 3 screenshots with you, to see what you are thinking about this (the screenshots were made @ a time the glow was adjusted to maximum):
-
Ugly.
You are mixing up genre of the game. This is not horror, this is Sci-Fi, and the game is trying to convince logic and physics.
-
I also feel you're taking the glow maps a bit far, MCR. How about a break?
Kildor: You're wrong about one thing though, it *is* horror, at least a little. It's supposed to be a little scary. But not because the enemies are imposing per se, it comes more from a sense of hidden threat.
-
No problem, I knew devs would not like that one... ;)
This was more meant as a joke ;)
But I am quite sure that small details like 1 golden glowing pixel indicating a small ear-ring or plug (?) only even seen when zoomed in very much, these are details that do matter, regarding the atmosphere of the game...
Anyone who knows girls ::) should know that they would take their earrings even to the battlefield ;)
Small leds on weapons that indicate that we are in the scenario of 2084 & not 1984 do also help a lot & bring lots of details, where those would be missing without the glowmaps (out of technical reasons, as the glow looks always smooth, but normal textures look pixelated @ high zoom)...
Regarding the weapons:
Just take a look @ them ! I was very careful to make them glow just there, where the original designers already indicated that they should !!!
Judge them one by one !
Look @ the original weapons skins & then look @ the glowmaps...
Many of the weapons & ammunitions do not glow intentionally, my work with the weapons is imho finished, so please judge me on this, but once again:
I was very careful in adjusting the glow, but if you can tell me exactly what you do not like, I can correct this... ;)
-
Also I want to note here that this shows all 44 weapons & ammunitions glowmaps & their summed up sizes.
Take a look:
-
Woah thats not as big as i thought
-
Glow should no longer be visible through other models as of r29626; let me know if there are other issues. (NOTE: current SVN (r29626) seems to hang on the loading screen; I think this has something to do with recent changes in the file-system drivers.)
-
should be fixed (the endless loop)
-
Who call me Intelligent??
I`m cruel Russian scientist, and don`t know «political correctness» phrase.
-
Come on, MCR, get over it.