Hello!
i would like to know if it is possible, to exclude some brushes from the radiosity / bounce compile. in my map, models that stand on the terrain with a green texture are lit very green from below what look really unrealistic (my compile-settings are the following in the lightstage: -light -bounce 1 -fastbounce -patchshadows -samples 2).
is there any shader-command or command for entitys that could solve my problem?
walk_on_sky
You can change the amount of light from the reflecting surface with q3map_bounceScale N.N See http://members.lycos.co.uk/quakeroats/q3map2/shader_manual/
Reducing this for your terrain might make things look better.
I don’t recall any way of doing this for the receiving surface.
Note that 1 bounce doesn’t give you much radiosity
Alternatively you can specify a dummy black texture with
q3map_lightimage "path/to/blacktex.tga"
which effectively eliminates bouncing.
im sorry but i dont know 
i read something about these two modes of lighting, but i don’t really know when which of these two is used? can you explain that to me?
the models that were (q3map_bounceScale solved the problem, thanks for that) lit wrong were foliage models and manually placed models as well.
walk_on_sky
What does vertex lit mean? Does that mean like when something has a shader that removes it’s lightmap and it just looks like it’s on fullbright in game?
BTW,
-fastbounce enables fast mode for radiosity only.
It will do not enable fast mode on whole light phase.
It is wasting your time to discard -fast on light phase.
-fast contains -fastbounce, so why don’t you use -fast instead of -fastbounce? 
http://nibsworld.com/rtcw/tutorial_lightmapped_terrain.shtml
Kael- if I have an updated q3map2 compiler will be brushes\floors be automatically lightmap lit instead of vertex- or do you need a specific shader to do that?
Brushes are all lightmapped by default. Only models are vertex lit (by default).
And pick a name and stick with it. This mena/acrobat thing is a nuisance.
I don’t know who Mena is- not me though. We have similar IPs or something?
Hmmm so I have noticed that entity sun’s will not apply light to vertex lit models, but if you make a skyshader with q3map_sunext and q3map_XX whatever the name of the updated light emitting one, then the model will be illuminated. Is there some rhyme or reason as to what lights will illuminate a vertex model and which won’t?
Also I’m always fascinated with ways to build larger maps. If we put shader on certain textures to make them vertex lit instead of a lightmap- that would hopefully allow us to make a largermap? Or would it be best to just use a giant lightmapscale like 15? I know 15 sounds really high, but if you make the main dueling area with a reasonable lightmapscale, and then leave some of the larger areas that don’t matter with a really high lightmap scale things turn out nice. But, again, maybe switching over to vertex lighting would be the best way to go?
The third option besides vertex and lightmapped, would be a fullbright shader right? I’ve seen some textures mapped that weren’t emitting light into the lightmap, but appeared almost to be glowing themselves.
Sorry, my mistake. Mena has like, about 6 alts and for whatever reason your name got mixed up as one of them. Weird, because I’ve had discussions with you before without the mix-up.
Lightmaps:
By default, all brushes have an implicit shader “generated” (it does this internally, there is no actual shader file) that includes the diffuse texture stage and a filtered lightmap texture stage. When you make your own shader, you have to manually create a lightmap stage. Lightmaps are really nothing more than another texture filtered (darkens) on top of your texture (or the other way around: texture filtered on top of your lightmap) giving the perceived effect of shadows. That’s why when you view your map with lightmaps disabled, everything appears as what we call “fullbright”.
The pixels in the lightmap file are called luxels (lightmap pixel). The pixels in a texture file are called texels (texture pixel). This differentiates them from the actual phosphors/liquid-crystal-cells of your screen.
When Q3Map2 renders the -light stage, part of that creates the lightmap texture by calculating light intensity, radiosity, etc. and records it into an image file which is compressed into the BSP (unless instructed to dump them externally using the -export switch). Most lightmap images are 128x128 pixels, though some games like W:ET support larger sizes. Each lightmap image is called a “page”.
Lightmaps are uniquely UV-texture-coordinate-mapped to your brushes, meaning each luxel in your map is unique. One luxel does not cover two surfaces at the same time. As you can imagine, this can build up quite a lot of pixels, which is one of the reason why we are supposed to caulk unseen faces. Also, lightmaps typically have a lower resolution than textures to help blowing out your video memory, but we can scale them (up or down as need be) using the shader, func_group entity key/value pairs, and with compiler switches. Because of this resolution requirement, lightmaps have certain limitations, which I will discuss later.
Vertex Lighting:
Vertex lighting is generated for both brushes and models. By default, the game prefers to use lightmaps for brushes because of certain limitations with vertex lighting (also to be discussed later) though you can force it to use vertex lighting only for a slight performance benefit on older hardware if you don’t mind the lighting to look like crap. Vertex lighting is applied to the mesh of an object, be it brushes or models. A vertex point in 3D space can contain certain bits of information, primarily its coordinates (XYZ) but also a few other things as well like colour and alpha.
Any three vertex points in space will form a surface. Assign all three vertex points a colour (or light) value and they will create a gradient between them blending their colour values evenly across the surface. For example, lets say we have a vertex with a white colour value, and two other ones with black colour values, the surface will have a white to black gradient across its surface.
Lets say we have a box sitting in your map that is vertex lit. The vertex points occluded from the light source will be assigned darker colour values, the vertex points directly in front of the light source will have lighter colour values. Faces in between light and dark vertex points will have a gradient going from light to dark. This gives the illusion that the surface is shadowed.
Vertex alpha isn’t used too often other than on texture blending for terrain. You’ll notice that with all the popular methods of blending textures on terrain (alphamaps, alphaMod dotproduct, alphaMod volume) uses vertex alpha to blend textures. This differs from pixel alpha that you traditionally use when you create an alpha channel in your image file.
Vertex lighting is very fast and can be dynamic. Since your brushes and mapmodels don’t move and lighting in the Q3-engine doesn’t change, vertex lighting on these surfaces are pretty much static. For player and weapon models, the vertex lighting is controlled by the lightgrid.
Q3Map2 also generates a lightgrid in your map. You can think of this as invisible cubes of light throughout the map that is used to light player and weapon models. What the lightgrid does is once a player or weapon model enters the “cube” the colour values for that cube alters the model’s vertex colours.
Limitations:
As mentioned, because lightmaps and vertex lighting are so different, they do have certain properties that can be considered as pros and cons. The primary limitation has to do with light fidelity.
Lets say we have a large (note that I said large) surface that has half of it shadowed by another brush. So half of the surface should be in shadow, the other half should be lit. Lightmaps have the advantage of storing relatively detailed shadow outlines on large surfaces so if the surface is lightmapped, it will appear as it should - half of it in shadow, half of it lit. If the same surface is vertex lit, it will appear different. Because vertex colours appear as a gradient between vertex points, you will instead have a gradient spanning across the entire surface instead of a detailed outline. Lightmaps for this surface will appear to have a greater fidelity.
Now lets say we have a detailed model mesh with a lot of vertexes that are in close proximity to each other. This means we have very many small surfaces. Lightmap luxels are relatively large (8x the texel size) when compared to the small surfaces, so much so that each luxel may span over several surfaces. Coupled with the fact that the lightmap needs to be UV-mapped over a complex mesh, this looks terrible. If the same group of surfaces are vertex lit, what you will end up with is very many small shadow gradients spanning the entire model. The “resolution” of the vertex lighting is as high as the number of triangles on the model. In this case, vertex lighting will appear to have a greater fidelity.
Brush based meshes are relatively large surfaces. Models generally contain very many small surfaces. So by default, brushes are lightmapped, models are vertex lit. Sometimes it may be advantageous to force it otherwise, like if you have a large model terrain mesh or otherwise.
Phew! That was a lot to write. Someone might want to check some of that to make sure I didn’t make any mistakes. My eyes are all blurry now, so I’m not going to read all that again.
You probably don’t want to use vertex lighting on brushes. I can’t even recall if there is a way of doing this explicitly for just a single surface. Tweaking the lightmap scale is certainly useful. In any reasonably (as in playable - ridiculously large maps are no fun) large map, you shouldn’t ever hit any kind of limitations. ydnar had compiled a HUGE map with that to-scale space station from 2001: A Space Odyssey without problems. A player was about the size of a single pixel when viewing the whole space station. It was lightmapped. If you want to create excessively large maps, you may want to try your hand at ETQW mapping since you can make several square miles of uniquely textured terrain. While I’m sure that the Q3-engine can handle several square miles, to make it somewhat playable, I’m sure it’ll start bitching at you and throwing a tantrum. She’s sensitive like that.
No such thing as a fullbright shader. Fullbright is the absence of everything light related. If you skipped the light compile stage entirely, fullbright would be the result. Everything in Q3-engine games is first fullbright and then darkened using lightmaps and vertex light, etc… sort of the opposite of real life where everything is black and then illuminated. Certain surfaces like lights don’t have a lightmap since they are the surface emitting light anyway (why would you have shadows on a lightbulb?). They typically have an additive blend stage to make them glow or pulse.
and there is no way to disable bouncing per entity(such as func_group) but per surface of each brush.
Welcome to item4u.com. Cheap to buy gold coins of the game.Warhammer CD Key $46.90Warhammer Online CD Key $46.90World of Warcraft CD Key EU $14.40 WoW CD Key US $18.25 Age of Conan CD Key $28.50 10 Million Rohan Crone $7.97 20 Million Rohan gold $15.94 5 Age of Conan Gold $3.00 30 AoC Gold $17.64 Warhammer Leveling us Level 1 - 10 Package $14.95 Warhammer Online Power Leveling us Level 1 - 20 Package $49.95 War Leveling us Level 1 - 40 Package $229.95