It's really easy to add though, i'll add it after fixing Pritchard's issue.

Cool! Sounds like a good addition

Man that could open up some interesting visuals.

Random dipping of light from clouds in an overcast sky...the strange pulsing of an alien sun...a simplistic day/night cycle (obvs no moving shadows but whatevs, it's not as if you can animate the skybox)...

You could sync up the light variation with some variation in the fog and skyfog settings to sell the effect better.

I did think it might be interesting if it was possible to have multiple different sunlight setups, all on a unique lightstyle (well you'd be limited to 3 I think) - morning, midday, evening - and you lerped their light intensities in QC (along with "night", but that wouldn't be a lightstyle, just an absence of light). But that's probably overkill and the shadows might still look odd.

I'm not really sure what the performance implications are with massive amounts of lightstyled surfaces though. Are there any these days? 

I just looked up how lightstyles work, is there any limit to the length of the string? Or could you actually have a light that took a really long time to complete it's cycle? That would be a lot of letters...

Also seriously? It's done with letters of the alphabet??? 

Yeah, you can set up those strings and have the light cycle automatically, or you can just set a single brightness value explicitly (e.g. say you wanted a slow day/night cycle thingy, I guess you'd want to set up a slow think function and increment the brightness in the think) 

Uhm, how come this QBSP generates a whooping 11k more clipnodes than other compilers on my map?! 

Hmm, I don't remember touching anything related to clipnodes since this forked from tyrutils.

I just tried compiling ad_zendar.map and it looks like I can reproduce that:

bjptools_xt_290914_phong2: 38011 clipnodes
tyrutils-ericw_0.15.10_beta1: 44953 clipnodes

So it's producing 18% more clipnodes than bjptools_xt. Is that the same kind of percent increase you're seeing / what are the total numbers of clipnodes? 

Around 41% in my case if my math is correct.

bjptools_xt 1.2.5: 27174 clipnodes
tyrultils_ericw 0.15.9: 38372 clipnodes

(Also roughly 700 more marksurfaces with tyrultils) 

Hmap2 produces an even higher count: 43601

So it's settled then: Bengt Jardrebb ftw! 

I don't mind using the old txqbsp_xt in order to not exceed the standard marksurfaces limit, but I'd like to use this light.

I was wondering if the problem of light not passing through sky had been fixed. 

Negke thanks for the info, I'll look into optimizing the clipnodes sometime.

Rick: sometimes this qbsp will produce fewer marksurfaces, so try both.

About making ordinary lights go through sky faces, I tried it a while ago and I don't think it's worth the code complexity, and it caused a significant slowdown.

If I added a way to add entities to specify multiple suns would that help? Alternatively just make a hollow box connecting to the window, it should only add 1 extra leaf and a few sky faces. 

Tried latest beta and I receive too many light styles on faces when I didn't on the latest stable version. Going to assume that's with styles now bouncing?

A few notable black faces I was keeping track of are still showing as pure black. Just reporting! 

latest build from here has a bug.
Rotate_object arent lit, leaves them all black. 

i'll look into it. The git master and 0.15.10-beta1 versions of light are half-baked at the moment, I recommend the stable version 0.15.9. 

When a deep lake full of mud or slime is in a very bright area, the lighting from the outside will illuminate it as if the liquid didn't exist. This is specially true for lakes under open skies with sunlight.

How complicated would it be to implement an option in the light tool for underwater faces to receive gradually less light according to their distance from the water surface?

I suppose it could work this way:
1) If the face is underwater, check if the light entity is not underwater;
2) If the light entity is not underwater, make a list of all liquid surfaces between it and the underwater surface;
3) For each ray, check which liquid surface in its path is closest to the light entity;
4) Calculate the distance from the liquid surface to the underwater face, and use it to reduce the brightness received by the lightmap.

Note: Light entities placed underwater shouldn't be affected by this, because their underwater brightness was deliberately set by the map author.


I think this feature could be very useful, specially in areas with both water and slime - the slime would look more muddy than the water, because the bottom of it would be harder to see.

Maybe this could be implemented through an entity field in func_detail liquid brushes. 

r_waterfalloff
r_slimefalloff
r_lavafalloff 

But lava glows on its own. So does slime, doesn't it? 

I don't think slime necessary glows or doesn't glow, though it depends on what kind of slime it's supposed to be...

In Lava's case, you'd never realistically be able to see underneath the "surface" so no one can say if it glows or not :P

I feel like this effect could already be possible with negative lights - those subtract from the lightmap right? You could place a bunch of them underwater and it'd probably be possible to have the desired effect. 

Never knew they exist... 

I've never tried using them myself but it's in the docs. 

I was thinking of Quake 2 where (all?) liquid textures had surface light. So I guess that's actually irrelevant.

Quake's palette shifting effect tends to make underwater areas too bright anyway but negative light would probably still help. 

Attenuate faster if the trace crosses a water surface.

How do you see this working with moving liquid bmodels? 

How do you see this working with moving liquid bmodels?

Let's follow the current standard:
"_shadow" "n"
If n is 1, this model will cast shadows on other models and itself (i.e. "_shadow" implies "_shadowself"). Note that this doesn�t magically give Quake dynamic lighting powers, so the shadows will not move if the model moves. Default 0.

Liquid faces from inline bmodel entities should only be taken in consideration if their entity's self._shadow is 1.

Shadows are, essentially, instant attenuation. Faster attenuation can be considered semi-related to shadows. 

source 

The volumetric water attenuation is certainly do-able; the raytracer is already set up to have side effects when a ray hits certain surfaces.

The latest stable release from last fall has "stained glass" support, i.e. if you make bmodel with "_shadow" "1" and "_alpha" "0.5", light rays going through the entity will be partly attenuated and pick up the color of the texture.

So a simplified version of water attenuation would be not considering the distance traveled underwater, but just attenuate the ray when it goes through the surface. But on the other hand, I can imagine it would look cool to have bright sunlight at the water surface fading to black (thinking of an e1m4 type environment).

Anyway it's a cool idea to add to the todo list. My first priority now is fixing the breakage that Pritchard reported a while back, which I'm making good progress on but kind of a bit drained on tbh. 

That's fine, just know that what you are doing is really really great! There is no going back to the old tools now.

Incidentally, is your light or qbsp multithreaded? I know vis is, which changed light to be my current bottleneck (bounce fun notwithstanding). 

Thanks, appreciate it :)

Light is multithreaded, qbsp is not. Qbsp could get a lot faster, it spends most of its time in CSGFaces checking if each brush intersects each other brush in the map. Quake 2's qbsp is multhreaded.

The main performance tip for light is to avoid using -extra or -extra4 except on your final compile, and also add -gate 0.1 or something to reduce the overhead of delay 2 lights.