Yeah, it should be easy to add a default; I was thinking func_detail.
How complicated would it be to add random texture tiling feature based on texture names during bsp generation similar to Half-Life's technique which does this during run-time?
This would help break monotony of large walls and rocky terrains.
Misc_external_map 'classname' Shadows
I want to make sure I have this right. While setting up the entry in the FGD it seemed that for...
func_detail, func_group and func_detail_wall there is no way to disable shadowing?
Setting _shadow to 0 or -1 on the misc_external_map entity had no effect.
Jus' curious, thanks.
@veryslowmapper Yeah, it would be doable - probably not too hard because qbsp already chops up faces to fit within the software limits.
@damage_inc "_shadow" "-1" should work on misc_external_map. I'll double check.
Netradiant Valve 220
"Infinite projection" in 220 format causing light stage to fail. Created by rotating brush without tex lock.
Example map with stretched trim
I'm not sure what to do.. on one hand, that face with an invalid texture projection crashes software quake (at least winquake.exe), so light.exe failing with a hard error isn't too unreasonable.
maybe qbsp should warn about the face, and then save it to the .bsp with default texturing.
1) the qbsp defines the sizes of surfaces.
2) infinite projection means infinitely sized lightmap.
if the qbsp is generating a lightmapped surface larger than the specified limit then that's the qbsp going wrong, not the light util.
(unless its turb or sky, anyway, in which case the light util shouldn't be trying to light them and thus shouldn't care).
Just reading about the new misc_external_map feature, and it sounds awesomebiscuits.
Although, I'd have thought it could be even more powerful if it worked like: whatever is in the external map, including multiple entities (e.g. func_door, func_detail, light_*, whatever) would just get copied across, so e.g. you could have a brush torch sconce + a light or two associated with it.
I'm sure there's a damn good reason for the current implementation but just thought i'd mention it :}
Are you talking about Quinstance style external bsp support?
I'm talking about the misc_external_map entity in ericw's bsp tool
I started with "brushes only" as a first step because it simplified things a bit, especially "-onlyents" compiles can ignore the external maps right now, but they'll need to load them when I import entities as well. No special reason it can't be done though.
Well, I think one of the biggest uses for me would be the aforementioned torch sconces where I'd maintain just a small selection of lighting prefabs; each containing some func_detail_* sconce thingy, plus a torch entity and maybe complimented with a couple of secondary filler lights.
I'm fairly schizophrenic when it comes to lighting, and often decide to change every single light in my map in a certain way, and then some time later, I end up changing them all again, etc. Being able to do this through prefabs would be a "game changer", to coin a phrase :}
What Kinn said is why I wanted instanced groups in TB so much. You could just stick your light setup (brushes + ents) in an instance group and copy it around the map, thus easy to iterate over time.
I've avoided directly addressing this, for fear of seeming to shit on eric's efforts in the same vein, but I feel I should clarify that Quinstance
is not for external BSP files, but for MAPs, and already does what Kinn's looking for.
It is an external tool, which of course complicates compile setup, and it (along with VMFII
, which does all the real work) is written in C#, which demands the .NET Framework in Windows or Mono in Linux and macOS, so I understand the value of doing a similar thing in a native tool, especially one already so widely used. Until entity support arrives in ericw's QBSP, though, you could use Quinstance to have easily tweakable prefab entity configurations. Nesting, entity name fixup, @ syntax, material replacements, most of the Source func_instance features work with Quinstance. The "origin" and "params" entities found in that engine don't, but VMFII doesn't support them either.
If you need example usage, I could pack some of my own maps up for you. The Jam 7 and Retro Jam 5 distributions include source for my entries that separates the main map from the instances, but only in JMF form, which I'm only now realizing I shouldn't have done. For most other Jams I only sent in collapsed versions, i.e. after the instances were resolved, but I've used instances on all but one of my maps going back to Jam 6 (including the "bubbler" ornaments in my Xmas Jam map), so I have plenty of samples if anyone's curious.
Eric, if you're interested, both my wrapper code and Metapyziks' is MIT licensed (really "X11", pardon me), so despite it being a different language you're free to browse it for ideas of how to approach the problem without fear of running afoul of some oddball license terms. Or how not to, if the techniques prove unappealing. I know the VMFII dev has expressed a desire, at one point or another, to redo the project to greater or lesser extent, so how much you'd want to imitate I don't know.
the super useful _dirt_off_radius / _dirt_on_radius stuff seems to be missing from the website documentation.
Anyone else seeing buggy behaviour with the "mangle" setting on "_sun" "1" lights? Try setting a few different yaw values on the mangle...
What does external bsp support offer that would be different from setting the model key on a func_illusionary to a .bsp? (Ignoring precache requiring engines of course)
its external_map not external_bsp :P
So it's a simplified quinstance that's editor independent. Cool.
Would be awesome. I’m think it could be used for lots of interesting stuff
Any love for quake 2? :)
Nothing usable right now, but I made some progress a few months ago (light.exe can read q2 bsp's and write them out with working lightmaps). What's missing is mapping the Q2 contents / surface flags to the what the tool can understand.
Small update, mostly with changes to how invalid valve220 texturing is handled:
I'll do another release soon with _phong_angle_concave which lets you disable / change the phong shading threshold for crevices / concave joints.
Yeah I've tested it and it's really useful for rocky structures where you want to smooth out the convex areas, but keep the concave parts hard (like where boulders intersect basically).
Also useful on some weird low-poly arch setups with angled trims where you'll only want concave smoothed but not convex.
Another small update:
- light: tweak phong shading to use area and angle weighting
- light: add "_phong_angle_concave" key
- light: fix -bspx option
full explanation for _phong_angle_concave is in the light manual: http://ericwa.github.io/ericw-tools/doc/light.html
I was going to add a toggle for the new area/angle phong shading weighting, but it's too subtle to notice in most cases, but I can make it optional if needed.
Thanks again for _phong_angle_concave, it's quite handy!
I have some ideas of stuff to do with the new area weighting that will probably show off better how it helps, need to find some time to do it.
Silly question, does light still act really strange around certain geometry (example on github here
) or is 0.15.9 still the most reliable version?
I haven't had those kinds of artifacts in a while with the new versions, at least not on sealed maps (sometimes on leaky maps the lighting is a bit weird).
CLEric, Hope You Don't Mind @Mankrip
Been just dabbling a bit with my own flava of a compiling utility when tonight I had this idea:
After you set all your options just click "mini mode", stays on top also, and then no alt-tabbing to the compiling UI!
Anyhoo's... beyond that I almost have the "simple compile" interface done. then it will be on to the advanced UI design part. It will also have the map conversion and bsp operations(extract textures etc) incorporated as well.
"Debug" Preview Of The "simple" Compile UI
I say Debug because I have screen elements that will not be in final design, they are there just so I can see what's it going on.
Here it is:
I know "central" part looks identical to WC/Hammer/Jack etc, I just like that layout. Still not set in stone, if I "see" and easier to view arrangement I will ofc change it.
This is windows-only gui tool or crossplatform?
@Doomer, Most Likely.
I loaded up my 'Nix distro, which is severely aged at this point, and it partially worked(Under Wine). Which is ofc not good enough.
Wine Its Not Very Good.
What was used to create this tool - MFC, .NET (WFp or WinForms), Delphi?
An off-the-wall Basic IDE! Yes, laugh... hehe
I'm no programmer, and in reality this is just a glorified batch file/commandline tool. Mostly string declarations, manipulations and paths saving.
If there is an easy to use, freely downloadable cross platform IDE let me know. I would consider rewriting it.
All I need is access to File and Folder dialogs plus write to .INI files.
Working With Func_detail Stuff
Is a bit of a pain. Would be real handy to just rely on standard func_groups/etc for organizing in editor and then just slap a detail flag on whatever as needed. Maybe handling it like q3map2 does is possible. Would feel more consistent and be less of a headache to work with for sure.
Like...a Spanwflag? Interesting.
But maybe I missed something. What is the point of func_group if you can just group a bunch of func_detail or standard brushes in the editor?
Just Like In Q3 + Radiant,
a simple "detail or not" flag for the compiler with filtering in editor. I don't know if anything more is needed for quake? To me func_detail_ seems unnecessary and it'd be much better just marking brushes as detail. You could have detail stuff and worldspawn linked together in func_groups then atleast.
I did notice too that func_detail_wall and func_wall don't behave the same in game; custom entity keys were removed from func_detail_wall I think.
To me func_detail_ seems unnecessary and it'd be much better just marking brushes as detail.
That requires a new map format.
That's why func_detail exists. To allow you to flag detail using the existing quake map format.
I can add support for the quake 3 .map format's detail flag (stored per-plane in the .map file). @Qmaster in GTKRadiant there is a shortcut key to turn the selection into detail, so it could be handy if that's your editor.
I did notice too that func_detail_wall and func_wall don't behave the same in game; custom entity keys were removed from func_detail_wall I think
They are completely different beasts.
func_wall is a separate entity in game, potentially interactive.
func_detail_wall becomes "baked" into the world geometry on compiling, like func_detail. Unlike func_detail, it doesn't chop up world faces that it butts into.
An alternate approach is to adopt just the UI aspect from q3radiant (the keyboard input) -- under the hood the editor could be using that flag/unflag operation to move the brush from world to func and back. Don't show it to the user as an entity, show it as world brushes with detail flag, but store it as a func.
you'd also still need to support _phong and all the other keys that you'd want on detail too...
Would be awesome to have q3 style detailing as option eric. Wanted to ask this ages ago.. Before pestering niger to add support -)
Will be easy enough to just use func_groups to add keys I assume.
It just occurred to me — are BSP entities self-shadowed?
For BSP entities that doesn't cast shadows onto the world, it would make sense for them not to cast shadows over themselves either. This would also require them to support backfaced lighting, like the lit liquids does.
They're not self-shadowed; you can opt to it with "_selfshadow" "1" though. Enabling world shadows with "_shadow" "1" implies self-shadowing too. (All of this should be consistent with tyrutils).
Can I use these to compile q2 maps?
No. But you can compile Hexen 2 maps.
Check out this page near the bottom for compiling tools. http://maps.rcmd.org/tutorials/q2_mapping_today/
Not currently, but the next update will have experimental support for q2 in the light tool only (so it'll be possible to use this 'light' in conjunction with a quake 2 qbsp + vis), thanks to m-x-d's contribution! I've been slow to get to testing it but planning to soon.
Nice. Can you implement an entity field to enable lighting from the back, like in the liquids?
This would be useful for opaque glasses such as the func_illusionary stained glass windows in some E4 maps (they're completely black from behind when you enter their secret area), and for new stuff like ice bridges, etc.
I think it's actually textured with "black" on those levels, but what you want is _mirror_inside 1. Or was it _mirrorinside 1. To add backfaces inside the brush.
No, adding backfaces is a different thing. I'm talking about letting the surfaces be lit from behind, just like EricW already did for the water.
this would be a good addition. "_light_from_behind"?
Bug With _lightignore?
I have a platform with "_minlight" set to 300 and "_lightignore" set to 1 and the result looks less uniform than expected:
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?
Add A _maxlight Key?
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. :)
Multiple Minlight Excluded Textures
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?
I Figured It Out!
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:
"_visparams" "-level 4"
Also good for newer mappers to see how the tools were used at a glance. I dog this suggestion.