Development > Artwork

New Feature: "Glow" textures

<< < (17/35) > >>

H-Hour:

--- Quote from: BTAxis on April 19, 2010, 11:32:45 am ---Wouldn't that effect already be there what with the lightmap?

--- End quote ---

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.


--- Quote from: Mattn on April 19, 2010, 12:30:36 pm ---that's not something for glow in particular, that's something i will implement for all material settings.

--- End quote ---

Great! I was hoping for this.

Mattn:

--- Quote from: H-Hour on April 19, 2010, 12:46:31 pm ---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.

--- End quote ---

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.

H-Hour:

--- Quote from: Mattn on April 19, 2010, 01:11:45 pm ---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.

--- End quote ---

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...)

Mattn:
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 ;)

arisian:
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 :)

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version