Thanks, compile & compute aren't the same. 

to create first rate work with Quark as Mark Shan showed with Project Genoma for Quake 2, and it was the first editor that I tried, but for me, Radiant and BSP are both more to my liking.

I guess the biggest advantage to using Quark is that the team (or is just Armin?) are showing no signs of giving up on improving the editor. 

but I could be wrong (I know him via a completely different connection -- small world). 

Mark Shan was using the DeathMatch Maker (DMM) editor, not QuArK. 

DMM=lol
one couldnt make anything remotley nice in it 

You'd get better results with Notepad. 

ugh... this is driving me nuts. :P

afaik, you can't bake on lightmaps like you can with other games like Painkiller, or even q1, everything must be lit realtime in the engine.

ok, that's cool, but holy shit: how do you get the map to not have more than 2 lights on a surface without it looking pitch black?
(my first test area had only like 8 lights in there, and it ran like total shit) and all the walls were pink/white indicated 4+ lights on the surfaces. :P

are there any good tutorials that show lighting techniques that can give me double digit fps and not look fulldark?

also, is there any equivalent of the _sunlight like in q1 compilers to get sky brushes to emit light without any (or much) performance hit...
i mean, i have gotten the effect by placing a really bright light ouside the map... but is there a better way?

also, when you are counting the number of lights on a surface, do you count faces that don't get shined on (ie: they are blocked by another face)

and how do you get it to split faces so that each face is split where the light hits?

also, what would run slower: a large room, say 768x768x256 with each face with max 2 lights on each face, or a small room, say 512x512x128 with 3 and maybe some places with 4 lights per face?

/me is a total n00b at d3. O_o o_O 

i have a strange problem... in my map, you start in a room facing a door, and behind the door a monster is placed there, facing you. but it can't see you through the door, but regardless it awakens, walks through the door itself and starts attacking.

the strange thing is, when i turn on notarget, go into the other room, spawn a monster in manually, go back into the first room and turn notarget back off, the monster won't awaken until i open the door (which is what it should do)
so my question is, why does the monster awaken on map start like that? is there some kind of hidden value i need to put in? 

As far as monsters are concerned, there is no sound attenuation. So, when you make a noise, all monsters, regardless of where they are in the map, will awaken and come running to take your soul unless you set them to ambush, or set them to be spawned on trigger.

There was a good tutorial on monsters on doom3world, but I'm fucked if I know where that's gone :/ 

unclicking 'cast shadows', and using ambient type lights can help you a ton. But that's all I know cuz I've only messed with d3 engine a small bit :D 

so, then these would just be normal lights except they don't cast shadows, but still affect spec and diffuse, right?
or is it a different entity? (i haven't seen on like that)

but it tried making some lights not cast shadows, and they still did on the world, and i didn't see much speed increase... did i do something wrong? 

but the way it seems lighting should work is that each area uses 1 'major' light, and it casts shadows. The rest should be detail lights that do not touch each other, and do not cast shadows. Depending on their use, specularity and diffuse is up to you. For an ambient, you just make a light, texture it with one of the no falloff or ambient or whatever they're called textures, and give it a dark color. 

I confused Shan's work with Milhous who did use Quark for his XXX. 

there is ambient light shader (same place you set cubemaps for a light) - no shadows, no spec, lights backfaces - every poly that gets into the volume. Use with care (dark color) or it looks shite

some crap about lightmaps ( I didnt try)
http://www.doom3world.org/phpbb2/viewtopic.php?t=8045&postdays=0&postorder=asc&start=20 

Stay clear of ambient lights, they wash out stuff too much. Instead place the lights so in the editor, that each face has only two overlapping lights touching. This might not be always entirely possible, but keep trying. And darkness is a tool just as lights. Areas with a lot of contrast can look very good. 

i'll give all these suggestions a try then.
i guess a lot of the problem is that i'm not used to having everything so dark like this...

i miss my q1 softshadows too. :P 

You just need to be careful to leave it pretty dark--if you brighten it up much at all things do indeed look like ass. 

And don't think of ambient as a full map thing, this is small, controlled ambient we're talking about in areas that would logically have a dim light all over. And to avoid some of the wash out, you just have your normal lights be whiter than others in darker areas (leaving lights full-on white for general use generally looks a bit too bright in contrast to the dark) 

The problem with ambient light in Doom3 is that it doesn't pay attention to normal maps (to my knowledge). All contours of the surface are shaded equally, which makes ambient lighting even more flat and ass-like than in in the Q engines. Even ambient light has bias towards a particular direction or range of directions - it's bouncing off of walls and crates and things.

I think a good go-between, if anybody who writes this crazy ass shader things is reading, would be to shade with the blue channel of the normal map as an intensity map. It'll show the contour of the surface still, looking as if the light were coming at the surface from directly in front of it, but still shade the surface pretty uniformly.

Not enough hours in the day, man. 

You end up adding lightcounts by 1 on every surface at the area you are using the ambient light at. You have to be really careful about adding further lights after that. Same goes for fog since it's a light too. In my experience fogged areas tend to have lightcounts predominantly in green-blue, and i'd bet it's the same with ambients.

I don't think D3 mappers in general should worry about map having pillars, corners and stuff with 0 lights on one side or something. Place some materials with fullbright elements there for example. Looks kickass.

Also try using lights that go over the 1 1 1 RGB value scale. Some odd effects there. The doublebright cubemap materials for lights are quite nifty too. And remember to split brushes at light area boundaries when necessary (X or Y flip the texture so the bsp won't re-merge the brushes). Brush your teeth every morning and respect your elders. 

Isnt there a switch to make 'compiler' split according to light volumes?

btw there is interesting solution in the above d3w link (page 1) - shaders that add-blend the colormap
cheap (as in looks but in performance too) 

But you don't want to turn that on. You'll just end up with billion split polys. You get better results by splitting the most offending brushes (80% of time the floor) by hand. 

man, first i needed to align my brushes on the grid, now i need to align my lighting? O_o

hehehe, lol, so manual brush splitting it is then.

in general, how much of a gain is there on this? ie: is it really worth doing or just if you want to try to get an extra 1 or 2 fps here and there? 

what about lights on models?

say i modelled a large structure or something like that and there were no brushes used at all (well, except the caulked ones behind to seal the map) does it matter how many lights hit a model?
and does the size of a model matter as well?

what about large swathes of terrain? 

Forgive my stupid question but are all the custom textures I have used for my Quake level (made in WC) within the bsp so that I could just throw away all the texture wads I have used and they'd still remain in the level?

It's just that this is all new to me - because I remember that when I made a map for Q3A you had to store the JPGs/TGAs with the pk file along with the actual level. The same with Duke3D for which I have been mapping lately (since -97) - you always had to include Tiles***.art file with the level or the textures vanished.