I was wondering if there is a way to get the -sunlight function not to have zero falloff...

I am using -sunlight in my map, and it produces really nice and crisp shadows on the ground -- which is great. But I also have skylights that are ~1024 (or more) units from the floor... and the bright spot on the floor looks a bit silly to be honest :/

I want to release this map during qexpo, and if I can't get this problem worked out I'll just go for the regular "put lots of lights near the sky and hope for the best" technique -- but I don't really want to do that! :) 

oops :/ 

...is that you don't actually want sunlight. 

Try Yaw and Pitch to make sure the sunlight doesn't shine straight down.

or

Try anti-lights in the area where you don't want full sunlight. 

stretch the sky brush up like 512 and put a bright point light inside it near the top. 

i'll try all of those things when i get back from dinner. in short, i like the cool shadows that sunlight makes, but not the ugly unrealistic stuff it can also produce! 

Don't forget -light and -sunlight2. 

I didn't understand the question, really. What is causing the "bright spot" on the ground? If you're using sunlight, you shouldn't also use intense point lights as that would defeat the purpose of the sunlight.

You can however add other ambient point lights around to make the outdoor lighting more interesting, but these should be low-intensity and with low wait values (e.g. 0.01).

You can also try using the _anglesense key in worldspawn (only affects sunlight then) with lower values than 0.5. This will reduce the angle attenuation and create a more intense sunlight, especially on vertical walls.

If you then lower the intensity of the sunlight to compensate, the difference in light levels between the ground and the walls will be smaller. If that was what you wanted ... 

So for a hazy sun effect I could have a high _anglesense value? 

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