Yeah, that could work. 

I have a platform with "_minlight" set to 300 and "_lightignore" set to 1 and the result looks less uniform than expected:

https://media.giphy.com/media/xiBtcFw60XXFvNYIMn/giphy.gif

It looks like the torches affect the minlight of the platform even if it's supposed to ignore all lights, right? The darker areas of the platform also looks very dark even if _minlight is set to 300. Is this supposed to happen? 

Forgot to write in the previous post, that the problem made me wish there was a "_maxlight" key to prevent some areas from being too bright, so that's something for you to consider implementing in future versions. :) 

Sorry for the spam, but I keep remembering stuff in drops. ;C

Currently the "_minlight_exclude" key allows for only one texture, right? Could you make it possible to have more than one texture be excluded by separating the textures with a comma/semicolon etc? 

It turned out that the cause of the non-uniform brightness was the "_dirt" key in the worldspawn. That affected the brightness of the elevator in the narrow hole. I solved the problem by adding a key/value combo of "_dirt/-1" for the platform.

But my two previous suggestion posts still stand. Something for Eric to consider implementing. :) Sorry for the spam again! @_@ 

+1 for _maxlight key

it would be handy to give certain brushes a range with _minlight and _maxlight 

I know from experience this is a tough feature to work with and it's currently pretty limited. But if it could be improved I think many more ppl would use it. I was able to get a pretty decent result in my 100b4 map. The big 4 on the far wall is a projection.

I'm wondering if there's any way to rethink this or improve the functionality somehow? 

there's four ways to improve it.
1) tga/png images. either way qbsp really needs the ability to read tgas too, not just the light util. wads need to die (or at least have the option to be killed for non-fullbright surfaces).
2) cubemaps. project all 6 sides instead of just 1. it should reduce issues with fovs higher than 90 and potentially improve rtlight compat, but 6 faces is more of a pain to create.
3) lights placed INSIDE the brush containing the light that is being projected, which would be especially handy with cubemaps. Failing that, just switching the light to an orthographic projection would properly allow for sunlight through windows.
4) higher lightmap resolution, so that the projections can actually be seen without turning into a blurry mess. You can already achieve that in a backwards compatible way by using _lmscale, however it'll currently only work in FTE+QSS when compiled with ericw's tools. Otherwise you can achieve higher resolutions by just rescaling the texcoords and increasing the texture size to compensate (ericw was toying with the idea of automatically doing this a while back), but this sort of thing has a direct impact upon texture filtering etc.

stuff like that '4' might be better served by adding support for decals somehow - even if they're still just lightmaps it would be easier to align them, avoiding bluring and effectively doubling their resolution. failing that there's always fence textures.

either way, any kind of change requires someone to devote their time to implement said change... 

That map was clever as hell! Great job! 

As Spike said, the lightmap resolution being tied to 1/16 of the texture resolution brings unavoidable conflicts.

Personally, I'm eventually going to create a different BSP format where the lightmap projection and texture projection will be completely independent (plus other features). It's the only way to implement this nicely. 

doesn't upscaling the projected texture help make it look better? 

@generic Thank you!

@Snaut I don't recall if I tried anything over 512. It was a long afternoon of trial and error. 

there's no mipmapping or anything on the projections, so if your projected texture is too high res, then all that will happen is that it'll skip over various pixels completely, resulting in shimmering at least if it were moving in realtime.

so 1 lightmap sample per 16 wall texels, which means 1 per 16qu with quake's default texture scaling. a fov of 90 is probably easiest to figure out the required distances of the light.
Thanks to linear filtering, a 16*16 lightmap covers only an area of 240*240qu, not 256*256.
the same is true for a projected light image if you want it to match your lightmaps.
so a fov90 projected texture that's 16*16 should be 120qu away from your 240qu*240qu 16-aligned wall. your light should be centered where you want it - which means misaligned by 8qu on each axis from your 16qu grid.
assuming I didn't embarrassingly screw up the maths anywhere, that should give you the best resulting image quality.
a 17*17 projected texture would be cleaner (128qu from the wall, aligned to the grid, woo), but mipmaps need to be a multiple of 16, so that's not presently possible. :(
The res will still suck though. _lmscale on a func_detail is the easy engine-specific way I'd do it, but if you want to instead double the texel density then just change the scale and halve the distances - just remember that doubling the projected texels from 16 to 32 is actually 15 to 31 luxels, which is NOT doubled, so 124qu instead of 120qu from the surface (and along from the minimum point of the surface - this is the point the lightmap is aligned to). 

Thanks for helping with guidelinesom this. I know what I'll be messing with this weekend. 

Can we have the params used for each of the build tools stored as extra keys in the worldspawn entity?

For light in particular, because so much behaviour can be dependent on the command-line params, this would be useful to be able to recreate the build.

I'm thinking something like:

{
"classname" "worldspawn"
"_qbspparams" "-splitturb"
"_lightparams" "-extra"
"_visparams" "-level 4"
} 

Also good for newer mappers to see how the tools were used at a glance. I dog this suggestion. 

I have a particularly persnickety map. Do you mind taking a look at it and seeing if it can compile for you? I keep having random missing faces (tend to be same areas but different faces on each compile), nonsolid tris in my trisoup terrain, a spot on the 2nd floor of the house where vis causes walls to flicker out, and the occasional extra solid edges in the trisoup. It's actually my halloween jam map. I managed to get a compiled version with minimal issues in the main areas and physics seemed to be ok, but still the other issues, though minor. 

Why aren't you on Discord? 

Sure feel free to mail me and I can take a look. Can't promise a quick fix but it always helps to have a map to look at. Both issues (missing faces in general, missing faces from certain viewing positions after vis) have been lingering for a while. 

Sounds good. Ya, no rush.



@dumptruck, might change around later but I feel like I have enough things to check and read up on as it is without throwing another one in. 

https://discord.gg/AeEFKt 

thank you shamp 

https://i.imgur.com/2qFrB8G.gif 

 

Is there a way to make paths to external .map's relative instead of absolute. E.g. relative to the main .map file: "ext.map"