what i wanted was for the sunlight to be more natural, in other words, not make a straight shaft of light straight down with no falloff whatsoever..

HOWEVER... that method is great for creating detail on the floor, for example, above ceiling fans or something... but not in great big open (and tall) areas where it just looks silly having a circle of light on the floor. anyway sunlight2 seems to do the trick.. thanks 

Sunlight falloff on earth over distances of a few hundred feet is imperceptible. So why is not having falloff "unnatural?" 

I'm not sure what you mean by "hazy" here, but experimenting with the _anglesense value in sunlight can offer very interesting outdoor effects. A low value makes individual brush faces harder to spot as the junctions tend to disappear.

A high value will really pronounce the brushwork, creating an almost surreal impression of a "silky" material. Maybe not the most realistic variant, but it definitely offers an interesting look.

Entity or global _anglesense values can also be used for different effects. 

not having falloff means that the light continues in the same shape as it was cast, forever

this is not realistic for obvious reasons, and doubly so when coming from the sky! 

As metl said, having falloff on sunlight isn't realistic as the sun is a strong point light very far away.

If you have an outdoor area in a map, try values like -sunlight 200 -sunmangle 45,-75 sunlight3 80. This creates a pretty sunny feeling and the high pitch -75 angle is good for vertical maps, i.e. not so wide open areas under the sky.

For open areas, you can try lower pitches, like -60 or even -30, which will create a more sunset/sunrise atmosphere. Low sunlight intensities can be used for "moonlight".

The yaw angle of 45 degrees helps avoiding light shining along axial walls and creates more interesting shadows.

Experiment some and see what looks good in your map. If you use the -nolight option, trying out different outdoor lighting combinations is fast, even in big maps. 

thanks, will check it asap! :) 

i confronted inertia in IRC and it turns out what he was trying to say is he wants radiosity, becuase it looks unnatural for light not to bounce around the room. 

haha :) you got me! 

I hate using features of anything that I don't understand how work. So:

What exactly does the -gate # switch do? It's barely mentioned in the changelog in the readme, so I have no idea what it does. It says default is 0.0, reccomended value is 1. Does it accept 0.5? 1.5? What would it do then? Please explain more about this.

The second sunlight; Does this mean that if the check for a sky surface in the direction of the sunlight angle from a point fails, it will check in several directions in a cone around the sunlight angle and see if it hits a sky surface that way?

Are checks for sunlight performed on every surface in the map?

Light currently says it will perform "8G casts" on my map. Is there a limit ever to how many casts can be performed?

Otherwise thanks for the nice tools. I was toying around one day on converting them to Java, but then I decided not to. 

Long Post! First a small dictionary:

oversampling the -extra/-extra4 options that make shadows more smooth. -extra means 2x2 grid (four times slower) and -extra4 is 4x4 (16 times slower)

surface point: each face has a discreet grid of these points where the light levels are calculated, oversampling means more points

raytracing: testing if a straight line can be drawn between the current surf point and light source without any brushwork in between

cast: one of the straight lines between the surf point and light source

The Fade Gate is used to reduce the often enormous amount of raytracing that is done for all casts. It's done by first checking how much light that will actually reach one surf point with regards to distance attenuation etc for the current cast.

If the amount is smaller than the gate level (default 1.0 light units when enabled, any float will do), the raytracing for this cast will be omitted. This can (and often does) save huge amounts of processing time.

The visible effects are extremely hard to spot, I actually haven't found any case yet. The difference is measurable as a faint random noise pattern, but not visible. It's e.g. nothing like the digital distortion of jagged shadow edges.

Of course, if you increase the gate level, more light will be missing and finally you'll be able to see it. The default level of 1 is usually good. One of the few maps I can remember that needed a lower gate value (0.25) was pushcoag.

The 2nd sunlight just checks if any skybrush is visible in any direction from the current surf point. If so, it will get the sunlight2/3 level if not already bright enough. Sunlight3 is recommended as it also uses a vertical angular attenuation, i.e. the light is omnidirectional, but still comes from above.

The raytracing for sunlight is done for all surf points in the map (as it's non-attenuated), so its impact can be severe in higher oversampling levels. Higher level also means more suns for 2nd sunlight.

The # casts is basically a product of the total amount of surf points and the total amount of light sources. The surf points depend on the total size of all faces and the current oversampling level.

Since it's usually a very big number, the final calculation is made in 32-bit float precision to avoid overflow. The biggest value I've seen in a released map was about 25G casts, I think it was gmsp3.

The # of casts or even the size of light data in a map is probably more restricted by other bsp limits. It's e.g. relatively easy to produce a map with 10-20 MB vis data, but having more than 1 MB light data is unusual. The current limit is 4 MB.

Java eh? I wonder how RVis would perform then ... ;) 

then I could run your lovely tools on random non-windows platforms. 

That clears up some things, especially the fade gate thing.

I was thinking about porting Light to java purely because I suck at writing C, and it'd be cool if I could add my own functionality (read: bloat) to it. 

I have tried to use the vermis from lost chapters in one of my maps.
It looks like the vermis dosn't respond to the flags 'delay spawn'. Since it is a void map the vermis is visible all over the map.
Is this a bug or haven't you given the vermis the spawn- delay/silent/alert flags?

Hi, sorry for taking ridiculously long to respond... the WoW bug still has a hold of me these day. :P

anyway, to answer your question there is no spawning functions for the vermis. the orignal coiling thing was made for the situation you're describing, but we never really planned on having the monster be totally exposed and not hidden away in a little pit or somesuch before activation.

i'm planning on uploading a small 'update' to the chapters pak for qexpo and if you still want the feature, i can attempt to code in some type of spawning stuff for it in the update. 

the orignal coiling thing was made for the situation you're describing,

OK! Just as I thought.
I was planning to use the void map as a 'boss map' with the Lost Chapter map I'm releasing tomorrow, so it will be a little to late to do anything about it now.

I don't know if I will use the void map in a Lost Chapter pack in the future, so thanks for the offer but I'm not sure I need it anymore! 

I tried your suggested default settings for sunlight as recommended to inertia, I must've done it right (light entity with 0 brightness and the keys/values added). Does it look decent?

- http://www.phait-accompli.com/q/s4/pre/sun1.jpg
- http://www.phait-accompli.com/q/s4/pre/sun2.jpg 

the pics are very dark ... 

The joys of different gammas. Eh nevermind about it ;) 

I might have found the cause and fix for the synchronized flame animations. After checking in DP how it's handled there, the problem seems to be that lights are static ents and therefore aren't affected by the mdl sync flag.

I've just put in a simple hack to randomize the starting pose and it seems to work in both Win/GLQuake. Now Mike's and Chapter's torch rows look better. 

since the flag is in the model data and not in the quakec, it seems that from the beginning they intended it to be handled on the client-side. So this is just one of those cases where id screwed up? 

they didn't have separate static ents from the beginning and then forgot about it. It's pretty hard to notice if the torches aren't lined up close. 

I am sure some of you have mapped for RtCW so I have some questions to all of you:

1) I have unpacked models/mapobjects from pak0.pk3 and sp_pak1.pk3 and can now load the models inside Radiant. However, some of the dirs for the objects (mapobjects/bush, mapobjects/clipboard, mapobjects/lion to name a few) only contain textures and no model file, where are they?

2) Say I added a mapobjects/bodyparts/helbody.mdc into my map as a misc/model, how can I choose which skin is used on the model? By default, hel_body1.jpg is being used, how do I make the model use lop_body1.jpg instead? 

As of right now, my models/mapobjects dir is 27.5 mb in size, I am thinking this is too small and I am missing something? 

I need this answered ASAP:

how do i make 45 degree angles on walls in which the player does NOT get stuck on the edges??

im talking something like this:
www.qwplayers.org/inertia/problem1.jpg
www.qwplayers.org/inertia/problem2.jpg 

http://www.qwplayers.org/inertia/problem1.jpg
http://www.qwplayers.org/inertia/problem2.jpg 

1) Make sure you're using aguiRre's latest QBSP.

2) If that doesn't solve the problem, merge the angled wall and its supporting right-angled walls into a single brush.

The problem occurs when QBSP grows the brushes to create the clipping hulls, and QBSP grows the angled brush incorreclty so it extends past the right-angled wall and creates an invisible wall that players get caught on. There's a command in Tyrann's engine that lets you see the clipping hulls, and there's also a command in aguiRre's QBSP that lets you view this clipping hull in normal Quake.

Hopefully this makes sense since I just had some gin and a Sam Adams.