 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
|
I like being able to preview the different light settings with just a click of a button :)
give him some time, you..
Nice site eric, i actually learned some new things i wouldnt have with playing around with it. I like it. Modern day Quake lighting is insane. It would be totally possible to make a great looking monochromatic level these days. Fuck textures. :)
nice page ericw. those comparison pictures are really informative. i'm not a mapper, but i'm seriously considering relighting some of the levels in my collection just to see how it would look like.
- warrenm is right monochromatic levels would be great. i've just recently finished naissancee and i was impressed. i would love to see something like that in quake. imagine it... black/white level and the only color would be red bloodstains. - jakub I would like to make a map with all this, but at the same time, I'm too lazy to even make one properly.
(Consider this a beta as only I have tested it, but it seems 100% bug free!)
I have created a https://dl.dropboxusercontent.com/u/33279452/quake4ericwTools.fgd Let me know if you do find any bugs or confusing titles etc. USE THE HELP BUTTON AS ALL THE DETAILED EXPLANATIONS OF EVERY NEW COMMAND ARE IN THERE <3 <3 <3 One quick thing in this new FGD
Also, lights used to be colored sprites in Jackhammer. Now they're boxes. The monsters thing is really weird, I didn't touch any of that part at all!
As for the lights being boxes, I am sure there is a bit of code to tell the editor what sprite to use for entities but I don't know what it is :| I will investigate! by directional arrows you mean in the 3d view? I thought you meant the direction spinner in the entity properties :P
Ok, I'll see where this stuff is so I can add it. * added editor models for all items that have a model
* added direction arrows to everything has a direction (direction arrows do not show when a 3d model is rendered in place of a solid box) * Lights now have proper sprites and/or 3d models. * entities now appear in the correct position when clicked into the 3d view (mostly) https://dl.dropboxusercontent.com/u/33279452/quake4ericwTools.fgd I'm not sure how to remove just those two entries from a single func_* entity def. The new solid entity parameters are all inside the base solid entity class.
Haha, awesome! I think this marks the first time that I've EVER had actual models show up in Jackhammer.
This is now the greatest FGD of all time. OF ALL TIME! * Additional options removed from func_detail as they don't work
* Re-added func_illusionary as somehow I deleted it :P https://dl.dropboxusercontent.com/u/33279452/quake4ericwTools.fgd Ok, I think it's there! Let me know if you find anything else. ]@PointClass = info_notnull : "info_notnull (spotlight target)"
This line is incorrect, the correct usage for info_notnull is for "teh hax". * Spotlight angle renamed to Spotlight direction
* Spotlight angle (sets spotlight cone in degrees) https://dl.dropboxusercontent.com/u/33279452/quake4ericwTools.fgd Sorry I had no idea I sucked so bad at this :P Hopefully this will be final version! Nah, you're a hero for making this thing. It'll make Jackhammer a lot more fun to use during this jam. You've got my vote, congressmen.
* Removed setting a default for Deviance as it actually forces the light to use deviance!
https://dl.dropboxusercontent.com/u/33279452/quake4ericwTools.fgd This can bring your light compile to a slow crawl so be sure to update if you are using this fgd! Any advice on how to prevent it from creating too much light and containing it at a small fade scale?
I need to put some examples on the website for doing lava surfaces.
Here's one that uses two surface lights on the lava: http://i.imgur.com/FAmAZlM.png delay 2, light 20 for the fill light delay 0, light 200 for the direct glow If you use "delay 2" make sure to use low light values or you'll end up with a fullbright room. If you are using my fgd file, download the latest version of it as it causes a bug where all point lights will be deviance lights (each light is broken up into 16 lights!)
Make sure to remove any _samples key/values from any lights you have in your level, as they will be left over even after downloading the bug fixed fgd file. If you haven't been using that fgd file, then can suggest some settings for your surface light for lava : wait 3 delay 2 light 100 you can tweak "wait" to have the light be smaller/larger but I've found these settings to be quite nice. How the surface lighting works exactly: if you look at the BSP surfaces in-engine with "r_drawflat 1", each surface with a matching texture will get a light copied in the centre of the surface, 2 units above it. However, if a surface is larger than 128x128, it's subdivided into sections no larger than 128x128, and the lights are placed above those sections. So, you can think of the lights as being tiled roughly on a 128x128 grid.
My lava screenshot above is ugly, so if anyone comes up with a good example scene for lava settings that you want to put on the tool website, that would be welcome! What I've found works best for lava: use really low surface lights just to fill areas (if you find it necessary), and then hand place a couple really bright lights that will do the heavy lifting and cast your major shadows in the area.
and be sure to set "_dirt" "-1" on the lava lights, you don't want dirty corners next to your lava! "Never actually considered that you can use two lights on the same surface :O "
!! Same. No idea You could use a 2nd light with a high offset on the lava and make it a bounce fill light.
AWWWWW YYYYEAAAAHHHH hey DaZ, when I try to load your
"Parse error at line 26, column 39: Expected token type closing bracket, or word but got colon" Personally I'm guessing it's TB's parser, not your Looking at the row/col. It's the first line of added code in the file, so I'm guessing that the version of fgd the file is written in is incompatible with TB.
This fgd was written for Jackhammer / Valve Hammer and probably uses some things that are not compatible with Trenchbroom (the colour picker comes instantly to mind). It's worth noting that you can still use all these new features that are exposed in this fgd, you just have to add the key/value pairs manually. TB doesn't like the comments after the second colon. This is an oversight by me, I didn't read the FGD spec carefully enough, and the FGD files I had used for TB didn't contain such comments. File a bug report and attach the file so that it gets fixed, please.
the comments are useful as they show up in jackhammer/hammer help screen. That's why I added them in the first place :D
But yes, you could remove all the comments and it should work. Right, I get that. But it's either wait for someone to fix Trenchbroom OR start using the FGD now. So
The fgd won't be useful in tb1 anyway, since tb1 doesn't display the key/values part of the fgd. Will be nice in tb2 though :-)
do func_groups get ignored or something? I have a map with a func_group in it with ~4k brushes in it, but qbsp finishes in 1 second with the following:
---- LoadMapFile ---- *** WARNING 06: No info_player_deathmatch entities in level 19190 faces 4766 brushes 4 entities 2 unique texnames 38380 texinfo Opened WAD: Opened WAD: Opened WAD: Processing hull 0... Processing hull 1... Processing hull 2... ---- WriteBSPFile ---- 0 planes 0 0 vertexes 0 0 nodes 0 6 texinfo 240 0 faces 0 0 clipnodes 0 1 leafs 44 0 marksurfaces 0 0 surfedges 0 1 edges 8 2 textures 391772 lightdata 0 visdata 0 entdata 293 0.152 seconds elapsed Peak memory usage: 13694572 (13.1M) looks like it's skipping it? one idea, make sure there's at least one ordinary brush in worldspawn that's not in a func_group/func_detail. There's a bug that happens if there are no regular brushes.
haha yup! thanks!
and while you're here... currently in this qbsp, mixed face contents is a full error that halts compilation, while other compilers (aguirre's in my case) will just give you a warning and convert the brush to a solid. any chance of doing the same here? mixed face contents really isn't a big deal, at least, not enough to warrant an error. One quick suggestion
I found when I set up my batch file to use one fewer core than I actually have, working on maps became a lot more fluid... Your fgd file contains a few integer properties with float default values such as in line 34:
_range(integer) : "Global light range" : 0.5 : "Scales the brightness range of all lights without affecting their fade discance. Values of n more than 0.5 makes lights brighter and n less than 0.5 makes lights less bright. The same effect can be achieved on individual lights by adjusting both the 'light' and 'wait' attributes" That's technically invalid and I don't know what JackHammer and others would make of it. TB currently crashes at that line. I'll fix it and round such values. In line 76, there is this:
@baseclass base(Appearflags) flags(Angle) size(-16 -16 -24, 16 16 32) offset(0 0 24) color(0 255 0) = PlayerClass [] The flags(Angle) part is syntactically wrong. Check https://developer.valvesoftware.com/wiki/FGD While doing n-1 threads by default works, I think I'd prefer auto-setting priority to "below-normal". This way, when the computer is idling, it'll use all cores, but if needed, it can be put into the background while you work on your map.
That might work too. All I know is that right now, if I don't hand set the thread count, I end up with a machine that can't do much while light runs...
haha yeah, i know what you mean.
as a workaround, you can start light/vis with the start.exe command: START /BELOWNORMAL light.exe to manually set thread priority. Sleepwalkr, I'm fixing the fgd but I don't understand a few parts of it.
_range(integer) : "Global light range" : 0.5 : "Scales the brightness range of all lights without affecting their fade discance. Values of n more than 0.5 makes lights brighter and n less than 0.5 makes lights less bright. The same effect can be achieved on individual lights by adjusting both the 'light' and 'wait' attributes" If I just set the value type to float instead of integer will that fix the error? This value defaults to 0.5 and 1 will change light values in the map. @baseclass base(Appearflags) flags(Angle) size(-16 -16 -24, 16 16 32) offset(0 0 24) color(0 255 0) = PlayerClass [] Honestly I just copied this from the fgd that ships with Jackhammer so I don't actually understand it. Can you post the correct syntax and I can update it! <3 <3 The integer vs. float thing: Integers cannot (or at least should not) have non-integer values, so that default value of 0.5 is nonsensical. Either use float or use an integer default value. If non-integer values are supposed to be okay, then do this:
_range(float) : "Global light range" : "0.5" : "yadda yadda" As necros said, default values for floats should be in quotes. As for the flags thing, what are these flags actually for? Does that specify additional spawnflags? Maybe it's something only JH understands. Either way, TB2 now ignores such things (and gives a warning), but it would be cool if that FGD were compatible with all editors. If you want, I'll make you a TB2 build to test with so that you can make all warnings go away. It might be JH specific. Thinking about it now it might be the part that tells the editor to show the direction arrow in the 3d view for info_* and monster_* entities.
I will change to a float for those two non integer integers. Onetruepurple : the color255 brings up the colour wheel for selecting light colours in an rgb 255 format. it's too useful to remove. It would be wonderful if TB supported something like this but for now I guess sleepwalkr can ignore this specific attribute? I'm not sure how it's set up internally, but if you add a "_color" key to a light in TB1, a color editor shows up when that row is selected.
i think it is hardcoded currently? _sunlight_color gives a picker, but _sunlight2_color does not, for example.
TB2 will at some point. Right now, the special semantics of that property are ignored, but it will load and it will show up in the editor.
it's not hardcoded, but it tries to guess whether a property is a color property by examining it's name. It's flaky, and the color255 and color1 property definitions in the FGD would surely help. I will support those in TB 2.1
I just tried out this new light utility. I'm have trouble getting lava to look right, but I'm sure I'll get it figured out. One question. Is there a limit to how many surface lights? Because I'm getting some ideas here. I realize it's just one light per texture name, but if I have 30 different light type textures, each can have a different type of surface light emit?
no problem having multiple surface lights with the same texture name.
The way to think of it is the "_surface" key causes a light to be deleted, and then copies placed across surfaces with that texture. There is currently a 65k limit on total number of lights, for no good reason, but the light tool will be really slow if you get anywhere near that number of lights. Okay, so it's possible to have multiple different style lights per texture name in addition to many light emitting textures. This is pretty cool.
Just as an experiment I lit up a rock formation inside a cave with a func_wall then removed the brush using killtarget on a trigger when the map loaded. Worked fine. I like that the color of the light is controllable. The Quake 2 surface light color was taken from the texture which probably contributed to its reputation for garishly colored lighting. yeah, what happens is the surface lights are already spawning arrays of lights, then each of those lights gets another array of lights. I ran into the same thing, but when you think about it, deviance on surface lights is only necessary if it is a single light (eg: a small wall texture), but not in the case of lava.
i wonder if you could track how many lights have been spawned as part of the surface lighting and if it is over a threshold, do not apply deviance lighting. just some internal tracking, nothing added to the actual map or anything. because you would want to use deviance lights for small 32x32 lights, for example. That would be nice to have. Maybe I was premature to disable combining _deviance + _surface; I could just make it print a warning.
ericw,
I had to switch to a faster computer for building the bsp because light was getting pretty slow on my editing computer. I now get those jitterning messages I asked about in the mapping thread. First time I've seen them. Not just a few, but screen after screen of it, but it doesn't take very long to get to the progress indication and the resulting bsp is fine, I just thought you might like to know. Stupid me. There's a copy of the 7/13/2015 zip sitting right there in the maps folder. I guess I downloaded the newer version but forgot to extract it, because the exe in that folder (the one I'm using) is dated 5/15/2015.
is there a problem with reading
although... maybe it's not related to symlinks as it happens if it is absolute or relative paths. So I've downloaded and extracted the tgz archive, but I don't know where to go from here (can't remember how I got the original tyrutils up and running, and I'm sure I didn't do it in the most elegant way).
Also, I'm not sure if downloading the archive was the best first step, as I'd ideally like to set it up so as to be directly update-able from github (the way I've got TB2 set up -- but I needed a hell of a lot of help in getting that up and running too, and understood virtually nothing of what I was doing!). Could someone give me some noob-friendly instructions, or tell me where I can find them? I should add these to the readme. Assuming you start in your home directory,
git clone https://github.com/ericwa/tyrutils-ericw.git cd tyrutils-ericw make If there are no errors this will generate ~/tyrutils-ericw/bin/qbsp, etc. To update: cd tyrutils-ericw git pull make clean make That was painless :)
Am I correct that the actual programmes are now in tyrutils-ericw/bin? Do I need to cd into that directory every time I wish to compile, light, etc.? Also, do I need to have the files I want to use (e.g. the the actual programmes are now in tyrutils-ericw/bin
Yup. You can run the from another directory by using the full path to the tool, like this, if you had maps in ~/maps: cd maps ~/tyrutils-ericw/bin/qbsp test.map -- What I actually do is use this build script: https://gist.github.com/ericwa/360f35c92a0139961f35 If you want to try that, save it as build.sh, update the UTILSPATH and DEST variables to match your tyrutils bin path and quake/id1/maps path, run chmod +x build.sh to make it executable, and copy it to your mapping directory. Now you can do: ./build.sh test.map and it will compile and copy the resulting bsp/lit to your quake/id1/maps folder. the actual programmes are now in tyrutils-ericw/bin
Yup. You can run the from another directory by using the full path to the tool, like this, if you had maps in ~/maps: cd maps ~/tyrutils-ericw/bin/qbsp test.map -- What I actually do is use this build script: https://gist.github.com/ericwa/360f35c92a0139961f35 If you want to try that, save it as build.sh, update the UTILSPATH and DEST variables to match your tyrutils bin path and quake/id1/maps path, run chmod +x build.sh to make it executable, and copy it to your mapping directory. Now you can do: ./build.sh test.map and it will compile and copy the resulting bsp/lit to your quake/id1/maps folder. What distribution are you on? If it's Archlinux, I could make a package for easy and system-wide installation.
Thanks very much for the extensive response, ericw! I'll give that a shot.
Spirit, no, I'm on Mint -- but thank you for offering. download
Changes since 0.15.1: * qbsp: make "mixed face contents" and "degenerate edge" non-fatal, from txqbsp-xt * qbsp: make "-oldaxis" the default. new "-nooldaxis" flag to get the previous behaviour. * light: add "-surflight_subdivide" flag to control amount of surface lights created * light, vis: use below normal process priority on Windows * light: allow negative surface light offset * light: ensure light values in the bsp equal the average of the lit file color components. This fixes "dark" colors (where all components are < 1), on some engines (such as MarkV), which require the bsp lightmap brightness to match the * light: fix lighting of hipnotic rotating entities. * light: fix crash in "Bad texture axes on face:" Thanks to everyone for testing & reporting bugs :D I've run my lava map through this new lighting program about 20 times this morning and I'd have to say that the sub_divide switch has definitely helped.
There is one room with a large rectangular area of lave (320x2048) which does not get lit (well, it does but very dim). In game, r_drawflat shows this lave as one single color. I think adding some structure to break the lava surface up more will fix the problem. I still have problems getting enough light near the lava without having it light up the entire cave, but I've got it pretty close. I'm up to wait 18 and my puny little 200 value delay 5 lava surface light still lights the the ceiling 1200 units above, but not a lot. The negative offset is very useful. You can sink the lava lights down below the surface and eliminate much of the spotty appearance, doesn't help much with default delay lights though. Those just basically paint the walls/shores up to a point then stop, which looks pretty bad, I've decided default delay is mostly useless for lava lights.
I'm working on a map for Jam 6, like so many others, and in experimenting with surface lighting using the beta Tyrutils posted earlier, I've run into a problem.
As far as I can tell, 'samples' on a light entity is being used whether 'deviance' is set or not. Even in a simple box test map, making one light and setting its texture name to the floor texture, with the deviance key either unset or set to 0, I get a certain number of total lights reported. Lowering the samples value down from its default 16 to 1 reduces the total count. With the total light count being a new addition, I can't confirm whether this is new behavior or not. I've had one other problem, where light exits with no errors after reporting "X entities, Y are lights" but before actually computing any lightmaps, but I'm still trying to find a minimal repro for that one. The deviance/samples thing is either more pressing, or just me being an idiot, so I thought I should speak up now. Am I just misunderstanding how to use these features? If you are using that fgd I created for JH I strongly suggest getting the latest version at https://dl.dropboxusercontent.com/u/33279452/quake4ericwTools.fgd as an old version set _samples 16 (which is default, but doesn't need to be set by the fgd) which caused some lights to use deviance automatically.
With the new fgd this doesn't happen (but you will still need to remove the _samples key from any lights that had it assigned before you got the new fgd). And err, if you aren't using that fgd, then ignore all of this post. YAY! Yes, I was indeed using an outdated version of your FGD. The new one fixes it, thanks! If I may, I'd humbly suggest the tool docs and FGD be updated to clarify the _samples description, which says "Default 16 (only used if "_deviance" is set)." I didn't understand that any value of _samples activates the feature regardless of the _deviance value.
Thanks, Wiiki! (Can you guess where my username comes from? :P) Now I just need to figure out why the beta tools are producing maps missing some textures. I'm using ID1, lavacity1a, and mapjam666 wads, and a few textures from each are missing. Others load just fine. Switch back to 0.15.1 with no other changes and all the textures show up. Any ideas? ...as soon as I post I realize the problem isn't exactly as I describe. It looks like the texture thing I mentioned isn't spotty, I mistook a few textures as belonging to a different set. The problem looks like two of the three wads aren't being loaded at all, with only mapjam666 (the last one listed in worldspawn's 'wad' string) being used.
The _samples thing iirc was a bug in the tools, the description was copied directly from Eric's site! It may already be fixed in his latest version of the tools.
Making that fgd has certainly upped my appreciation for programmers, and how they make stuff compatible across different apps/versions! What a pain in the arse :D http://i.imgur.com/jUcJ0Jn.png
I'm not really sure why the Lighting FGD just adds these unnecessary entity keys to all the light entities in my map, and It's just tedious to remove all of these different keys. I didn't understand that any value of _samples activates the feature regardless of the _deviance value.
Crap, I forgot to fix that :-(. Will fix it and put it in the next beta. re: textures not loading with the beta, but working with 0.15.1, that is messed! Any chance you could send me the wads and map so I can double check what is going on? I don't think I changed anything that should affect texture loading. Eric, I just sent you an email, thanks for the offer! You'll get the map, wads, and a readme with details. Hopefully I'm just doing something dumb. :)
If I don't select every single light entity in my map, the lighting would end up like this: http://i.imgur.com/37pGUH0.png
Honestly, I'm getting tired of being forced to select all the light entities and removing all the unnecessary entity keys for each light. Are there any workarounds for all this crap> are you using the latest fgd I made? https://dl.dropboxusercontent.com/u/33279452/quake4ericwTools.fgd
You don't have to use this fgd, there is a default one provided with Jackhammer. I made it for myself and thought others might find it useful! Looking at this screenshot (also had a similar thing myself playing around with mapping recently) http://i.imgur.com/81RoXoQ.png You can see that there is AO applied at very shallow angles. Maybe something like -dirtangle [degrees] would be a good setting to add. Where of course stuff under that angle would not be dirtmapped or something like that.
I guess not all of that stuff is from dirtmapping but just how light works. So maybe something that makes faces with angles under a certain threshold have averaged normals, basically like angle threshold controlled smoothing groups.
you can reduce _anglesense below 0.5 to help alleviate the shading problem in that tube. it may make the light look a little odd because it won't attenuate based on face normal as much. might take some tweaking to look good.
you can set "_anglesense" per-light.
When I get a chance I'll try playing with normal smoothing again. The first time I tried it I was still getting hard edges, e.g. with sunlight shining on an octagonal pillar. It's too bad you can not assign any values to brushes, that way it could be controlled on a brush basis, which would make more sense from a user perspective. But having it as a global variable with an angle threshold should be enough I think. Maybe additional value for func_walls, func_detail and such might make sense.
phong shading would be sweet... how will it be implemented though? Quake 2 allows surface flags to be set but there's nothing like that in Quake 1.
might be to do it via textures. Basically have a version of the level which you just use to generate smoothing group data and compile before the other stuff or something. You could just have it be a bunch of textures that correspond to SG01, SG02, SG03..
That would probably be a pain in the ass to do though. Just plopping out dumb ideas here. Or it could be integrated into the editor somehow, which just generates some file based on which faces the user has combined into a smoothing group. HL's light compiler uses Phong to shade smooth curves. You can also setup "smooth groups" in hammer that can tell the compiler what brushes to perform smooth lighting on. A good place to start!
I think I remember playing around with WC and you could assign a value(-1?) to a brush face(I used an octagon) and then when you compiled the map you could not see any hard edges? If you looked at the floor you could tell it was an octagon but otherwise no.
Am I crazy or does anyone else remember this? Are you thinking of Quake2 mapping? because ArghRad added a feature for phong shading via that method. Quake2 let you specify surface properties per face, so you could stick values into properties to set up smoothing groups for the compiler. (IIRC, you set a brightness value for the face as the smoothing group number, but didn't turn on the face's 'emits light' flag and ArghRad would look for that pattern)
Quake's That's it! Now I remember, it was When I was teaching a friend Quake2 mapping. Thanks.
Trying to use your fgd with Hammer (not Jackhammer) causes it to crash. Any idea why this occurs? The standard fgd by czg works fine.
*** WARNING 12: New portal was clipped away in CutNodePortals_r
*** WARNING 16: Texture __TB_empty not found I got them while compiling a TB2-made map using qbsp from this branch. I've been compiling every so often to test things out and I mostly do not get any errors. Would just like to know what I could have changed that would have resulted in these errors (and hence what I should avoid doing in future). CutNodePortals_r is usually caused by complex brushwork, often occurs where several planes meet at one point and/or there are brushes with vertexes off the grid. If it gave coordinates, look there in your map to see what could be the cause.
Example, txqbsp_xt will report it like this: WARNING:CutNodePortals_r: new portal was clipped away near (2592 -518 -40) Texture TB_empty sounds like some kind of missing texture error where TB substituted "Texture __TB_empty" in it's place of its name. Depending on where it is, you can often just ignore a CutNodePortals_r warning, but sometimes it causes small invisible walls that'll block player movement. Turning complicated brushwork in the area of the warning into func_walls will also sometimes fix it.
I got a lot of this in my jam6 map due to the weird brushes making the damaged walkway, so I just made them a func_wall. "__TB_empty" is the texture name Trenchbroom puts on a face with no texture. If you know the brush, you put a texture on it, if not, do a find/replace in notepad or something and search for "__TB_empty" and replace it with some other texturename (Does TB/TB2 have a texture find/replace? if so, use that)
is used when you have a face without a texture. TB2 has to insert some string as the texture name, and this is the placeholder it uses for such situations.
"" is a string, no? :) :) :)
srsly tho, yeah, I opened my ...for both explaining what causes those errors and giving me pointers on how to fix them (or potentially work around them, in the case of CutNodePortals_r).
Texture names are not quoted in the map file. God knows how different compilers would interpret "".
Radiant uses a blank space, luckily it also recognizes that blank space as something you can find and replace in the editor.
By the way, my favorite new feature of the light utility is the ability for func_walls to cast shadows. I used it a several times in my jam 6 map. The 12 fingered torchieres in the lava and the hanging lanterns beside the last steps up are all func_walls casting cool looking shadows.
I used "_shadow" key quite a bit... but there's one obvious spot where it caused an issue that I should've worked around: A func_illusionary with "_shadow" "1" on the floor casts blackness on the floor below it, so any dynamic entity on top of that func_illusionary will be unlit because it uses the lightmap of the solid floor (which is fully shadowed) as the brightness of the entity above it. This isn't a compiler problem, it works as intended, but can be unexpected that that is how it works. This is why there is a fully dark Ogre in the map.
I had to do that because of a clipping error, but I should've tried some other things to fix it, but it was getting really close to the deadline. That's similar to the old "black scrags against a bright sky" thing that many maps suffer from.
To fix that particular problem you had, sometimes you can put a func_wall floor underneath to catch the shadow, then put a real floor below that which is lit normally to provide the entity lighting. But it can be tricky to get the brightness balanced. Yeah, that deadline was a pain :) been meaning the mention this... -fast is missing from light.exe... Could we have this back, since it can take 20-30 minutes to light stuff now with all those deviant lights and such...
I think that might actually be possible. It would be a bit of work to code, possibly not too bad though.
cool, it's just a nice-to-have. maybe you have some floor you want casting shadows, but later needs to break or something...
There's a fix for mixed face contents I'd like to have that was added to git on 31/07, but the latest build is from 13/07 (according to readme).
Will there be a new build soon-ish or will I have to do it myself? (= pain) available from here: http://quakespasm.ericwa.com/job/tyrutils-ericw/
Yeah, those nightly builds should be fine to use.
In other news I found a serious bug in the surface lights code that was causing it to spam multiple copies (sometimes 10+) of each of the surface lights. This is unrelated to the bug where setting "_deviance" "0" on a surface light would also spam copies.. This explains why they were going crazy for some people during the map jam, and the extra long compile times with surface lights. That should be fixed in the nightly builds. I'm working on some speedups for light right now and hope to have a new release soon. available on the website: http://ericwa.github.io/tyrutils-ericw/
Changes: * qbsp: add "-maxNodeSize" option, from txqbsp-xt. Defaults to 1024. Makes large maps process much faster and should generate better bsp trees. If it causes a problem disable with "-maxNodeSize 0" * qbsp: make "mixed face contents" and "degenerate edge" non-fatal, from txqbsp-xt * qbsp: make "-oldaxis" the default. new "-nooldaxis" flag to get the previous behaviour. * light: add "-surflight_subdivide" flag to control amount of surface lights created * light, vis: use below normal process priority on Windows * light: allow negative surface light offset * light: average the lit file color components to generate the bsp lightmap value. TODO: use a perceptually weighted average. * light: fix lighting of hipnotic rotating entities. * light: fix crash in "Bad texture axes on face:" * light: fix surface lights being mistakenly duplicated * light: add "-onlyents" * light: add "-dirtangle" setting to control dirtmapping cone angle, default 88 degrees. http://triptohell.info/moodles/junk/tyr-h2.patch
adds -hexen2 argument to qbsp to generate a h2(mp) bsp. vis and light also accept hexen2 bsps. doesn't do anything about palettes. silently ignores hexen2's extra 'light' attribute of each plane, if specified. this is consistent with other hexen2 tools (iiuc). doesn't do any special behaviour with watervis, so unlike hexen2 lava is watervised by default. do NOT try loading a hexen2 bsp in a quake engine (other than ones that explicitly support it). doing so will likely result in crashes (and vice versa). -hexen2 -bsp2 are accepted simultaneously. fteqw supports this, other hexen2 engines will need to be tweaked now that there's a tool that can actually generate them. this relaxes the clipnode limit that otherwise severely limits the sizes of hexen2 maps (to two fifths of a quake map, approx). let me know if I broke anything... wow, thanks! this will be nice to have.
I will test this a bit and merge it in. ExportClipNodes is confusing, I don't get what the "diff" variable is doing and why was it only modifying model->headnode[1], but it will probably be clear if I watch it in the debugger. yeah, that took me a while to figure out too...
its reordering the clipnode trees because they're calculated by hulls then models, but stored in the file as models then hulls, so the previously stored hulls need to be remapped to cope with the clipnodes added into the previous models (ie: clipcount has changed since the tree for the previous hull was generated). the alternative would be to store the trees as-is and fix them up later. I forgot to do anything about world.spawnflags&1 signifying mission pack+hulls. I'm not sure that there's much point in it not being set, but meh. Hexen 2 bsp2 support - cool, I might finish my big H2 map then. I considered using it elsewhere but it doesn't really match there either. It has been just collecting dust since it broke the format like a clumsy child breaks eggs. :-/
just like my ROEM maps have been collecting dust since I got vaguely pissed off with RMQ gameplay and Quake at large but was too bored, sick, busy to do much about it. Can't puzzle out the gameplay but also can't release them for vanilla quake (too big, too spacious etc) anyway, hordes of fucking archer knights, at the ready? I'll have to try H2BSP2 some day. uh, Hexen 2 jam in honour of this feature? Or am I hallucinating. I probably am. No one makes Hexen 2 maps anymore. If you want to Hexen 2 map, hit me up? Detail brushes that are (I imagine) accidentally used to seal the void are bad, right? Might it be worth putting in a -nodetail switch or something that lets you do a test compile that discards all the detail brushes, allowing you to find leaks that are purely in the (non-detail) world brushes?
If you're using TB you can actually hide certain brushes.
Just go to the View tab on the right and deselect Detail Brushes. I use Netradiant, and never could get into TB unfortunately (although I like the sound of TB2 - I may have to have a goosey at that).
For now, I notice that rebb's txqbsp has an option to "make detail leak" for this exact purpose, so I can try that I guess. Since func_detail is an entity, I imagine your editor must have some facility for hiding/showing groups of entities
Since func_detail is an entity, I imagine your editor must have some facility for hiding/showing groups of entities
Hiding anything in netradiant does not exclude it from compile, so that would not help in debugging detail-sealing-void issues In radiant, you just press L to bring up the entity list, and select all the func_details by clicking the first one and shift-clicking the last one in the list... you just just delete them, save as, and compile the detail-less version.
In radiant, you just press L to bring up the entity list, and select all the func_details by clicking the first one and shift-clicking the last one in the list... you just just delete them, save as, and compile the detail-less version.
I know there's been plenty of talk of a prefab feature before, and I think last time it ended with people talking about doing it editor-side.
However, I never like the idea of restricting the choice of editors, and I know plenty of us are using an editor that is no longer in active development (e.g. netradiant) and really want to stick with it, so is it worth talking about a compiler-side prefab feature? The user interface would be simple - a "func_prefab" entity with a key that points to the filepath of a Of course in old editors you'd lose the ability to see the geometry in your map, but in a lot of cases I don't think this would be much of an issue as you'd position the brushes in your prefab map file so that a sensible anchor point would be at the origin. Thoughts? Is how to ensure that the textures are still aligned. Translation is easy, scaling is not so easy, and rotation is a bitch. Also difficult are targetnames etc.
someone mentioned having written or used such a tool on their jam map. Seems like a great idea to me, I also like making it a standalone tool so it's not tied to one editor or compile tool.
Sleep- one idea to help with texture alignment is to have the postprocessing tool convert the map to Valve 220. That should make it easier to preserve texture alignment. Since it's a postprocessor it doesn't matter if you editor can read 220, and all qbsp's these days can. Eric, I didn't think anyone was paying attention when I mentioned that during the last jam! :)
The "someone" in question was me. Over a couple of days before map jam 6 I hacked together some changes to Metapyziks' "VMFInstanceInserter", and while building "Princess of China" used it to place the light fixtures, skin bridges, totems, and of course googly eyes. VMFII was built to allow the use of the func_instance entity in branches of the Source engine whose tools don't natively support it, namely Half-Life 2 and its episodes. With the map and FGD file formats of Source being based, as they are, on the Quake/Worldcraft tradition, I figured I could simply conform both types of files to the expected formats on input to VMFII, then postprocess them back to Quake land before spitting out the results. It seems to have worked out, and saves the trouble of duplicating an entire codebase of translation/rotation code. The As for features, name fix up works just fine, prepending or appending a name (either one of your choice or an automatically generated unique) to your entity connections to make sure each instance remains separate, and variable replacement is no different. The func_instance_parms, _io_proxy, and _origin entities mentioned on that SDK Docs page don't work, mind you, but that's not unique to my Quake additions. There are some caveats: -I haven't released any binaries of my custom changes yet; I could always run off a few private builds for testing, but I haven't yet contacted the original developer to see if he's receptive to support for other games, or if he's satisfied with my approach in the event he is. -I haven't updated the documentation, and there's a bug in Jackhammer I just realized I forgot to mention in its respective thread that keeps this tool from working conveniently there. -The program is written in C#, so running it in Linux/OSX is sure to be tricky. What research I've done suggests it's not impossible, though, especially without any GUI libraries to worry about, and I have access to a Mac Mini with the latest OS X and as many Linux VMs as I have disk space for, so I can certainly take a crack at building it there. -There's no scaling support. I don't have enough 3D graphics theory under my belt to even begin tackling a thing like that, and I don't know what effect it might have on Source instances (which don't support it either) in any event, so I don't know how realistic this one is. -My code currently requires the Valve 220 That sounds very interesting!
PS: I wouldn't bother with scaling - I mean there might be some situations where you might want to scale a prefab (e.g. the depth of an arch) - but you've got to worry about what the textures do on the surfaces that get affected by the scaling (e.g. inside of the arch), and you're probably better off just making multiple prefabs to cover the small number of scale variations that you'd want. The dev builds now have Hexen 2 support ("-hexen2" flag for qbsp. Thanks Spike!), and also the qbsp "-epsilon" flag from txqbsp.
http://quakespasm.ericwa.com/job/tyrutils-ericw/ I'll start a dedicated thread around here eventually, so as not to hijack this one, but I thought I should mention I finally got around to cleaning up and releasing the instance thing I talked about.
The changes I made to that other project, VMFII, turned out to be awfully clumsy implemented that way, so I turned the code into its own wrapper project. Curious parties can try out Quinstance from the releases tab of its Github page: https://github.com/ItEndsWithTens/Quinstance Instructions are included, have fun! I'll tentatively say yes, I believe it's something like that, but I've never worked with bmodels before, only heard vague whisperings of their existence.
I think the best way to describe it is that it's like using prefabs, but any changes you make will automatically be applied to every instance you've already placed, and using a standalone tool means it's editor and compiler agnostic. Sadly no, eric, you don't get a preview in Jackhammer. I only focused on JH when building the included FGD because it's the editor I was using. Positioning things can be slightly irritating when you can't see what you're placing, but keeping Quake running in a window makes it easy to adjust/recompile/reload/repeat, so it's workable. Of course I'd love to see actual display of the instance contents, but it's just wishful thinking for now.
SleepwalkR, that sounds wonderful! Bear in mind I'm not trying to present this as the be-all end-all solution, just one I found useful for my own project. If someone comes up with a better way to do things, I'd be just as happy to use that. a copy of the other map's contents will have appeared where the func_instance once was
Are they aligned by their center coords? If this is the case, I would probably try to make func_instance a brush entity of the same size as the prefab, like a bounding box. That would help keep things on grid. Ah, thanks for the question, I'll need to clear this up in the documentation. The instance contents are not positioned based on their collective center, no. The center of the point entity and the origin of the instance map are lined up. All objects in the Filename map get offset from the func_instance by the same distance they're offset from their own map's origin, so it's reasonably straightforward to predict where things will be when all's said and done.
The Source engine tools' version of instances does have a func_instance_origin that lets you define a custom origin, actually, but VMFII doesn't yet implement that, so it won't work with Quake maps until that changes. I should have a News post written up in a few minutes, so if it's accepted we can take further discussion over there. Hang tight! When using func_detail, you have leaves (subdivided volumes of the map, including func_detail) and clusters (volumes ignoring func_detail). The vis speedup when using func_detail comes from vis only looking at portals between clusters.
What it was doing before was writing a copy of the visdata for a cluster for each leaf in that cluster - I just changed vis to write a single copy of the visdata for each cluster, and then all of the leaves in the cluster reference the same visdata offset in the bsp file. All this really does is shrink the bsp file (telefragged.bsp is 10mb smaller) and maybe load a tiny bit faster as a result, but it seems like a nice optimization. Seems to be safe with old engines (winquake.exe) too. Does light use the pvs data (if present) in any way to speed up traces?
i believe that was true in quake 2 light compilers, but not quake 1. (unless somebody added the feature to quake 1 light compilers)
czg, my light tool doesn't use vis data. I experimented with it a while ago, but the code was messy and I couldn't get much speedup from it. I could have been testing the wrong map (was trying telefragged.bsp). It probably would help if there are a lot of delay 2 or infinite lights, but also good vis blocking.
another idea I had is to shoot a bunch of random rays from each light, and use the furthest distance hit as a bounding sphere for the light, sort of a rough guess at the pvs. haven't tried this, though. is minimum intensity contribution as bounding sphere already implemented? once a delay 2 light drops below a half percent intensity or so it might as well be cut off anyway, right?
That's implemented, the -gate option. I think "-gate 1" means to cut off lights when the brightness would be 1/255.
I asked several times in the past about what exactly the "gate" number referred to and what was the range. I never really got a good answer. My working theory is that it's the rgb value of the lightmap, 0-255. So if you set -gate to 20, everything below that is pure black? Or am I totally wrong. What always threw me off was that many references state the default value is 0.01 or some other nonsense.
I think it's been broken since it was added to tyrutils in 2013. If you have a map with lots of delay 2/5 try the devbuild in #158.
On jam6_ericwtronyn I get a huge speedup, like: No gate: 60s, gate 5: 7 seconds Wow, yeah, map I'm working on went from 18secs to light to 8 seconds (only option was -gate 10) nice!
...though it seems -gate 10 is a bit high of a setting now that it actually works, lost a lot of detail in my lighting :D
Still, nice that it actually works! When you specify "-gate X": for each light, the util calculates the distance at which a surface would be lit up by that light to an intensity of 'X'. The intensity units are the same as the bsp file, so 127 is full brightness, 255 is 2x overbright. The distance calculated is used as a bounding sphere, so beyond the sphere the light casts 0 brightness.
Scampie + mfx, awesome it is giving a speedup for you guys!
If you just have a delay 2 light in a large box room, "-gate 10" should give a visible seam where the brightness changes abruptly from 10 to 0. Might have to turn up the quake gamma to see it clearly. It's possible I still messed up the formula so i might try rewriting it in a more straightforward way. I found -gate 3 worked well for my situation. Still a large speedup and I keep some of the subtle lighting effects I was doing.
i remember -gate 1 got a great speed up on old rigs in aguirRe's tools. like from 10 minutes to ~10 secs. Was is different now?
Tyrann just added -gate more recently to his tool (2013), and it looks like there was a bug causing it not to give as much of a speedup as it should have. but it's fixed in the most recent dev build of my version of tyrutils.
https://github.com/ericwa/tyrutils-ericw/releases
Highlights are Spike's addition of Hexen 2 support, fixed -gate, a new "_surface_spotlight" key which automatically sets "mangle" on surface lights to turn them into spotlights. Also, a question: Does surface lights follows the shape of the fullbright texels, or maybe the luminance of each texel?
The "surface lights" I implemented are nothing fancy like that, all it does is handle cloning & positioning copies of point lights. It's just a shortcut around a lot of copy&paste really. It works best with runic light fixtures where it'll reliably put a single point light on each light fixture.
The q2/q3 light utils have "real" surface lighting, where the light-emitting surfaces are divided into radiosity patches, and then the area of these patches is used in the lighting calculation. See here in the q3 tools. I think the patches took their colour from an average of 32x32 texels or something. I did experiment with that code in my tool but didn't have the greatest results, it was slow, tended to cause "hot spot" artifacts on the walls around a lava surface, and generally didn't look very good in Quake. :) Thanks for the info.
Idea: Interpret the fullbright texels as transparent, and put the surface's point light behind the surface. This way, you can use the algorithm of the alphamasked texture shadows to shape the light. The results will be more akin to spotlights, so it would have to be optional. It would be useful for stuff like windows. mankrip, windows like http://triptohell.info/moodles/junk/fte-20150311190731-0.jpg really needs
Considering my lighting knowledge is terrible at best, here's the bit where I go: "I've seen surface lights mentioned but how does it work?"
that screenshot reminds me of something that I experimented with.
http://quakeguy.tumblr.com/post/120732856652/stained-glass-window-casting-light I have a feeling that however you did it might be more competent because you have managed to get the actual texture to look like it's projected, whereas mine is a bit more of a hacky workaround using alpha masked textures and a couple of different coloured lights. _surface_spotlight sounds cool. So it just sets a spotlight based on the surface normal or something?
Stained-glass window lighting to me always looks exactly like those rainbow-splatter lightmap glitches you'd see in games from the early 2000s that remind you that you need to update your OpenGL drivers.
Yep, it sets the spotlight based on the surface normal. It's just a little convenience thing, I always found setting "mangle" to be a pain. This way you can rotate the light fixture brushes any angle and the spotlight will always shine the correct direction. :-)
oGkspAz, there's an example screenshot + entity at the bottom of: http://ericwa.github.io/tyrutils-ericw . Basically add key/value "_surface" "texname" to a light entity, and copies of that light will be cloned on all faces with that texture name. Surfaces lights in these tools are pretty simple things.
You place a light, anywhere in the map, and put whatever _color and light and delay settings you want on it... you then put "_surface" "NAME_OF_TEXTURE" on that light, and the light compiler will automagically copy that light around just in front of any surface with that texture, spaced apart every 128 units. It's best for things like textures that are clearly light sources, a nice convenience so that you can mess with a single light once, and all of them will be lit up. It can also be good for something like Lava, and doing the legwork of lighting it all up for you. A minor thing though is that if BSP chops your surface up, you get a new light for each face which can make things brighter than expected in places. This seems to be a problem with liquid surfaces mainly.
Thanks for the 128 units clarification.
I wanted to ask that before, but couldn't formulate the question properly. I don't know if there's an option for this already, but it would be cool for the dirtmap to be sized accordingly to the angle of the surface. This way, it would give a better impression of being dirt, since it would appear to have been affected by gravity and friction (horizontal surfaces gets the most dirt, vertical surfaces gets the least dirt).
Implementing this through an adaptive -dirtgain would probably be enough. -dirtscale would have to remain the same, to ensure equal shading at the edges. As far as I can tell, antilights (lights with negative value) no longer work - can anyone verify?
I was using quite a few of these :{ to elaborate:
One of the things I made use of before were antilights with a "style" value - crucially these only subtracted light from other lights with the same style value. Ok, they should be fixed in the dev build: http://quakespasm.ericwa.com/job/tyrutils-ericw/
I just made a mistake when reworking the light culling in the last release (to make -gate give a proper speedup), and it was culling all of the antilights. The special behaviour of style should still work. I didn't realize they would work that way at first, but it makes sense, because whenever a light with "style" set hits a surface, there's a new lightmap allocated for that style number - so a negative light with that style number would only affect that separate lightmap. It seems like when _surface_spotlight is set in the entity the actual surface no longer illuminates as it would without. Is there a work around or is this a bug?
To get a regular surface light in addition to the spotlight, just have two template entities, one with and one without _surface_spotlight set. You can have multiple lights with the same _surface value :)
I think dirtmapping should not be applied in points where there's a light close by, 16 or 32 units maybe. The low resolution of the lightmaps makes small surfaces in cramped places close to a light go fully dark.
Hehe, I was thinking something similar, but it needs to be controllable per light.
Remember you can work around all the issues currently by using _nodirt on a per-light basis. However, that requires more light ents to be added, which may get fiddly and annoying as the map scales up. A way of doing what you are saying would be to introduce a _nodirt_radius key on a light, which means the light gets "dirty" as normal except on surfaces within (_nodirt_radius) from the light. the transition between nodirt and dirt needs to be blended in as well to avoid ugly transitions. Ugh, maybe another key is needed to define when the blend starts :/ sorry I forget the names of the keys, I think they have changed once or twice as the feature developed
change list & downloads:
https://github.com/ericwa/tyrutils-ericw/releases Mostly bugfixes, except there is a new _sunlight3 that comes from the bottom hemisphere, instead of the top (_sunlight2). This is mostly for maps floating in the clouds, where you want skybox under the map that emits light. Combine both sunlight 2+3 for light coming from all directions, and use two different colors for crazy effects. Also, the -parse_escape_sequences option for light is a gimmick that lets you make red text in door/trigger messages, which previously you could only do with custom QC. added the _sunlight3 stuff to worldspawn
https://dl.dropboxusercontent.com/u/33279452/quake4ericwTools.fgd I added to my privately hacked tyrlite branch a "domelight" (this was pre-sunlight2), with control over color and intensity coming from straight up, the horizon, and straight down, blending between them (even though I'm not really working on a map that would take advantage of that.)
There's enough ways to light a world from the sky that moving stuff like this from infinitely numbered worldspawn keyvalues to a light_sun entity would be prudent, except for the "no spawn func" errors it would produce. Does stripping an entity from the bsp seem dangerous or counter to some method of production? How often do people really re-light a BSP without re-BSPing it first? info_null is ignored by the game engine, so you could have an info_null full of sun properties.
But is it really better than just putting it on the worldspawn? and flag it with a special key (eg _sun: 1) to tell light.exe that this is just your holder for the sun properties and not a normal light
classname: light _sun: 1 _some_cool_sun_property: 21.463 I have spent maybe 2 seconds thinking about this, so there may be a better way. is it really better than just putting it on the worldspawn?
Just feels cleaner to keep the sun properties encapsulated in a single dedicated entity that you can copy 'n' paste between maps easily. Also, getting a bit carried away with this...but with a sun as its own entity - you could support multiple suns by having multiple entities. To make setting the sun angle easy you could just target your sunlight entity towards an info_null, to implicitly specify the direction of the light (the setup would look like a cute little solar system)
Cool, blending the colors/intensity was something I wanted to try and will probably test out. control for the horizon is a good idea too.
If I'm going to add a new, tidier way to specify sun settings, I would be tempted to do it properly and make new entity types (light_dome for _sunlight2/3, light_sun for regular sunlight), and then strip them out when writing the bsp. Even the way surface lights are currently specified is sort of a hack, it should be a "light_surface_template" classname or something. If anything is being stripped when light writes the entities to the bsp, it might make sense to make the light tool read entities from the with a sun as its own entity - you could support multiple suns by having multiple entities.
This is what I was thinking. Although, as someone with experience lighting a map with a fuckload of suns, beyond a very limited point (like two or three, which we have now) the line between imperceptibly subtle and clownishly gaudy seems to get pretty narrow. i'd like to have the ability to map lightstyles to sunlights... then you could have 4 'suns' that are always off, and flicker them randomly via QC.
that would be sweet. I think it's easy to do in terms of the lighting code, the only challenge is how to expose it to QC. That's probably another argument for using entities for sunlight, it could work the same as ordinary lights; if the mapper sets "targetname" on the sunlight entity, the compiler assigns it a lightstyle.
I tried lightning tied to a skybox change a while ago, but every engine's got its own console command for the skybox and they're not consistent :/
You'd hit that 'max lightstyles for a face' limit quick though. Moving all features that affect the world into entities would be neat.
"sky_fog" entity or something for easily copying fog between maps, etc... And "info_world_sun", "info_world_fog", etc. in case of different entities for different features. Just to make it clear that such entities are global effects, not local effects.
If EricW doesn't implement it, I will.
But a proper implementation will most likely require surface flags (or, more specifically, surface groups), and the actual algorithm may not be Phong shading, but something that looks similar. There are a number of design issues to consider. This is one of the features that I've been thinking about during this whole year, and it's not simple. for organic geometry how about something like "func_detail2" or "func_group2"? Something outside the regular thing that just applies it to a whole brush?
I know it would be more ideal to apply it to surfaces but I would love to see something, *ANYTHING*, in the mean-time.
better to have a key:val on any func entity
e.g. _smoothangle: 15 That way you can control which faces get smoothed based on angle. I would be all in favour of Quake 2 style surface flags... I know it's introducing a new format for Q1 but at this point does it matter?
I would be all in favour of Quake 2 style surface flags... I know it's introducing a new format for Q1 but at this point does it matter?
You have to think about compatibility with editors like netradiant that are no longer being updated. This would create yet another legacy feature that would become redundant and require extra work to avoid conflicts and retain compatibility with.
Plus, most of the work I need to do before developing my approach is to implement a bunch of BSP debugging features in the engine, in order to analyze and tweak things properly without blind trial and error. The smoothing algorithm itself shouldn't require much time afterwards. What's the deal with q1rad? Does nobody use it because it doesn't have all of Eric's latest jingles and jangles or does it not really work all that well?
It is essentially the hl1 light tool ported to Quake.
The problem is that the final results can be quite washed out and lack contrast. I lit crdm2 with it and looking back now, oh god the lighting is awfully dull! the q2 light tool supported radiosity too. default 8 bounces, max 40. in retrospect, the best looking option would have probably been -bounce 1, which is what I'd use for quake if we had it (one pass of scatter and that's it). since Q2 came out when I was young and dumb I thought -bounce was one of those parameters that you set to the maximum when you do your 'final compile' so I basically released two needlessly washed out yellow Q2 maps.
vrad for source just does the max number of bounces it can, and when it runs out of light it stops, but their scatter and falloff equations were probably adapted out of a real optical physics textbook by an in-house mathematician they pay a half million dollar salary, so it always looks perfectly real in HDR. http://triptohell.info/moodles/junk/tyr_smoothnstuff.zip
adds a _smooth key to your func_detail entities that smooths the normals across surfaces. you might want to use -anglescale 1 or the equivelent field in order to prevent quake's harsh boundaries between lit and unlit areas. the qbsp flags the various surfaces. it doesn't currently support smoothing groups, but it would be the qbsp that would need to generate dupe verts for surfaces with different groups (this ensures that engines with specular effects can work correctly). also adds a few other things that I've been messing around with. check the readme (be warned that much of the extra stuff only works with fte, but not always to the detriment of other engines - _lmscale has a well-defined fallback). there's probably other issues with it - I'm not the intended audience so I'm kinda lazy where it comes to testing. per-surface flags would be really nice right now... but yeah, map editors. not sure how it works..
I made a key in my func_detail as _smooth and put the texture name in the field but it doesn't do anything? I'm trying to make the big pipe in the middle lit smooth... even with this util I am not getting smoothing.
http://www.quaketastic.com/files/screen_shots/5thnophong.png Any ideas? It's working for me: http://imgur.com/a/8KLPX
That's with just one light entity, "_anglesense 1" set, delay 3. What kind of light sources are lighting the pipe currently? If it's _sunlight, try adding "-anglesense 1" to the light command line, this controls how much sunlight (only regular sunlight, not _sunlight2) is affected by normals, 1 is the maximum amount. Sunlight2 ignores normals, so try turning it off if you're using it. You're running both spike's qbsp + light? I just tried it on an indoor area and it seems to work. It's not quite as good as the smoothing in Quake2's tools. I get very weird lighting on pipes for example (it's smooth but it doesn't like pipe bends and I'm getting harsh results)
i'd imagine with some polishing it can be made to work as well as Q2's, the Q2 tool source is available too.
I haven't given this a whole load of thought, but just wondering how much of a big deal it would be to just use the Q2
I managed to come up with a solution that works...
I've made just the visible faces have the texture that needs to be smoothed. This seems to only work with indoor lighting though. I do hope it can be applied to outdoor lighting too since I don't want to go back to the horrible method of lighting prior to sunlights. Here's an example that shows the difference between phong shading and normal quake lighting - https://twitter.com/GavinEdgington/status/675802921334915072 The pipes have lighting issues if anything but the visible faces have the smooth texture. I made the non-visible connecting faces use a skip texture to avoid these errors.
is certainly not perfect and I would want to be able to have _smooth work with other brush types like func_group etc.
@mankrip
afaik tyrlight already parses q2 maps and generates q1 bsps, however it completely discards the extra 3 args (also, no value texture alignment tweaks). I don't see why you'd need q2 fgd changes at all, you'd still be targetting q1 mods and tools, and editors that support both would likely continue to support both without really caring. the real issue is 1) editors that do not support quake2. 2) editors that insist on using wal files instead of wads. 3) editors that assume the palette is that of quake2 instead of quake. for the editors that are mainitained tbh all it requires is for someone to be vocal enough - its amazing how much of a motivator harasment can be. @ericw I didn't change anything to do with sunlight that I remember, so yeah, no support there. sorry about any other issues with it too. I was going to sit on it while someone else found the kinks for me, before making it public. but, well, open source matra: release early, release often. I'm too lazy for the second part though. by releasing I hoped to at least save some time for mankrip. in theory it should be possible to switch the barrycentric coords part to use the entire polygon instead of a triangle (giving a less-triangular/higher-quality apearance), but I just went with what I understand. @Fifth, there's nothing specific about classnames, it ought to work with any classname (at parse-time, on account of the way it flags texinfos). certainly there's nothing specific to func_detail. all I can really suggest is to make sure that there's no tiny cracks between faces, because it calculates normals at each vertex and then just interpolates those over the various triangles that form the surface in a similar way to how a gl engine would interpolate normals. remember that it'll happily smooth around any angle, 20 degrees, 90 degrees, 170... this means you'll likely want to use some other texture for the top/bottom of your mid-pipe cylinders so that they don't cause it to try to curve around those rings. secondly, sunlight isn't supported right now. if you're looking at the map in fte or dp, make sure you disable any specular first. the texinfos are flagged to say that normals should be interpolated, but engines don't understand that yet, and yeah, I forgot sunlight, and there can still be harsh (often mid-surface) boundaries due to the maths behind the anglescale thing (at one point I was toying with the idea of these surfaces just always using a value of 1). I fixed a few bugs that were causing black fringes in my phong test map, and added support for phong+sunlight.
Here is a build: http://quakespasm.ericwa.com/job/tyrutils-ericw-spike/3/artifact/dist/tyrutils-ericw-v0.15.3-7-g05de1ad-win32.zip and the source code: https://github.com/ericwa/tyrutils-ericw/commits/smoothnstuff Hopefully this works on your map, Fifth! Note, this is based on the previous release of tyrutils-ericw (0.15.3), I'll need to do some merging later on. That seems to work actually. Very cool. Have you altered the code at all? It seems slightly less smooth than before (but still a lot better than ordinary lighting).
Seems like whole number integers on vertices or on texture alignment place a huge role in getting the lightmap to look right. Otherwise you get huge black bars or just errors in the lightmap.
I see what you mean about less smooth / more banding, I messed up something with that last build; trying to fix it..
@Fifth here's another build to try, I think it fixes the things I broke in the last one: http://quakespasm.ericwa.com/job/tyrutils-ericw-spike/9/artifact/dist/tyrutils-ericw-v0.15.3-10-g896b821-win32.zip
There is still room for improvement; I still get a few fringe artifacts on some terrain that was rotated 15 degrees, but it's pretty minor and way better than the last build. @Spike: I switched this build to use SSE; for some reason x87 vs SSE was making a difference in the barycentric coordinates code, with SSE having less artifacts when interpolating points outside the triangles. I will investigate it better at some point :-) I will give it a whirl after work. These compilers give me leaks compared to the ones I normally use
Yeah, these are less forgiving than bjp's. Raising the -epsilon parameter to qbsp can help, default is -epsilon 0.0001, try 0.001, 0.01
Here's another try...
http://quakespasm.ericwa.com/job/tyrutils-ericw-spike/10/artifact/dist/tyrutils-ericw-v0.15.3-11-g78ca193-win32.zip I notice extra/extra4 + soft crashes this one. Sorry about all the buggy builds but it'll take a bit to get all of this stuff stabilized and merged. I gotta go map first! This one appears to compile but I'm getting some black bars across surfaces even worse than the first build.
It's very likely this is due what I am testing it on (bsp pipe work) and is caused by micro-leaks and things along those lines. I suspect there might not be an easy fix for this other than to reduce detail for smoothed light maps, have smoothed textures use whole number values instead of decimals when doing its calculations? (I'm pretending I know what I'm talking about by this point, from my tests it appears that the closer to a whole number you get the better the smoothing appears to be across a surface). In some cases, the position where two vertices of two different brushes meet can become different for either brush due to differences in precision between them during the compiling. This will make the hidden orthogonal face of one of them to pop out, and this will mess up with the smoothing algorithm indeed.
It's one of the extreme cases I had predicted, but it shouldn't happen too often. ERROR: Too many vertices ( 65541 > 65535 )
Map also leaks in some mysterious way I haven't deduced yet because there is no Map only has 7901 brushes, so it shouldn't be hitting vertex limits I would think? Any reason why this limit couldn't be raised? Cool - if you need >65k verts, I think you just have to switch to bsp2 with the -bsp2 flag. I will add that to the error message.
Which is actually a good working philosophy even if you don't want to ship a BSP2. It allows you to work on an unsealed map for much longer.
Bad working practice IMO. The longer you leave something unsealed the bigger the final task of sealing it.
I prefer keeping everything sealed as I go along, even if it's with giant bricks I'll eventually delete. At least then I know that everything else is without b0rken3ss. Well, this only leaked because I'm working on this map with Lun and I merged in some of his stuff, and one of the brushes was apparently corrupt after import. Think even with some more to do, we'll still be well under and won't need to bsp2.
Depends on the map. I've had times when it would have been a fuckton of work to seal the map and it just wasn't time
I've confirmed that the problem with not all water surfaces being lit is a tools bug.
The light tool will only generate lightmaps for the liquid surfaces that gets hit by a light entity's beam. If no beams hit a liquid surface, no lightmaps will be generated for it. I couldn't figure out a simple way to fix this yet. I'm compiling the maps with qbsp -splitspecial enabled. I see, normally face->lightofs == -1 means the lightmap is black, but for liquids you need to treat -1 as "not compiled with lightmapped water, so render fullbright", is that right?
It should be easy enough to always save lightmaps for liquid faces, even if solid black. But I don't think I added lightmapped liquids support to tyrutils-ericw, do you have the code for it already? I am happy to add a command line flag for it, just don't want to waste time reimplementing it if you already coded it. that would be my fault. I added -lightwater etc args in that smoothnstuff branch, but didn't actually get around to testing it at all.
(release early, release often, right?) it should be simple enough to tweak WriteLightmaps to just write a lightofs of 0 instead of -1 when texinfo->flags&TEX_SPECIAL, with all styles still set to 255, I guess. I assume engines will be able to cope with that, but I've not checked. @Spike ah, cool. Still meaning to merge in your smoothnstuff branch, just lazy right now :)
@Fifth hm good point, this will need to be tested. Also thanks for the idea about using "smooth" prefix on texture names to enable phong shading, that could be good. re: unmerged branch
I wouldn't worry too much, I've been too lazy to fix any niggles since I uploaded it. :s re: smooth prefix I disagree in the long term on account of that making multiple smoothing groups too awkward to use effectively. supporting q2 re: lit water yes, lit water would generally imply that the lit water surfaces should also be subdivided by the qbsp in the same way that regular walls are (this means the qbsp needs to be aware of it too, and not just the light tool). engine-based turb subdivision isn't really a concern, as it doesn't affect the lightmap. there are already occasions where surfaces are overly pointy. if anything, having the qbsp subdivide turb surfaces too would reduce this the 'real' concern is that very few engines actually support lit turb surfaces re: nstuff I kinda want to build func_illusionaries and brushes with alpha-masked textures into the world too. conceptually this would be easy (assuming it doesn't have any fields set), they can just be treated like some water contents with water vising stuff, and be converted to the appropriate contents type just before qbsp outputs the unvised bsp. this should improve engine batching and stuff (and be consistent with what hlbsp support already requires from engines). there's some other things that need tweeking, but I forgot much of it. :s I've managed to fix it tonight. It should be bug-free, but it would be better to attribute a dummy lightstyle for fully dark liquids, to avoid potential "too many light styles on face" warnings.
Posted at InsideQC: http://forums.insideqc.com/viewtopic.php?f=12&t=5769 That wasn't your fault. I've implemented this code way before you released your smooth shading code.
My code still uses an old version of TyrUtils, by the way. I haven't ported it to the current releases. Lit fluids and smooth shaded surfaces... come on guys XMAS is over already and yet your still making these lovely gifts for the mapping community? :) Please continue. I do look forward to a final version with all these new toys included.
BTW the Website showing showing all the various options has been a great help getting the concepts across when it came to the dirt and sunlight options. I use light v0.15.3-7-g05de1ad and it crashes when I combine -extra4 and -soft options. While these options work fine if I use them separately.
Also I can't find if there's per entity minlight support. Adding minglight key to bmodel entities doesn't seem to work and documentation does have information about it. I think the -extra4 and -soft crash is fixed in v0.15.4: http://ericwa.github.io/tyrutils-ericw/
The per-entity minlight key is: "_minlight". There's a section of the light manual "Model Entity Keys" but it's easy to miss! That crash is really fixed in 0.15.4.
And thanks for pointing me at _minlight key, I really managed to miss it. Is it possible to make something similar to the shadow brush in hl2? It's a brush covered with texture with a special name (like skip) and doesn't have collision but casts shadows like it was a visible brush.
That would allow to manually create shadows for models (AD trees come to mind) or some new lighting effects. If something like this already exists in quake you can point me at it. you patched still in these new versions or was that a separate branch you gave me?
maybe a func_wall which is kill targeted immediately with a fence texture of leaf shadows????
dumptruck_ds: Yeah, the fixes for DP are in the main branch v0.15.4 which is what I recommend using: http://ericwa.github.io/tyrutils-ericw/
I think Spike has a better fix for the problem in qbsp in his patch, I want to test it a bit; I hope to return to working on this soon and merge his stuff and mankrip's patch :-) It would be possible to make the light raytracer trace through mdl's so they cast proper shadows. If an entity has "_shadow" "1" set and "mdl" or "model", try to load that mdl? there would need to be -basedir / -game flags to light so it can find your mdl's.
The thing that would mess it up, though, is this would likely make the mdl's black in game, since they would usually cast a shadow over where the engine samples the lightmap. So it might not be worth the effort More or less as amusement ideas.
1) WAD3 support. Screeshot More fun with more colors. Sample halflife.bsp download which Mark V can load both in the Open GL renderer (and also in the software renderer too!) Adding Half-Life map BSP 30 type of support is rather easy in the engine. 2) Rotation. You thought about it last summer. 3) Mirrors visibility support. /Like people haven't posted enough ideas in this thread! Following on from what ericw said about shadows from mdls, there's a problem obviously in how the engine lights the mdls in game.
Imagine also lighting the models properly - i.e. the light tool writes a new type of lit file that saves lightmap information for specifically flagged mdl entities - then custom engines can read these new lightmaps and if one exists for a model it uses that rather than using the default way of mdl lighting... What's the benefit, considering how modern engines already allow 24-bit external textures?
You guys rock thank you for the DP fixes. Really good to have options for folks that refuse to try other source ports.
A big static
On the ground, under the shadow is a rocket launcher --- also a Should the rocket launcher get a shadow from the object above? Or not receive a shadow because it is a Or worse, a player types r_shadows 1 in the console --- now what should happen? Then, out of nowhere, Barnak shows up and fires a rocket, generating a dynamic light to add to the mix Not only that: a decent chunk of people use DarkPlaces and it not really known whether or not DarkPlaces may ever be updated again by LordHavoc who is off doing prosperous things. I think many of those users griped quite a bit about alpha textures in the Arcane Dimensions release, in large part because AD was an exceptionally high profile release. (Complex world I've noticed that lit water gets dirtmapped, but it doesn't generates dirtmaps on the other surfaces.
Generating dirtmaps on the other surfaces could be a cheap alternative to alphablended shorelines. But maybe some mappers would prefer to just not generate dirtmaps on liquid surfaces at all. Also, my code doesn't take care of sunlights. Please take a look to see if sunlights should also be modified for backfaced liquid surfaces. Is it possible to make something similar to the shadow brush in hl2? It's a brush covered with texture with a special name (like skip) and doesn't have collision but casts shadows like it was a visible brush.
Yes, it's called info_null : - p Seriously, a brush-based entity with info_null and "_shadow" "1" should case shadows but disappears in-game. It does use up a model precache, but you should be able to safely combine all of them in your map into one entity to it only takes a single slot away. oh heh, that's a good idea. i was thinking of making think: SUB_Remove and nextthink:1.0 or something but that's even better.
I thought I would find it in here but does anyone remember the batch tool for recompiling all of quake1's maps to use the new dirt AO?
Vanilla Quake has several places, like the wooden stairs to the E4 pool in the start map, that doesn't behave well with dirtmapping.
A manual editing of such situations is recommended. I did it once. It looked like shit. :(
Maybe some tweaking could help, but it might have to be done per map. Question... sunlight supports color but does the ambient sunlight2 also support its own separate color? If not could that be added? Nice cold shadow with warm lighting done for exteriors super easy.
Nice cold shadow with warm lighting done for exteriors super easy.
That is one of my favourite setups, but i've also found other cool combos like Yellow light and green shadows (eg: the interstellar skybox) Is something changed with the way 'style' is done on lights? I have a bunch of lights in my map with no targetname, but I have manually set them to use style 12. I then was changing them in QC by directly referencing style 12 instead of doing the typical target/targetname shtick.
However, this no longer works with the new tyrutils (I was using aguirre's light before). I've checked my code and I'm still modifying style 12, but it seems like the lightmaps lost their styles..? weird, that should work. If it was broken in the tool, I'd expect the regular flicker styles 1-11 would also be broken.
Try version 0.15.4 from http://ericwa.github.io/tyrutils-ericw/ if you're on a different version? i see, for some reason, delay 4 lights cannot have lightstyles in tyrutils?
can we revert that so that it works with all lightstyles? also, it appears that delay 4, 'local minlight' is broken? it looks just like a normal light. Ah, good catch, delay 4 lights don't support lightstyles. They are handled in a different function that applies minlight, and it just assumes the style is 0. Should be easy to fix.
As a workaround, delay 3 (infinite) should be almost the same as delay 4, especially on styled lights, because the engine will be blending the base lightmap with the styled one, so you wouldn't really get a minlight effect even if the styled light was using delay 4. Delay 4 is working correctly for me otherwise, though. Maybe send over the map if you can't get it going? nm about the delay 4 not working. i think it was the dirt mapping making it look like it was attenuating. :P
Trying to find problematic brush atm. Log blames line 66597.
Using notepad++ to edit What's the catch here? How can I find actual line that compiler refers to? I remember seeing some screenshots and talk of smooth shade surfaces using textures with a prefix or suffix of some sort included to tell the compile that they should all be smoothly shaded together... It was this lovely set of tools correct? Still in development or another offshoot somewhere else that I am missing?
Feel free to correct my madness if I am imagining such things. :P Is this what you are looking for?
http://www.celephais.net/board/view_thread.php?id=61211&start=257&end=279 i've lost track actually... but is the smoothing stuff not in the normal version we pick up from github?
No rush right now. I would rather wait for a more official release I guess with some notes in the text file I can refer to. I can keep myself busy with the monster update for now.
IIRC, Spike said something about FTEQW supporting it.
Retroquad also supports it, but there's still a lot of work to be done before it gets released. Phong shading is not in the releases on github yet.
Fifth has a build with it that is working, and I hope to post a new dev build soon that has phong shading too. DeeDoubleU: weird, I don't use notepad++ but it should have a "goto line" feature that should take you to the right line. Anyway, I don't think "Brush With Duplicate Plane" is a serious warning, it's more a warning that the editor saved some redundant data. this document never gets old.
Lit water yeeeesss I look forward to that one because my level has murky water like a swamp / bog and I would love it to be dark shader fluids.
Any plans to ever include radiosity in the light compiler for Tyr like in Quake2's Light compiler?
Regarding Quake 2... possible support for it using these compilers at some point in the future? I read it does support the map format but does it output quake2.bsp files? Currently I think ArghRad is the lighting one for quake2 maps correct and no other tools came after that outdid it? I would love the AO / Dirt / Skylight / Sunlight from Tyr tools to be usable for Quake2. The main things Q2 still had is Smooth Shading and Radiosity though.. Just wondering because I love this toolset and some offshoot in the future would be great. It's actually important to understand that there are not one but two major differences to the Quake 1 lighting model in Q2. When people say "radiosity" it pays to be clear about which of these two is actually meant.
First one is actual "radiosity", as in the ability of surfaces to cast light. Second one is bounced/indirect lighting. Thing is, these two don't actually have any dependency on each other. It's possible to implement each without implementing the other. So you can have surfaces casting light but without light bounces - similar to what these tools already do with lava surfaces. And you can have indirect lighting but have it coming from light entities which the mapper must place rather than from surfaces. Or you can have both; but presence of one doesn't demand presence of the other. Also, Quake 2's radiosity actually created a result the same as if you'd just floodfilled the lightmaps with the same flat shade of orange/brown.
Yeah,maybe I shouldn't dismiss it out of hand. and with multicore lighting, it's maybe not so bad anymore.
Light bounce is indeed what I am looking for. Light bounce that picks up the colors from the surfaces it hit is one thing I liked a lot from Q2 lighting. And we all know the Orange lighting was just them having too much fun with colored lights as it was relatively new technology in games and folks sucked at using color for lighting their levels.
And no Radiosity is not redundant because we have dirt / AO... that is a hack of light occlusion not the spread of lighting. But yes Radiosity is an old way of doing GI. There are better ways to do it these days which are also much faster. Ultimately I would love to see this toolset support quake 2 and include the smooth shading and Radiosity features from Arghrad. Skiffy, yeah I'd like to implement some kind of bounced lighting, like this article: http://www.scratchapixel.com/lessons/3d-basic-rendering/global-illumination-path-tracing
Probably just supporting 1 bounce to start with. It actually looks very similar to how dirtmapping works currently. I'm not sure how hard it'd be to add Q2BSP output. Spike might know? Also, I should have a new beta soon. q2 renders much like q1bsp.
its the tracelines that are very different. that said, I think you can still use the q2 bsp tree as a point-sized hull, so that's fine for light. this is of course ignoring all the changed structs that you'd have to deal with somehow (easiest to do at compile time). One or two bounces would be fantastic. It could save a lot of trouble. As it is now, for indoor areas I probably place 3 to 5 fills for every actual light.
Personally I'd suggest adding a "_bounce" key to light entities; default if there's no key is no bounces (makes sense to keep defaults same as stock Q1 tools) and the value specifies the number of bounces.
That way lighting could be easily recreated at any time and by other tools without needing to know the command-line options that were originally used. weird, I don't use notepad++ but it should have a "goto line" feature that should take you to the right line. Anyway, I don't think "Brush With Duplicate Plane" is a serious warning, it's more a warning that the editor saved some redundant data.
It's not that I can't find exact line which correspond to log output - notepad++ shows line numbers. Problem is compiler treats line numbering differently. I think I found the problem - it doesn't count comment lines. Tested on my map backup. Compiled as is *** WARNING 03: line 45402... added a bunch of commented out lines("//asdasd") , in the beginning of the file and line number didn't change in the log. Then I replaced commented lines with empty lines, just a line break. No spaces, tabs etc Now log says *** WARNING 03: line 45406... If it is the case, then every line with entity/brush number gets ignored and line numbers 'shift' from what you would get in text editor. Sorry for little OT.
There is nice BSP importer for Blender. I would love to bake static Lightmap there and export it back to BSP. In overall some lightmap import option would be great. I know it's hard, because BSP is just fragmented mesh "dump" and lightmap is low res, but we can think about some solution. Hmm being able to read and write the lighting from and to BSP would be a rather fantastic addition but then you run into a world of pain if you want more light styles supported. how to handle flicker lights and so forth because those get layered on top and limited to the polygons they affect if I remember correctly.
As for the _bounce you could do that or just add it to the compiler as a global option. Same goes with bounce multiplier and saturation. How much energy is maintained when it bounces and how much color is picked up when it hits the surface. In Unreal you can tweak these values so its more saturated and propagates lighting further by not losing as much energy on the first bounce. yeah, I know about light styles being problematic in this situation. I'm going through source to fully understand how it works.
As for the _bounce you could do that or just add it to the compiler as a global option.
Then make it a worldspawn key, so that way lighting could be easily recreated at any time and by other tools without needing to know the command-line options that were originally used. There is a port of the half-life 1 radiosity lighting tool to quake 1 you could look at? It does bounce and phong but lacks modern features from these tools... It's called q1rad. No link sorry I'm mobile
Beta builds are moved here for now, if anyone wants to try the update phong shading.
The documentation isn't updated yet, but the readme.txt has the details on phong. basically set "_phong" "1" on func_detail/func_group/func_wall etc. Yes, spike added it, but it's untested.
There are these command-line options: [-lightturb] [-lightwater] [-lightslime] [-lightlava] [-lighttele] -lightturb just is a shortcut for water + slime + lava + tele. This is just crazy, so much advancements to ole Quake! Thank you all for the efforts, really...can't be said enough.
btw, the key for phong shading has changed since the version you were using, you no longer need to give the texture name. The main improvement of this new version is having an angle cutoff, so it won't smooth around 90 degree corners by default (the cutoff is 89 degrees.)
Another new feature: when using phong shading I suggest setting "_anglesense" "1" in worldspawn, this affects all lights in the map that don't override "_anglesense". This will make phong shading more visible and generally increase contrast.. it makes the angle that light arrives on a surface matter more than the quake default. Does it apply phong shading to the whole brush? Not sure if this is desirable behaviour.
The thing I want most is a more tolerant or forgiving compiler like txqbsp my brushwork sucks and I guarantee once my map is properly "sealed" it will leak like an incontinent old man who just drank 30 litres of water.
sounds like an AI chat bot I can get behind. Maybe Microsoft can make it their next project after Tay failed.
"ur avin a giggle m8" "u wot ill fukin slap u" doesnt seem desirable to me to always have an object fully phong shaded. I think there should be a way to choose to either have the model phong shaded or certain textures.
Dunno, I think with the angle cutoff and the fact that you can break it down into as many func_groups or func_details as you want, the current system seems pretty ok?
I'm just trying to envisage a scenario where that's not enough, and I'm struggling.... complex func_groups like this -
https://twitter.com/GavinEdgington/status/714465169649377281 Where I don't want to have to break up into small groups because it will make it a pain to move around and place. The angle cutoff is pretty flexible, if you set it to a low value like 30, only pairs of faces with normals up to 30 degrees apart will be smoothed together. So I imagine something in 30-60 would work well on that spaceship, and not add smoothing in unwanted places.
Also it's easy to check what the phong shading is doing, just compile with the light flag -phongdebug. I could add back the list of textures to restrict phong shading to, if it's really needed, though. You guys are fighting the engine's weaknesses instead of playing to its strengths. Some things you're just not going to get control over without fundamental data format changes.
Pick what game you really want to be mapping for first. We'll continue working with quake and seeing awesome new tools to use and extend the life of the game.
When trying to compile the vanilla GPL start.map:
*** WARNING 10: Reached occupant at (386 1554 132), no filling performed. This error happens in a lot of places with the vanilla you use the tyrutils qbsp? I guess so, this thread gives me the clue..
I tried to recompile those vanilla maps myself some time ago, several compilers had problems with them. Whats the cause of those? I don't know, the map were rather tidy in my eyes, all integer coords and such. We all know there aren't any fancy brushes in them. thats an old version, only watervising added to it.
https://www.quaddicted.com/files/tools/wqbsp165.zip According to the WQBSP165 docs, it doesn't support -splitspecial, so lit water won't work with it.
The problematic entity is a light torch; I've tried deleting it and creating a new one at the exact same place, and the problem still happens. It's like the tyrutils qbsp compiler is too strict about entity placement. Light entities should be treated as point entities by the QBSP compiler. I wonder if the tyrutils qbsp is checking whether some default bounding box size is out of map bounds or something. weird, can't reproduce here.
I have a START.MAP modified 4 Sep 1996. No leaks with qbsp.exe from tyrutils-ericw-v0.15.4-115-gfff8cbf. Adding -splitspecial doesn't cause leaks, either. Anyway, I've confirmed that my code for lit water wasn't implemented. -lightturb doesn't make any difference.
See the result with tyrutils-ericw-v0.15.4-115-gfff8cbf: scr_0778.png And the proper result with my old modified build: scr_0779_mankrip.png So, there's still no way to compile maps with both lit water and smooth shading. :( Oh well. I forgot about http://forums.insideqc.com/viewtopic.php?f=12&t=5769
But I'm confused.. now I realize that -splitspecial means water won't have TEX_SPECIAL set. This means lit water should "just work" without changes to light - so the -transwater stuff Spike added is unnecessary. Your patch just makes the bottom face receive light from above, rather than underwater, right? That seems sensible since typically most of the light sources will be above the water, but not having that shouldn't cause the artifacts in your first screenshot. all I can say is that the water parts of my patch were completely untested, and only half written. yeah, I got bored and then forgot about it, okay? please forgive my sins! so that I can more easily commit them in future! mwahaha!
the bright part of the water is probably a poly with no lightmap info at all (which technically means all-white-but-not-overbright instead of all-black when found on water surfaces). this would imply that much of that area is normally lit from below. I don't think it tries to subdivide water either. I guess this means that the controls for whether water should be lit should really be inside the qbsp instead. Your patch just makes the bottom face receive light from above, rather than underwater, right?
It makes each face receive light from both under and over the water, to match the lighting on the nearby walls. The normal inversion is done on a per light entity basis - the face's normals will only be inverted for light entities behind it. now I realize that -splitspecial means water won't have TEX_SPECIAL set. This means lit water should "just work" without changes to light -splitspecial also splits the water surfaces into the appropriate size for lightmap creation. typically most of the light sources will be above the water, but not having that shouldn't cause the artifacts in your first screenshot. As mentioned at InsideQC, my code includes a hack to force liquid surfaces' lightmaps to always be saved, otherwise fully dark liquids would remain fullbright. It would be better if the -splitspecial option in the qbsp was replaced with -splitturb and -splitsky options. There's no need to split sky surfaces, because there's no need to make them receive regular lighting.
It makes each face receive light from both under and over the water, to match the lighting on the nearby walls. The normal inversion is done on a per light entity basis - the face's normals will only be inverted for light entities behind it.
Ok, cool, I'll try merging this in. As mentioned at InsideQC, my code includes a hack to force liquid surfaces' lightmaps to always be saved, otherwise fully dark liquids would remain fullbright. I think this bit is missing from your patch? This does seem like a hack around an engine bug... There shouldn't be any ambiguity; in an engine supporting lit water, a face with face->styles = 255, face->lightofs = -1, TEX_SPECIAL unset, and texture name starting with '*' should be rendered black, right? This does seem like a hack around an engine bug... There shouldn't be any ambiguity; in an engine supporting lit water, a face with face->styles = 255, face->lightofs = -1, TEX_SPECIAL unset, and texture name starting with '*' should be rendered black, right?
It's not an engine bug, the lightmap data is missing from the BSP file itself. For some reason, if no lights touches a liquid surface, no lightmap data is generated for it. I've studied the light.exe code for hours and couldn't figure out what causes this, so I've just forced the lightmap data of liquid surfaces to always be generated. With no lightmap data, the surface cache for the lighting can't be created. I think this bit is missing from your patch? It's not missing, I've just implemented it in a subtle way: /* don't bother with light too far away */ if (dist > entity->fadedist) if (!backwater) // mankrip return; This allows far away lights to be casted on liquid surfaces, therefore forcing the lightmap data to be generated - even though far away lights won't add any brightness to it. It's not missing, I've just implemented it in a subtle way
Ah, I see :) It's not an engine bug, the lightmap data is missing from the BSP file itself. For some reason, if no lights touches a liquid surface, no lightmap data is generated for it This is not specific to lit water.. light.exe will not write fully black lightmaps to the bsp. It was a compression / optimization in the original light tool and engine; lightofs of -1 is rendered black. You can see this by deleting all lights except a small dim one in a large map, the lightdatasize will be only be a few hundred bytes. here's the early exit in light: (f->lightofs = -1; is set earlier) https://github.com/id-Software/Quake-Tools/blob/master/qutils/LIGHT/LTFACE.C#L542 and places where it is handled in the engine: sets surf->samples to NULL if face->lightofs is -1: https://github.com/id-Software/Quake/blob/bf4ac424ce754894ac8f1dae6a3981954bc9852d/WinQuake/gl_model.c#L795 This is not specific to lit water.. light.exe will not write fully black lightmaps to the bsp.
I know this. I don't remember all the details on why the lighting for liquids couldn't be generated if the light data wasn't present in the BSP file, but I will take a look at it again later. Alright, I've had some sleep.
Here's the proof why the lightdata for liquid surfaces must always be generated. In Mod_LoadFaces: if (!Q_strncmp(out->texinfo->texture->name,"*",1)) // turbulent { out->flags |= (SURF_DRAWTURB | SURF_DRAWTILED); The SURF_DRAWTILED flag in the engine is similar to the TEX_SPECIAL flag in the tools: it serves to indicate that the surface shouldn't have lightmaps. And it can't be eliminated, otherwise maps compiled without -splitspecial will crash the engine when trying to generate the surface caches. Right now, I'm using an if(!out->samples) statement to ensure that maps without lit water will have the SURF_DRAWTILED flag set. However, the engine loads the mtexinfo_t data through Mod_LoadTexinfo right before Mod_LoadFaces is called, so in theory it should be possible to replace the (!out->samples) check with a (texinfo.flags & TEX_SPECIAL) check. I'll modify the light tool to remove the "always save lightdata" hack, compile a map with it and change the check in the engine to see if it works. Yeah, it worked. Now instead of this:
if (!Q_strncmp(out->texinfo->texture->name,"*",1)) // turbulent { out->flags |= (SURF_DRAWTURB | SURF_DRAWTILED); // mankrip - begin if (out->texinfo->flags & TEX_SPECIAL) out->flags |= SURF_DRAWTILED; // mankrip - end if (!Q_strncmp(out->texinfo->texture->name,"*",1)) // turbulent { out->flags |= SURF_DRAWTURB; // mankrip - edited :) Thanks for making me look into this. been fighting with this for a while now.. it's more or less in a finished state I think.
windows builds source Command line flags: -bounce enables 1 bounce (this is all that's supported) -bouncedebug saves only the indirect lighting to the bsp/lit, for previewing -bouncescale scales the brightness of bounce lighting, default 1. can try 2 or 0.5 for more/less indirect light. -bouncecolorscale how much bounce lighting picks up color from the map textures, between 0 and 1. default 0 because this can lead to q2 style everything-is-gaudy. you can try 0.5 or 1. Note, this is slow! light uses visdata now, I recommend only using -bounce on vised maps because that speeds it up a lot. Other info: it works more or less like the existing "_surface" light system; point lights are generated on each face to bounce light back into the map. Currently there is no face subdivision for this, so the bounce light given off by really large faces will be coarse (all coming from just 1 point light). cool.. glad it works.
FWIW mfx and I did a ton of back and forth testing/fixing on phong shading, it's pretty solid now (though one glitch just came up that I need to look into) check the BJP tools thread, I linked a build of txqbsp that is patch to write the phong shading info. Looking at the current source, you've implemented support for properly lit water.
Thanks EricW, I'll try it out. It works flawlessly, way better than my implementation.
I've noticed -fence was removed, but that's not a big problem for me. I'll try out making some smooth shaded lit liquids now. glad the lit water works :-)
-fence I removed because it was done in a hacky way. I understand the trace code better now so can re-add it if anyone wants it. http://ericwa.github.io/tyrutils-ericw/
New features: - light: added a better options summary with the -help flag - light: added -bounce option, "_phong", "_project_texture" key - light: use vis data to accelerate lighting - light: "_minlight_exclude" key to exclude a texture from receiving minlight - light: add "_sun2" "_sun2_color" "_sun2_mangle" which creates a second sun (unrelated to "_sunlight2" which is the sky dome light) - vis: support - qbsp: add -objexport flag Bugfixes: - vis: fix ambient sounds when using func_detail, broken in tyrutils-ericw-v0.15.3 Hi, I hope I don't come across as an idiot for asking this, but what exactly am I doing wrong to get this result?
http://puu.sh/pvLvr/f08175b526.jpg Ignore the missing textures, but how do I fix my strange lighting on the map? I'm not running with any command line options, just the map bsp. Thanks for any help! it's hard to tell from that shot if it's a corrupt file, or something else.
Check for any stale Might be easiest to just post the Thanks for the suggestion about the
I tried the latest compiler tyrutils-ericw-v0.15.5-win32, but it glitches off.
I'm just an old time user, winxp etc but version tyrutils-ericw-v0.15.4-win32 goes great. No bad word here for the harworking improvements, more a shout from an old map compiler. This is an easy check engine-side and mismatches like this will never happen. Just check if com_filesize is equal to (l->filelen * 3) + 8; if so the LIT file is good, if not it's invalid and you can display a developer warning.
I think I fixed the problem, mind checking if this build works for you on XP?
I checked a rather big map I converted from Sin.
When I use the TreeqQbsp v2.03 it compiles. The newer version compile faster, but end up with a leak after bsp compiling. Of course it can be my lame '06. Use TreeQbsp if that works, or I'd recommend using rebb's version of BJP qbsp/vis: http://www.voidspark.net/projects/bjptools_xt/
The main thing in my tools is light.exe which has lots of new options. Hey EricW,
Forgive me if this functionality already exists, but I thought of something that would help with lighting control. Is it possible that a func_wall, func_detail or func_group be given a surface light flag for individual surface light control? The current setup (using the light entity) lights up each instance of the "_surface" defined texture, however there are times that I don't want every instance of that texture lit or times that I want different colours or intensities on said textures. Cheers. Hmm.. I can see that would be useful, but I'm not sure if can be done easily.
The surface light template (the light entity with "_surface" "xxx") can use any keys allowed on lights, so it would be messy to read those light keys from a func_detail/group/wall entity. As a workaround, creating a duplicate of the texture with a different name, along with a new surface light, might be the best option. As a workaround, creating a duplicate of the texture with a different name, along with a new surface light, might be the best option.
That's similar to what I did for my Jam 6 map. I used TexMex to make a custom jam666.wad specifically for that map. I had textures that were the same but with different names. One with surface light and one without. Heya, yeah... That workaround... It feels like I'd be adding bloat to the map (not that it's an issue with such small textures or modern machines).
I spent the last few hours looking through the code... It's a bit beyond my skills to modify it. But I think I'm slowly getting a handle on it. At the moment the program cycles through all entities searching for the key value "_surface", not just light entities. So it's possible to play around with lights on other entities, but there is no light drop-off with these. I suspect that this has something to do with geometry detecting as worldspawn? because the output: "Creating surface lights for texture "DOPEFISH" from template at ()" omits the origin. I thought that I might be able to modify the function to use a name key rather than a texture name for "_surface". Or modify it to read the colour and intensity keys from the geometry (as func_detail) rather than the light entity itself. Either way, I need sleep. I might come back to this later and have another crack at it. Yeah, it's true duplicating textures adds some bloat.
At the moment the program cycles through all entities searching for the key value "_surface", not just light entities I think that's an accident.. I'm currently reworking the entity handling code (on the master branch on github) to have a clear distinction between lights, bmodel entities, and other entities. "Creating surface lights for texture "DOPEFISH" from template at ()" omits the origin. Hmm, that is a bug. I thought that I might be able to modify the function to use a name key rather than a texture name for "_surface". Or modify it to read the colour and intensity keys from the geometry (as func_detail) rather than the light entity itself. The main problem with doing anything with func_detail/group in light.exe is the information about which faces correspond to the entity doesn't exist in the My hunch is it's not worth jumping through all those hoops for this feature, but it could be done. btw, another workaround worth mentioning.. there is a "-surflight_dump" flag, which writes the generated lights to a file. so you can use "_surface" lights to generate a first draft version of the map lighting, dump the generated lights to a file, delete the "_surface" lights and paste in the generated lights, and then tweak them individually. The bounce feature looks badarse. I have a question though - how are the bounce lights attenuated? Does the attenuation of bounce lights depend on the attenuation of the source lights?
The bounce lighting is hardcoded to use 1/(distance^2) for now, regardless of what the source lights used.
What happens is there's a regular lighting pass, then the average light brightness / color received by each face is calculated, which is used to create lights for the bounce lighting pass. So this means a delay 0 (linear) light uses linear falloff for its direct light, but the reflected light acts more like delay 2. Hopefully this makes sense! Sounds good!
Another question - I understand a single "bounce light" is generated for each face. This sounds similar to the surface lights features. The issue I found with that was the intensity of light created depends on the density of faces on the surface - this is a problem I found particularly noticeable with large surfaces like liquids that get split in unpredictable ways. Is the intensity of bounce lighting affected in the same way? Or are the bounce lights created taking the face area into account? Ah, yeah, I ran into that problem with surface lights as well, where lava was noticeably brighter around rocks that caused the face to be split up. Bounce lights shouldn't have that problem; they are scaled by face area, so the overall scene brightness should remain constant if faces are split up.
I also found hotspots (where you could see the individual lights) were a problem with "_surface" lights - especially when used on things like lava. The bounce lighting has a hack to work around hotspots: there's a distance threshold of 128 units, where bounce lights have the same brightness within that distance. Ace biscuits :)
Are you planning to use those bounce light ideas to improve surface lights in that regard? Been playing around with bounce and it's super cool.
Different topic...for me it seems _shadows 1 is broken now... Link to bsps and map files: https://drive.google.com/open?id=0B74rZcw0hvZpcmdUbnd1dndLckE Test case is a simple func_illusionary torch holder, with _shadows 1... temp01a.bsp, lit with tyrutils-ericw-v0.15.4-win32: http://i.imgur.com/aFzI3HK.png temp10b.bsp, lit with tyrutils-ericw-v0.15.5-win32: http://i.imgur.com/nGvFizl.png (ignore the fact that one shot has coloured light, and not the other - that was just me accidently invalidating the lit file when renaming the bsps) Note - it's not like shadows are disabled, in some cases, shadows are cast, but they are glitchy looking (e.g. the torch holder is actually shadowing the bit of floor at the base of the pillar, but the vertical sides of the pillar are ignored)
will fix this..
It's related to how sample points are positioned on a face, by tracing from the face midpoint to the desired position and stopping at any obstruction. I made _shadow models obstruct this trace, which was a mistake, so it ends up sampling the light value above the torch holder for the samples that should be located under it. The 3rd param of "_project_mangle" should be the "roll" value that controls rotation.
btw re-posting from the jam thread: I think "_project_mangle" is buggy, the docs say it expects "yaw pitch roll" like a spotlight mangle, but I think it actually wants "pitch yaw roll". I'll fix that in the next light release to be consistent with spotlights, so it's experimental/unstable only for now. Also I think I fixed the bmodel shadow issue, hoping to make a new release soon! Sorry, I'm a tard - roll totally works :} I guess I was just following the description of mangle in the readme (which said roll does nothing, so I didn't bother trying it)
However, a way of flipping the image would also be real nice (for those asymmetric stained glass window textures). Mapping Help, Post #15623:
@dumptruck_ds I got a hack for qbsp that seems to fix the DP lighting issues in your map. Here is a test build: http://quakespasm.ericwa.com/job/tyrutils-ericw/ (I just added rounding for the bsp texture vectors, the same algorithm that is used for points - if a value is within 0.0001 of an integer, round it to that integer. It's not a proper fix but it seems to work decently well.) Ericw, I can't find where I downloaded this test build, do you still have this? Also, I found possibly a bug...maybe with JACK(hammer). When I compile I get a string of warnings: line 11: Unrecognised string escape - U line 11: Unrecognised string escape - J line 11: Unrecognised string escape - D line 11: Unrecognised string escape - Q These correspond to letters in the directory path after slashes in the re: Darkplaces Lighting Fix: that stuff is in the most recent release (v0.15.5) at: http://ericwa.github.io/tyrutils-ericw/
Are you still having corrupt lightmaps in DP with this version? In my experience it only happens occasionally on faces with weird texture alignment (e.g. sheared texture). e.g. a few faces in ad_crucial.bsp from Arcane Dimensions have corrupt lightmaps in DP. about the escape sequences warning, yeah, it's confusing... I should probably just suppress the warning for the "wad" key of worldspawn. there's nothing wrong with "c:/foo/bar/naff.wad".
there IS a problem with "c:\foo\bar\naff.wad" because that contains a new line and two dodgy chars. "c:\\foo\\bar\\naff.wad" is fine of course, just ugly and specific to windows. there's an even bigger problem with "c:\foo\bar\" because that string isn't even terminated properly. And yes, I have seen that in maps, and yes it does screw things over, and yes I hate the idea of getting the engine to do special things just because of the name of the field. Its common enough that a terser and more specific warning would make sense, but I'd personally prefer if everyone just started using string markup consistently instead of varying depending on arbitrary field names. Idealism can suck sometimes. I had a quick look at the winquake source.. these are my 2 cents:
- Double-quote characters can't be escaped, whatsoever (COM_Parse). Winquake, DP, FTE all fail with parse errors if a trigger_once's "message" string is "foo\"bar" - The only escape sequence recognized by vanilla is \n, which gets converted to a newline character. (ED_NewString). Otherwise, the backslash and next character are left as-is. Writing paths like "wad" "c:\foo\bar\naff.wad" would only be dodgy if the engine/gamecode needed to use them. Everyone uses forward-slashes for paths meant to be read by the engine/QC though ("noise" "sounds/nnnn.wav", etc.) "wad" "c:\foo\" is not a problem because double quotes can't be escaped. A trigger_once with "message" "foo\" works fine in winquake, DP, and FTE (though FTE centerprints foo" instead of foo\ ) What would be a real problem is a wad path with double quotes in the directory/filename.. apparently that is forbidden on Windows, but OS X seems to permit it. Anyway, if anyone tries that, qbsp would fail to parse the How about making the compiler replace the backslash character with a forward slash, in the "wad" field only?
I always wondered why it couldn't just check the relative Quake path for any wads or just require that the wads be located in a specific folder.
enginewise, the biggest issue is that saved games and maps share parsing code. So double-quotes, new lines, carrage returns, and double-backslashes need to be saved, and thus also need to be reloaded. Otherwise mods will break - or at least mods designed for engines that can actually do string manipulation, anyway.
Whether that's consistent with winquake is somewhat irrelevant from my perspective - as you say, the only place backslashes would ever really be used in a map is in the wad key, or before an 'n'. I'm personally okay with FTE breaking compat from winquake to ensure saved games work, so long as embedded chars are rare and don't corrupt other strings. small correction: FTE's entity parsing is actually performed by qclib's misleadingly named QCC_COM_Parse - which includes consistent escapes and a special hack for "c:\foo\"<NEWLINE> in an attempt to prevent the map from being unusable. This is why you get foo" instead of foo\ - because FTE saw an escaped double-quote. The wad field *IS* parsed by engines in the case of halflife bsps, where named wad files may be required for external textures. The paths are ignored (absolute paths are a definite no in something that has been shipped/released), but if they arn't escaped properly then wads starting with an n will still get messed up (clients with download mechanisms might also attempt to download such wads from servers). Additionally, fte can load @mankrip, really its the editors that should be doing that, especially for relative paths which would allow such maps to still be compiled/loaded on linux/mac as well as windows. Obviously absolute paths are problematic regardless. @Rick, some -basedir argument for qbsp?.. and probably -game too... @mankrip, really its the editors that should be doing that
I agree that fixing this in the editors would help for when creating new maps, but for compiling old maps it wouldn't, specially if the user wants to compile some old maps directly from the commandline. The Quaddicted database has tons of maps with source available, and sometimes it's useful to recompile them without modifications, when all the user wants is to compile them in a different way (e.g. enabling translucent liquids or lit water). So, an ideal solution would be to fix this both in the editors and in the compiler - fixed editors would ensure that the maps can be compiled by any compiler, and fixed compilers would accept maps from any editor. even if you are recompiling it without any other edits, you'd probably have to fix all the wad paths anyway.
tbere's enough existing maps that auto-correcting the wad paths for any new ones is a little insignificant. I would personally rather that editors were aware of \", \n, \r, \\ when loading rather than \ getting switched to / in specific cases that 'the' engine will already need to deal with regardless. 1 well-worded warning is imho useful, 4 is excessive but still preferable to none. on a related but different note, casually recompiling all your maps isn't something I can really endorse - if you do this, you'll find yourself kicked from vanilla quakeworld servers due to having an assumed-cheat version of the map. vispatches and lit files won't trigger this issue, and can automatically run on maps without worrying so much about which qbsp originaly compiled it and how strict it may have been. This won't give you everything, so there's no single winning solution, but it should give more consistant+reliable results if you're doing it in bulk. Assuming those tools support bsp2 etc, anyway. @Rick, some -basedir argument for qbsp?.. and probably -game too...
Something like that I guess. Netradiant wants the wads in the ID1 folder. Put them there and it works fine, anywhere else and you have no textures in the editor. Frequently I dig out old maps from years ago and run them through QBSP and get no textures errors. Then I have to go manually edit to fix "wad" "E: \\ worldcraft \\ test.wad" or whatever I was using back then. I'd rather the map just used "wad" "wadname.wad" and let the compiler find it (with the assumption that the wad is somewhere in the Quake folder). yeah, if you do the classic 1:4 2:4 3:3 4:2 4:1 cylinders, you will have some angles that you can't perfectly line up the textures on with whole degrees. Not noticeable until you have a long enough surface with the same angle
I'm getting this error with my map:
light: /home/benny/Downloads/tyrutils-ericw-ericw-v0.15.5/light/light.cc:656: void CalcualateVertexNormals(const bsp2_t*): Assertion `smoothedNormals.find(v) != smoothedNormals.end()' failed. As well as a bunch of: WARNING: couldn't nudge light in solid at -1586.848267 174.062302 507.337677 Which I assume is because some of the surface light textures cover the entire brush and some are against other solids. This same map didn't give me errors with an earlier version. Running ubuntu 16.04. Also, isit possible to have phong shading on non func_details, I have a func_illusionary or two I'd like to use it on. Thanks in advance! Mind emailing me the
phong shading on any func_ should work. You have to run a full qbsp to update the btw hoping to make a new release pretty soon the new version compiled and works a treat.
also the "-gamma" command is amazing, saved me having to decrease all my light values after adding -bounce Liquid surfaces should be completely ignored when dirtmapping, but they aren't. Here's an E1M2 screenshot.
Ideally, lit liquids shouldn't receive or emit dirtmaps. I've taken that screenshot with the water fully transparent, and the map was compiled with these parameters:
$bsp_exe -nopercent -splitspecial $bspdir/$file $light_exe -extra4 -dirt -dirtmode 1 -dirtgain 0.875 -dirtscale 1.5 $bspdir/$file "_dirt" "n"
For brush models, -1 prevents dirtmapping on the brush model. Useful it the bmodel touches or sticks into the world, and you want to those ares from turning black. Default 0. Maybe it will work with water brush too? Well, actually _dirt -1 sort of works on func_detail. The water isn't dirtmapped now, but it still casts dirtmapping in the rest of the world model.
Thanks for the report, I will fix it properly.
Probably I'm checking for TEX_SPECIAL and skipping casting/receiving dirt if that is set, need to also check if the texture starts with "*" or "sky" in case splitspecial is used. Thanks.
A little feature request: Can you add individual options for -splitliquids and -splitsky? This would be more optimal than -splitspecial, since there's usually no reason to allow sky surfaces to be lit. Gosh I had no idea lit liquids were even supported in this tool. Any chance someone could give those quakespasm cheps a bit of a nudge?
Get it at: http://ericwa.github.io/tyrutils-ericw/
Not really any new features, but lots of performance improvements. It's something like 2-4x faster depending on the map. Also fixed the regression with bmodels touching the world that Kinn reported. full changelog: https://github.com/ericwa/tyrutils-ericw/releases V0.15.7 isn't compiling at all here.
** Executing... ** Command: C:\Dev\Tools\tyrutils\bin\qbsp.exe ** Parameters: -nopercent -splitturb C:\Projects\QuakeDev\Game\Quake\_QDebug_\maps\E1M2 * WARNING: File was not built! "C:\Projects\QuakeDev\Game\Quake\_QDebug_\maps\E1M2.prt" It was the 64 bits version. The 32 bits version is compiling fine. However, I'm on Win 7 64-bit.
Maybe try installing the 64-bit version of the msvc 2013 runtime (vcredist_x64.exe)?
I'll try it.
In the meantime, I've confirmed that the worst part of the dirtmapping bug is now fixed; liquids won't cast dirtmaps on the world anymore. They still receive dirtmaps, but at least this problem can be worked around by func_detailing them with _dirt -1: screenshot. Wow, 0.15.7 is incredibly fast! I don't have specific times, but it speeds up light on my map by a huge amount. No idea what kind of wizardry was performed for this, but it's really cut down on the iteration time for my map. Thanks so much!
Pritchard - awesome :)
got some bugs reported and fixed already (to be in the next release): - the "unmatched" target warning was broken - skip-textured func_'s with "_shadow" "1" were broken (for making invisible shadow casters) This one was tricky due to how I migrated light away from using the BSP for raytracing. The workaround I implemented has a limitation that the entire bmodel has to be textured with "skip", otherwise the skip textured bits don't cast shadows. Hopefully this covers the common use cases for that trick, though. Using independent surface caches for texture & lighting, and combining them in realtime.
The drawing routines of liquid textures (and now, of power-of-two textures too) were mixed with the drawing routines of regular surface-cached routines, combining the texture & lighting in realtime before blending the result into the framebuffer. It's not difficult to do, just really tedious. Involves modifying and rewriting a lot of code. @ericw: I'm curious if it would be possible to add support for func_viscluster brushes in order to negate large open spaces. I'm of course assuming that vis leafs automatically chop up empty space into leafs every 1024 units. https://developer.valvesoftware.com/wiki/Func_viscluster
Spikespasm: Host_Error: Mod_LoadLeafs: 121741 leafs exceeds limit of 70000. AFAIK, there is no chopping of space every 1024 units in this qbsp, that feature was added in quake 2's.
func_viscluster - this sounds like purely something to speed up the vis computation. It's probably possible to add to Q1 tools, it wouldn't help with reducing the number of leafs though. This just popped up now as I'm working on my map. Bounce lighting started generating random black spots in this one room of my level:
screenshot 1 Here's how it looks with bounce lighting turned off: screenshot 2 Any idea what's causing this? I was changing my light entities around, but I can't figure out what I did that caused this. Has anyone even seen this before? Help would be greatly appreciated :s At least somebody's happy about this...
I tried running the map through 0.15.5 and the issue went away. I'm guessing then that this is an issue caused by the new approximation methods in 0.15.7... I hate making a third post like this, but I tend to write in a very "stream of consciousness" manner... Anyway, I tried the -novisapprox flag on the command line and the issue persisted, so that's not the problem.
Sure, I just shot off an email.
I'm guessing it is some kind of regression from 0.15.5, although I couldn't say what other than that it seems to be bounce-related. Could somebody help me with this little thing that annoys me so much :
https://drive.google.com/file/d/0BwxYkKdSD855Mzhuc3ViNVo5YzA/view?usp=sharing bilinear filtering -- the last row of pixels blends with the first row of pixels, since it's a tiling texture.
In the black/red colored view it looks like the texture is mirror imaged. Is it one continuous surface going from from red to black or is it actually two different brushes?
It is same exact texture but one of axis is mirrored "-1" it is 128x128pxl, and those brushes are exactly 128x128 and next to each other.. so filtering is making this to happen, that is looks like it is.. like 0.5 pixels or something?
get up close and toggle between gl_nearest and gl_linear and you'll understand what's happening. You'll need to hide this pixel-wide blend by not using the full width of the texture on that polygon. Either scale it up slightly or make the polygon slightly smaller.
Any time there is a difference between the textures on adjoining surfaces there will be a noticeable line if GL filtering is used.
I call them GL seams, and any kind of rotation, x/y shift, flip, mirror, etc. will cause it. Even just pixel color differences will cause it. It is interesting.. it really looks like there isn't different pixels in this case, if I understood what you meant by that. I have no clue how GL filtering works, so basically I can't avoid these things to happen.
For example I should create texture that points out on every main angle? Then I should have seamless street texture to fill everything in middle.. I was trying to create streets which has some messy garbage on both sides but middle is a lot cleaner. It really seems like that brown/black line in middle is like texture's starting pixel line, because its end and beginning has different pixel colors. The way GL filtering works.. does it look every texture individually and doesn't care about rotation, x/y shift, flip, mirror at all and that is why something like this happens sometimes? Does it try to blend blend pixels with next pixels.. if I offset it by 1 it is already in beginning, so it tries to blend with those pixels?
What I did when making a series of similar textures was to create one common frame to use for all. Basically just the outer 1 pixel border of a 64x64 square. I used that to make different variations where the middle part was different but the pixels around all four edges are exactly the same for all.
For 128x128, I just repeated the 64x64 frame. Textures made this way have no GL filter seam/line as long as they meet at the 64 unit boundaries. To make sure no weird texture alignments happen, I never use texture lock. I only turn it on if I really need it. I thought we would have moved on from GL filtering as a society by now. Horrible concept really. Yay filtering. Let's blur all the textures. No glasses for you and contacts thrown away for you and baske in the glory that is nearsightedness on a screen.
</endrant> (P.S. I'm nearly blind and need powerful contacts so I may be biased.) Also this blending is not a compiler issue. The adjacent face has a different texture alignment and therefore is split into a separate face for blending purposes but thats the extent of compiler related. I might have used texture lock too much.. sometimes it was just left pressed down. Checking something like that multiple times, especially when placing lamps and such things confuses a bit.
I must be weird, because in some cases I want to have more control over things how wide/high some brushes should be.. and if there is only texture available that is 32x32 for example, but I want it to be 16x32 or 32x16 I have to cut it and offset other half so 'borders' are in right place. Creating new textures sounds like, I would probably fail at trying, I'm not an 2d artist by any mean. You could split an existing texture in two halves in PhotoShop, then use them in your maps. This way you wouldn't have to offset your textures, which can be tedious.
Just make the road so there's three brushes across the width instead of just two.
Thanks Kinn, but I also tried out.. scaling up a bit and it worked. But if I need to do wider roads.. then I need to use your advice.
don't worry, Linux package management just sucks..
what's the error? I have hit the same thing on debian/ubuntu before, there's some magic flag to make apt-get work usually. also maybe we should move this to the OS thread...? Thanks for being willing to look at it. Initially when I typed "cmake I thought the installation of cmake failed, because I still could not get the build process to work. I had another look, though, and it seems like the installation did work, but I need a higher version of cmake than the one that is in my OS's repositories: cmake CMake Error at CMakeLists.txt:1 (cmake_minimum_required): CMake 3.1 or higher is required. You are running version 2.8.12.2 -- Configuring incomplete, errors occurred! *If you're interested, I can post the weird stuff that happened too. Basically, as soon as I typed "sudo apt-get install cmake", the terminal window was taken over by the drupal configuration/installation process, which keeps failing. This happens whenever I type "sudo apt-get install cmake" again. OK, the problem is on my end; I thought I supported Ubuntu 14.04 but mixed up which cmake version it had. I'll see if I can adjust the cmake script and report back..
Ok, I made some changes and updated the instructions for Ubuntu 14.04 x86_64:
https://github.com/ericwa/tyrutils-ericw#ubuntu-1404 If you are running 32-bit there will be more work to do but it should be possible as well Not sure this is a bug, since it look deliberate in the code, but it would be interesting to know why. :) It treats any argument that begins with a '-' or with a '/' as a switch. Absolute path (linux), including relative to home, will begin with '/'.
Anyhow. It was an easy fix and the tools are awesome. Thank you! Will check it out and report back. Luckily I'm running 64 bit on my current primary computer.
Thanks, those instructions worked. :)
Now I just need to gather enough courage (and set aside enough time in case of repeated failure) to attempt building TB2 as per your instructions, and I'll be back in business. How are you guys going about finding leaks using netradiant and qbsp/txqbsp? Specifically looking to find the "Detail Nodes facing the Void". I can use q3map2 to find normal entity leaks, but it doesn't work for func_stuff. Is there an easier way than hunting through the map seams?
The main idea is to use the pointfiles (mapname.pts) output by qbsp/txqbsp. The quake engine can load them with the "pointfile" command. I use Trenchbroom to load them.
re: "Detail Nodes facing the Void" warning, this is unique to how func_detail was integrated into Quake tools. It's not the same as a leak.. as far as I know, the only problem that warning can cause is reduced vis quality (the fact that this is an issue at all may be a bug in vis, not sure.) To avoid the warning: having world brushes seal in the func_detail is not good enough, because detail clips away world, and the warning happens after the CSG phase when every brush is clipped against every other one. You want to ensure there are some non-detail *faces* left in the final bsp (what you see in-engine) that, if you extend the planes they are on, enclose all of the detail faces. e.g. if you have an outdoor area where the entire floor is detail, I think you will get that warning So, I did some experimenting and func_detail can actually be used to seal the map. Um...what?? Also, func_detail brushes are still being used to slice up the space into more and more leafs. Again...huh?? So func_detail is essentially worthless except to speed up vis then? I could use func_wall to save on leafs and not worry about leaks mysteriously showing up when I hide the (leak would be there anyway).
I thought the point of func_detail was to not affect vis, like, at all. No leafs added, no slicing other brushes. Is it possible for func_detail to work like in Source: https://developer.valvesoftware.com/wiki/Func_detail Assuming latest ericw tools are used, what are the downsides of using buttloads of func_wall in place of func_detail?
func_wall lighting might get a bit funky. You'd have to remember to include things like _shadows and _dirt etc.
That's the thing I can think of mostly being affected. The other issue with using brush entities is that you are contributing to the entity count. If you're trying to stay under 255 ents for extra compatibility I guess then it's better to stick with func_detail.
func_wall downsides:
- counts towards entity limits (I guess they are probably static ents?) - likely will have overdraw? - they can have different rendering performance quirks depending on the engine (and how well the GL driver optimizes what the engine is doing). Quakespasm: there is some setup cost per-func_wall rendered, but they use the same drawing code as the world, so they can have lots of faces and still render fast Fitz085 and I believe MarkV use R_DrawSequentialPoly which scales badly on funcs with lots of faces Also, func_detail needs to create leafs, otherwise collision wouldn't work, rendering might break depending on the engine. The engine needs to have been designed with func_detail in mind to support not creating leaves (q2/q3/source?).
Ok. On a related note, can func_wall have keys added to receive and block lighting identically to a func_detail.
Is there a simple reason why the light tools can't be extended to produce lightmaps of essentially arbitrary resolution?
More generallly, -extra 4 is still producing aliased shadows for me (e.g. here: https://ubiquitousgame.files.wordpress.com/2016/09/01.jpg). Is there anything I could try to get better looking lightmap resolution? It would require new file formats and engine support I would imagine.
This was thoroughly investigated a while back and actually got working, and from what I remember the feedback went something like: "Oh this is cool but a bit too sharp actually, can the shadows be made softer?" (makes it softer) "Hmmm, even softer?" (makes it even softer) "...softer still?...ok actually on reflection I think quake's default lightmap resolution actually looks better but thanks anyway ^_^" I imagine the tools to generate the lightmaps weren't as good then? From what I can tell the quality of lighting improved quite a bit in the last N years.
This is a limitation of the vanilla BSP format. Lit2 solves it, but only a few engines supports it.
I think it was only something like one year ago when this was explored. Might be wrong - my temporal awareness is somewhat shoddy to say the least.
higher-res lightmaps have their perks: http://triptohell.info/moodles/junk/fte-20150311190731-0.jpg
the biggest issue is that lightmap changes (both flashing lights and dlights) become abusive, which essentually requires multithreading and/or rtlights in order to prevent it being unplayable, which greatly limits the number of engines willing to implement it. crank it up to max and the bsp files become insanely huge, but that's only to be expected from poor-man's megatexture. :) either way, the stepping issue doesn't really go away. the only way to fix that is to use cubic filtering instead of linear filtering. currently this requires custom glsl. I really ought to investigate it some time. :s I think there is also some room to improve the filtering within light.exe.. it's using a box filter for -soft and -extra, which is the worst possible filter, I want to try lancosz or others.
Anyway to get the best quality currently you should combine -soft and -extra4. -extra4 alone will be sharper but have more aliasing the biggest issue is that lightmap changes (both flashing lights and dlights) become abusive, which essentually requires multithreading and/or rtlights in order to prevent it being unplayable, which greatly limits the number of engines willing to implement it.
As an aside, I've always thought the ideal handling for light styles would be to upload the four styles as 4 separate textures and combine them using multitexture (or multiple passses) when rendering. Are there any engines that do this? rmqe does, iirc.
my engine that tries to draw the entire worldmodel in a single draw call also does. the fragment shader is a bit faster if you do all 4 lightmaps with a single texture, at least when there's no lit support. you can then do the style->value lookups in the vertex shader and your fragment shader basically gains only a dot4product compared to a luma texture. As an aside, I've always thought the ideal handling for light styles would be to upload the four styles as 4 separate textures and combine them using multitexture (or multiple passses) when rendering. Are there any engines that do this?
I also have working, but unreleased, Q2 code that does this. It also needs 2X modulate support, but in practice anything that's not of 3DFX vintage has that. It's possible with basic GL_ARB_texture_env_combine but much easier (and nicer) with shaders. The basic formula is texture * light0 * style0 + texture * light1 * style1 + texture * light2 * style2 + texture * light3 * style3, or texture * (light0 * style0 + light1 * style1 + light2 * style2 + light3 * style3). You can do it with multitexture and a single shader, substituting 0 for the style value (and using an all-black texture) for styles that a surface doesn't have. Pros is code simplicity, everything goes through the one code path, fewer state changes; con is extra texture accesses. You can do it with multitexture and 4 separate shaders, trading off texture lookups versus state changes. You can do it with multipass and a single shader; similar tradeoff as above but with added overhead of extra draw calls too. Fastest way is if you've monochrome lighting so it becomes a single texture access and a dotproduct: texture * dot (lightmap, styles). Performance is similar to stock GLQuake for scenes without many lightstyle animations; it's one of those optimizations where you shouldn't expect it to double your framerate in DM3, but if you play a map with lots of lightstyles it works great. What's nice is that you can then add lightstyle interpolation to the engine and get it for free. For dynamic lights you do something similar to RT lights which works much nicer for MDL files because you've now got proper directional shading and attenuation on them instead of them just being uniformly lit. Pros is code simplicity, everything goes through the one code path, fewer state changes; con is extra texture accesses.
Would the texture accesses problem be solved by making sure all 4 styles end up on the same texture atlas? Or is it just the literal lookup into 4 different pixel locations? And is that anywhere near the cost of uploading new textures? Or is it just the literal lookup into 4 different pixel locations? And is that anywhere near the cost of uploading new textures?
It's 4 different locations, one for each style. It can be mitigated by replacing texcoords for unused styles in a surface with {0,0} (so that the lookup will be in the GPU's texture cache) or by using a 1x1 black texture for lightmaps of unused styles (same reason), but again we're getting into state change tradeoffs. Comparison with cost of uploading new textures is an "it depends" answer. If you've a switchable lightstyle like the ramp in e1m1 then uploading is going to be faster. If you've a room with hundreds of surfaces each of which has multiple torch flicker animations on it, then uploading is going to be slower. On balance I think that irrespective of which method you use to handle animation, it's the right kind of optimization. What's already fast either remains fast or drops a little, whereas performance of what's slow comes up and best case is levelled. I forgot to mention this.
Rather than using 4 textures, one for each style, with 3 of the RGBA channels used and the 4th unused, an alternative is to use 3 textures, one for each of R, G, B with the styles packed into the 4 channels. That both saves memory and reduces those 4 lookups to 3. Seeing as we're talking about lightstyles etc. right now I thought this would be a good time to ask: had there ever been an attempt to raise the number of lightmaps past 4?
I ask because as a mapper i've run into the issue a few times, and its pretty annoying when it crops up. i understand the need for such a low limit in the past, but is there any particular reason other than a desire for compatibility that we still have it? I can't imagine that there are many computers today that struggle to switch lightmaps frequently... It's not a problem for RT lights.
For lightmaps it would need BSP format changes as well as engine and tool changes. I don't know/can't remember why we didn't do it for BSP2. One thing that may help, in the next release I made light.exe not blow up when the "too many light styles on a face" warning happens. It will compute all the light styles and then save the brightest 4 per face.
There'll still be a warning, right? Not knowing why you're not getting the desired results would be pretty frustrating and cause a lot of forum posts!
One of the quirks of Quake, in terms of engine, tools and formats, is that it's stuffed full of hard-coded magic numbers like this that can make extending limits while retaining compatibility sometimes impossible.
Unless you actually knew, you'd think that it would be reasonable to suppose that each face structure would have an int member indicating how many lightstyles it has. I know I'd think that. So you might be surprised to learn that it actually doesn't - instead there's a flat array of 4 styles and that's fixed by the BSP format. What's even more fun is that the code is littered with cases where sometimes a #define is used but other times the number 4 is hard-coded. That does sound like great fun.
I like to daydream about one day just taking quake and gutting it and building something similar that's barely compatible but much more friendly and so on. Really just daydreams though, I don't know C. And I don't want to really deal with fun I've been wondering if I could use this feature to get smooth blends of textures for my map, i.e. a gravel path that fades smoothly into grass, but unfortunately all that _project_texture seems to do is basically tint the colour of the light a bit, with some textures that have significant colour differences producing multi-coloured lights
Part of me thinks that this is something that just can't be overcome; an issue with lightmap resolution, or something like that. But I feel like I should still ask; is it possible to get more fidelity out of this? If it's already possible, how do I do it? It's hardly dealbreaking if it's infeasible, but it'd be nice to have... texture projections are still just a lightmap trick, so there's a resolution of 1/16th of your normal res. think of it as just a filter over the light, projected by a single side of a small cube around the light (you can distort the cube a bit by using the fov, the other 5 faces of the cube are black).
so yes, all it does is basically tint the colour of the light. which means that if you make some white image and scale that up 16-fold, then you'll get the same lightmap res as the nearby textures without depending on engine extensions (lit2 would allow you to scale the lightmap per-func_detail without needing new textures). But... you'll probably end up shining light on the neighbouring surfaces too, so it'll be a bit too hard to control. it'd be nice to do some sort of alpha blending from one side of a face to another, for a nice blend, but politics and compat issues would make that an absolute nightmare. If you really want that, q3bsp+terrain shaders is the only proper answer right now. The only portable (across engines) way to increase the lightmap resolution is kind of a hack, scale up a texture by 2x in the wad file (e.g. 64x64 to 128x128), and then use a texture scale of 0.5 in the map editor.
_project_texture only really works for stained-glass windows like spike's screenshot in post #558. Another point: the projected texture will look less like mush if it's projected over a larger area / further from the light source. For texture blends the best bet is just make custom textures or use a wad with them. Even ignoring the resolution issue, the lightmaps are multiplied by the texture colors, so it would look like grass projected on top of rocks etc. I figured there would be issues like that. My gravel path shall continue to fail the existence test. Thanks for the explanation though, good to have my suspicions confirmed.
I remember some fantastic-looking hi-res textures of earthy/rocky paths blending into the grass on the sides, made for Oblivion. They might not be exactly what you're looking for but they could be worth checking out for inspiration.
It would be nice, and maybe i'll take a look in that direction, but i'm not too invested in this idea and frankly finding an appropriate wad or making one myself would take far too much effort for the results i'm looking to get.
You can see where the path would go here, on the grass with the two dogs. It's a pretty small area and so i'm just going to drop the issue now. Called quake texture tool.
Allows you to blend two textures together. I've tried it and it gives mixed results. Give it a whirl, you could probably get better results using other methods, but the tool is pretty quick. https://www.quaddicted.com/files/tools/quake_texture_tool_v0_1_0.zip There's a nice one in : <a href="https://www.quaddicted.com/files/wads/ik2k.zip_ik2k.wad.jpg">9th row, on the right.. it looks better than that preview, i think it's 128x128
someone needs to come up with something cool with fence textures acting as decals. especially if they move...
that does look nice (judging by the preview) but I'm not seeing any corner pieces; that's what's stopped me from using the hexen 2 textures too, since that's where my grass is from right now; it has a dirt path, but there's no texture for the inner corner so it's pretty useless.
Can't you find a way to make a corner yourself with two 45-degree-cut brushes and play with texture alignment so the seam isn't too noticeable?
Perhaps, but historically it hasn't worked very well. The hexen textures have a very nice blend into the dirt texture, with defined blades of grass that'd make it difficult to capture the same effect with brushwork (i'd say impossible).
Trying to make up for texture deficiencies with brushwork is normally a losing battle. Quake's gridsize only goes so small, after all. Just fire up Zendar and look at the ground in the opening valley. That sort of thing is the best way of doing it I think.
Quake's all a bit "squint your eyes and it kinda works". There's no point getting too perfectionist about this. There are 3
I only ask cause I've never seen anything but "embree.dll, tbb.dll and tbbmalloc.dll" I'm using an external raytracer (embree) in light now, mostly for performance. It's open source (Apache v2) and developed by Intel so it shouldn't be sketchy. The dll's are downloaded from: https://github.com/embree/embree/releases
I would say exoskeleton rather than crutch. Nice lazy light work, Pritch, I love the chiaroscuro effect.
Thanks, it's always nice to get compliments with fancy words I have to Google. I'm not really ashamed of how much I'm abusing the feature, it's a wonderful way to get smooth, soft lighting (those jagged edges are with soft and extra4!). I try to rely on visible sources where possible so having them reach as far as possible is a great help in a lot of ways.
I will say though that it's a shame it doesn't work for switchable lights! That's how I ended up with that before and after pic, adding a targetname to the light... Ruined my idea of an ambush in the dark... "I try to rely on visible sources where possible so having them reach as far as possible is a great help in a lot of ways."
I haven't reached the point where I try this feature yet, but I bet it indeed saves a lot of time by making the placement of additional ambient lights unnecessary. "I will say though that it's a shame it doesn't work for switchable lights!" Hmmm... Eric? Would that be within the realm of possibilities for a future update? I'll look into it! It was something I left out initially to keep things simpler. Nice screenshots!
Any chance of supporting the "brush primitives" map format (like how we support Valve 220) ?
As far as I am aware, the "brush primitives" format was introduced for Quake 3 engine games, and is supported by GTKRadiant-based editors. It's like Valve 220 in that it allows textures to be projected properly on the brush face, instead of just the coordinate axes. I don't know too much about it, but there's an overview of the various map formats here: http://quark.sourceforge.net/infobase/src.topics.face.html Should be doable, I imagine I can just grab the code from q3map2. I'll just need to find q3 map sources that use that format to test it with.
That would be ace biscuits :) It would allow better texturing possibilities for Radiant users, of which there are quite a few here :)
I think I got brush primitives working - alpha build!
Hopefully radiant can be configured to use brush primitives and quake 1 textures at the same time. I only really tested the texture alignment with a brush primitives map saved with Quark, although I did check that a map saved with the new netradiant can be parsed, so will be interesting to see if this works. Wow that was quick :)
Here's a test map in the Quake3 BP format: https://dl.dropboxusercontent.com/u/61424391/Quake%20Stuff/testq1q3.map I compiled it with your new build and it seems to work fine, cheers! So, here's how you set up NetRadiant to use the BP format: Edit the q1.game file located somewhere like here: "C:/NetRadiant/netradiant-custom/netradiant-custom-20160911/games/q1.game" All you have to do is set brushtypes="quake3" and maptypes="mapq3". Then in the editor, go to preferences->settings->brush and make sure the "brush primitives" checkbox is turned on. Restart the editor. Now, when you are in quake 1 mode in NetRadiant, you will be reading and writing maps in the Quake3 BP format. Everything else is still Quake 1 style - wad textures work fine and all that. I still need to pester the NetRadiant guy a bit more though. In the test map, I have included a crude terrain ceiling to illustrate the main problem with the editor's handling of the BP map format - which is ironic considering the format was created for Radiant in the first place... When in BP mode there currently seems to be no way of telling a face to use the old axial projection - it's face projection all the time. Face projection is great to avoid the weird skewed textures on certain angled surfaces that you'd get in quake's original map format, but for stuff like gentle terrain you would almost always want axial projection to get seamless texturing. The terrain in the map looks terrible because of this. But yeah I just need to pester the guy maintaining NetRadiant to add the ability to choose face or axial projection on a surface. A little bonus thing you could do that is not important, but might be worth doing, would be to read Quake3's "detail" flag on brushes, as an alternative to using func_detail - this might come in handy for people who want to try converting existing Quake 3 maps over to Quake. Hmm...not sure this is a bug or not, jpegs below:
Func_wall no _shadow: computer_noshadow Func_wall with _shadow 1: computer_shadow1 See the hard line where the face changes textures at the trim baseboard? Tried messing with the brushwork and got these: uh-oh and_more_breakiness.jpg I had that happen to me once on a map I was working on, my solution was to reduce the intersection of the brushes as much as possible. So the wall behind would need to be cut to shape around the computer panel rather than having them simply overlap. Try it and see if it helps, I guess.
I think that bug was fixed in v0.15.7 :) If you're on an older version, updating to the latest should fix it.
So I was messing about with flashing lights and realised that due to limitations of the engine there are certain things I can't do that are pretty simple. Things like having alternating flashing lights (without needing extra trigger/relay entities). Or having a light that has a fade and a flash sequence.
So I was thinking about custom lightstyles. Here is the idea: A light entity with the tag "_lightstyle" which allows users to have cusom "id" format lightstyles: string value a-z (example: "aallzzll"). What are your thoughts? Phong shading and Deviance are easy to understand as "options" you can exercise in your mapping. But I am a little confused about bounce(radiosity) and dirtmapping(AO).
Bounce: From my limited knowledge IIRC radiosity lighting is superior to standard Q1 lighting, yes? And if so, would that be considered to be the default choice(standard) for mappers from now on going forward? Dirtmapping: Should this also become standard practice in lighting a map, or more still just an option for giving a certain design/artistic "look"? Thanks. Both options can provide a pretty significantly different look. Bounce lighting is one that I personally see as almost always desirable, with the exception that it makes it quite difficult to have stark contrasts in your lighting (which you may or may not want to have depending on specific situations) due to the fact that light will, well, bounce! I can't think of a situation where it's made a map look bad, but by no means is it necessary to use if you want your map to look good.
Dirtmapping, in my mind, is a bit more subjective. It certainly helps to add a "look" to your map, although depending on how you tweak the values that can either be very intense or very minor. It's certainly not appropriate for all situations, but taken in moderation I think that it's generally useful. I think the same really goes for a lot of the modification's ericw has made; yes, they do have a distinct look that changes how the final product uses, but it's generally a tasteful, inoffensive change that most people would take as being an improvement. I mean, compared to coloured lighting (especially when ported back into older maps i.e. the original game) it's pretty harmless, and we've learned to live with the existence of that technology... Anyway, I'm not exactly prolific enough to have a "default" for my maps, since I have about... 3 to my name, none released, but so far I've always used bounce and dirt with varying settings in my creations. I haven't tested it in a while but I believe you can use lights with negative brightness to combat the horrors of bounce lighting (even though it saves time putting in fill lights).
ericw: would it be possible to compensate for lightmap seams as described in this paper?
One of those "would be nice" features. I tried 0.15.8 a bit tonight. There seems to be problems with lights inside sky brushes or something. Or maybe a problem with very low values for light?
Here's one that seems to have just disappeared. BJ/MH Light http://quaketastic.com/files/screen_shots/wish13_i.jpg 0.15.8 Light http://quaketastic.com/files/screen_shots/wish13_i_2.jpg That light shining through the window is in a sky brush, but just barely. It's almost in the void. The values are light 75 delay 5 wait I saw other differences, but that's the most obvious. Thanks; I didn't realize regular light entities were supposed to pass though sky faces. Should be an easy fix.
The thing is, most of them still did. The only one I noticed that didn't was the one in those screenshots. That's why it stood out. Is it possible it got "nudged" into the void?
On the good side, about 10 of the 30 or so lights it found "in solid" actually were old misplaced lights. Also to note, there was no reduction in marksurfaces using -forcegoodtree. The number actually went up a bit. Using txqbsp_xt always gives a drop of around 1200 or so. Download here
Changes: - light: fix black fringes on bmodels that are touching against the world - light: light passing through glass lights up the back side - light: bmodels with "_alpha" < 1 and "_shadow" "1" set cast tinted shadows - qbsp: support Quake 3 "Brush Primitives" - qbsp: save "_mincolor" for func_detail/group to the - qbsp: performance improvements To elaborate on the "fix black fringes on bmodels" thing, v0.15.8 had a pretty severe bug where every func_door (or any bmodel) would have black edges wherever it touched the world, like an ugly/broken looking version of AO. The reason I broke that in v0.15.8 was, I was trying to fix another bug, where bmodels (func_wall, etc.) that intersect the world, or have a face touching the world, would have broken lighting (usually all-black faces). Typical case where this would happen would be a large func_wall window that has a world brush slicing through it (or just touching the front). So, that bug is back, because the "fix" I tried was much worse (black fringes on all bmodels). If you have a func_wall with black faces / broken lighting, the fix is to manually clip it against the world so it doesn't stick into the world anywhere. I'll see if I can come up with a better fix next version That's great to hear, I encountered the black fringe issue before and it is good to know it may be fixed on this release!
Would it be possible to hit both bugs by having the compiler test if the bmodel intersects or not? Or would that require multiple passes or something like that? (Assuming extra passes would suck, which when it comes to speed they probably would :/)
Performance improvements - intrigued, my latest maps have been bottlenecked by Qbsp which is wierd since vis always took the longest until recent improved versions. Curious what improvements you've made.
@Qmaster - performance improvements are from undoing some mistakes I made when C++-izing bits of qbsp (unnecessary std::map lookups). Qbsp could be made a lot faster, though. e.g. Quake 2's is multithreaded.
Pritchard, I'm not sure if knowing if the bmodel intersected the world would help. I think I need to do something like: test whether each sample point is in the void or not, and just not use the ones that are in the void. How do you do lit liquids? I tried the commandline flags people are talking about here (-litturb etc.) and it just gives an error and doesn't run light. Was it removed or something?
-splitturb option for qbsp.exe should do it; light.exe will automatically detect this and save lightmaps for the water. Looks like that option is missing from the docs.
Engine support is fairly rare (?) - I don't know what supports it, off hand. Engine support is fairly rare (?) - I don't know what supports it, off hand.
So I can "bake" lightmap on the water and it will be still fullbright in some engines, or what? So I can "bake" lightmap on the water and it will be still fullbright in some engines, or what?
Yes. There is that one software render engine that mankrip is doing that supports it I think. That's the only one I am aware of. However, give other engine authors a slap and a tickle in the right place and I'm sure this feature can be adopted elsewhere (it bloomin well should be because it's coolbeans) I just checked my Jam 7 map to be sure I was remembering correctly, and Darkplaces supports lit water too, at least version 15:49:13 May 13 2014. Incidentally, I discovered the final version of my map is apparently broken in that engine for a different reason, which is just fantastic, but the lit water works as expected. It's easier to see the effect with r_wateralpha 1, of course.
All this talk of lightstyles in the AD thread got me thinking...
Say you had a moving object with start and end positions in radically different lighting conditions. Imagine you could tell the light tool to light this object in position 1, assigning all light on it to lightstyle "x", and then light it again in position 2, assigning the light to style "y". Then in the QuakeC you could fade lightstyles x and y in and out as the object moved. Just an idea, but it struck me as interesting that this sort of cheap dynamic light effect boils down to being a compiler thing + a bit of QC. You could even go nuts and leverage the fact you can have up to 4 lightstyles on the object, so can specify up to 4 different positions to light it in, allowing much more accuracy in the blending as the object moves around. I may be missing a few "gotchas" but, does the theory sound basically correct? there are only 64 lightstyles total, and 32 of them are used by light.exe for switchable lights, the other 32 for "styled" lights (flickering/pulsing) -- of which about 11 are actually used in id1 progs. So I think this would work if you were willing to dedicate 2-4 styles just for that one moving object, and write a quakec modification as necessary to do the proper fading.
I guess it would be something that could become an attractive idea when you have situations like in Hrimfaxi's rrp map, where there is a large section of a big room that moves up through several floors.
Wouldn't be worth it for run-of-the-mill platforms and what not, but for big setpiece movers I can see it having the potential to look quite sexy. There are 64 lightstyles, but Quake's BSP format only supports 4 different styles per surface.
IMHO, a more practical solution would be to use the "Lit BSP models" feature from the Makaqu engine 1.6 (used to adjust the brightness of the ammo boxes to the ambient lighting) and add an option to make it also work on internal BSP submodels. I only suggest the idea because it struck me as interesting that it doesn't need a custom engine.
I'd be happy to use up a handful of lightstyles on a moving room setpiece. How is the "ambient lighting" determined in Makaqu? I think the challenge is working out a standard between the mapper, light.exe, and the QC. light needs to have a copy of the logic for the func_door/train or whatever is moving. Func_door would be pretty easy, func_train would be trickier (unless the mapper marks which path_corner's to calculate lighting at, up to 4 per train?).
Also, things like making sunlight/sunlight2 use a lightstyle other than the default of 0 are certainly possible without too much work in the light tool. Easiest way might be for the mapper to specify a lightstyle number with a worldpawn key like "_sunlight_style" - light would then use that for the sunlight, and know not to assign that style number for a switchable light. I guess one implementation could be...
I would suggest light.exe should not need to know how the object moves - it only needs to know the positions to light it at - these could be specified in the map with "info_lightmodel" entities - they would mark the various positions (mins?) of the brushmodel. The info_lightmodel would target the brushmodel (to let light.exe know what to light, obviously), and also specify the "style" number to use. your sunlight suggestion is cool.
Question: what happens with bounce light coming off a surface with styled lights? Is there a bounce for each style? Mmm - yes the info_lightmodel sounds good.
Currently styled lights don't bounce at all, this was something I limited to make the first version of the code simpler, but I want to support it eventually. Yeah I guess bouncing styles would have a similar problem to styles on lights with 1/x or 1/x^2 falloffs: you could propagate styles to tons of surfaces everywhere and it could get out of control.
I think for most styled lights, you won't really notice the lack of bounce, but if you start doing styled sunlight, then I think sunlight bounce would be noticeable and you'd expect it to change like the direct sunlight does. How is the "ambient lighting" determined in Makaqu?
Nearly the same as in MDL models, using R_LightPoint and the entity origin, offset by the relative model position. As for a pure QC + assets workaround... How about this: - Make one model on origin A (start), and another on origin B (end). - Set the B model to non-solid, and enlarge it by 1 unit (not 1%) on each direction. - In the QC code, make the B model follow the origin of the A model. - Implement code to fade the Almost every custom engine supports Does light do simplified calculations on bmodels with _shadow 1? I get weird squares of shadows on solids from complex bmodels (in places, not everywhere). Splitting a big bmodel into a few smaller ones doesn't change anything. Any suggessions?
There have been problems with _shadow 1 bmodels intersecting/touching each other, or the world. The faces that are touching can have artifacts, either black fringes or solid black or other artifacts.
I forget what the current status is, because I've been swapping in and out hacks to try to combat that.. but I'm working on a more correct fix. Other than that, there shouldn't be any problem with shadows from bmodels. Check your version is 0.15.9, or feel free to email me screenshot/map if it seems like a different bug. Yeah, if they're not touching the problem should not occur (at least a 2 unit gap. The light sample points are 1 unit above the face, having these sample points blocked is what causes issues)
The use of an origin brush for rotating entities doesn't work with -hexen2. The origin brush is visible ingame and the brush still rotates around the map origin
Yeah, there is no origin brush support at the moment.
Current behaviour is (designed for Q1 hipnotic rotation): If a brush entity classname starts with "rotate_", qbsp looks at the "target" key, and searches for the targetted (point) entity. That point entity's origin becomes the origin of the brush entity. I'm not sure if that is compatible with Hexen 2 rotation? Hexen 2's is more like half-life, though it uses the "flags" key for how many degrees it should rotate. I think you can manually enter the origin to specify where it should rotate but that doesn't seem to work right in trenchbroom
You can actually manually put the origin in, but you have to place the brush at the map origin or it ends up outside the map.
Kind of a pain to light it properly but it works otherwise. Tried implementing it, download available on the github issue
It might be handy for Quake too. Hope I did it right.. if there is a brush in a brush entity with the "origin" texture, the center of that brush is used as the model origin (qbsp translates the model so that point is at 0 0 0, and sets the "origin" key). Also light no longer cares about the classname starting with "rotate_", if the brush entity has an "origin" key set to something other than "0 0 0", the faces will be translated to that position during lighting (hopefully doesn't break anything?) Is there a standard for final compile settings? I assume people leave BSP and VIS parameters alone, except maybe -bsp2 for BSP? Is that something everyone uses, or only if the map somehow doesn't compile as a regular BSP? Is there any reason not to use BSP2?
For light, judging by the doc page on Eric's site, I'd guess people use -extra4, -gate 1, -bounce 1, and maybe some -soft? Yeah, the main thing is to use -extra4 on light; the other tools can stay with the default settings.
-gate 1 is probably fine but it's actually a faster/lower quality option than the default. -bounce 1 is something you want to use from the beginning if you are going to use it, since it'll change the entire look of the map. -soft is personal taste, it will make the final lightmap softer. Is there any reason not to use BSP2? It's best not to use the -bsp2 flag unless it's needed so the map will run on the widest range of engines (including vanilla ones). qbsp will print an error if the map exceeds limits so that it requires -bsp2. Tougher to generalize as those are more artistic choices. The screenshots / settings on the website give some starting points, you can also check map sources for ideas.
I did check out some of the AD maps and was surprised to find very little dirt is used. Judging by the 1000 Cuts screenies I'd expect a lot more dirt, but maybe that's because of the greyscale. Sock seems to use 96 dirt, I'd think an intermediate between 256-512 would look nice.
Sock seems to use 96 dirt, I'd think an intermediate between 256-512 would look nice.
Sock's 96 dirtdepth is not a bad value actually. A dirtdepth of 256-512 is something that works when looking at a distant shot of an otherwise fullbright map, like in the preview image on ericw's page. For a normally lit map, it means surfaces 256-512 units away will be darkening your target surface, which can just suck all the light out of interior rooms quite easily. I know it's probably a good value; Sock chose it. I have no Quake experience so all I have to go on are Eric's pics and various worldspawns. I need to jump in and make myself a test map.
I prefer to set things like bounce in worldspawn and keep my compilation configuration as "universal" as possible. I just use -extra4 and -soft on my light config, and I usually use bsp2 for qbsp because what current engine doesn't support it, anyway?
Yeah, i'm pretty sure. Also, because of otp, i'm only going to release my maps in bsp2 from now on. (Not that I release any maps...)
Same. I only use in my compilation setup are the ones that can ONLY go in there. Otherwise the rest go in worldspawn.
Actually, speaking out loud, I need to add those to my I have
Open the
You can use the bounce parameters in the worldspawn? It doesn't say that on Eric's site.
Good spot. Looks like the "Worldspawn Keys" section needs updating http://ericwa.github.io/tyrutils-ericw/doc/light.html I did check out some of the AD maps
Every mapper did their own thing and there are some who did not use detail brushwork or utilize lit files. Personally I compiled all my maps in AD with dirt parameters which are setup on the worldspawn so everyone can reproduce the results for themselves. Sock seems to use 96 dirt Its dangerous to take that parameter in isolation because the dirt AO system has several parameters which all play key roles in how the dirt is applied. You also need to remember the dirt parameters work with 2 other key systems, architecture and light entities! I did countless tests with the new dirt AO system and found I wanted a strong dirt in corners that worked with finer brushwork detail. I also only added dirt to strong light source (excluded from all small/ambient light sources) and excluded it from most func bmodel entities. There are many examples of different ways to setup lights and I would highly recommend anyone to look at Honey by CZG and The Hell that's coming by warrenm because both have source files included. Honey uses strong point lights with many low fill (delay5) ambient lights and THTC uses many strong fill (delay5) lights for large windows and subtle fill lights for the rest. Both systems have different advantages and both create a different atmosphere. They are both pre dirt AO options, but they are useful for understanding lighting. The final piece to the puzzle is architecture and in my AD maps I often have _dirt and _minlight parameters on bmodels and certain architecture to correct the overall dirt parameters I use. Its impossible to expect one global setting will fix all light issues and that is why I requested Eric add the ability to all map entities to switch lighting features on/off. I also recommend everyone stop using the compiler for options and use the worldspawn instead! Why you might ask? Well so that everyone can learn from your source maps and try to understand how you did things. I usually use bsp2 for qbsp As I have said to Eric, this parameter should be on the worldspawn, it is really annoying to have to keep switching stuff around for different maps. The more parameters on worldspawn the better. Which fgd are you guys using? I have a quake.fgd that came with JACK and then the AD fgd Just edit/update either file with all the extra stuff you want. You can open a FGD in a text editor and cut and paste stuff around. Jack will run an error check on the file for you when it loads up a map, so its easy to spot errors. The format is not overly complex, the AD version should have plenty of examples of how to use the 'base' function and syntax formats for entity key types. I also only added dirt to strong light source (excluded from all small/ambient light sources)
Sorry it is the other way around, I have not checked my parameters in a long time because I just use the same setup each new map. Strong source lights = no dirt Ambient source lights = AO dirt The dirt is excluded from the strong light sources so that you get the hotness effect around lights. Remember Dirt AO will make every surface look darker and make strong lights sources feel dull. Here is some more lighting tips to think about. I also recommend everyone stop using the compiler for options and use the worldspawn instead! Why you might ask? Well so that everyone can learn from your source maps and try to understand how you did things.
That's a really good point. Having as many compile settings as possible inside the map file makes it much more portable.
Imagine working on the map on different PCs (cheeky bit of lunchtime mapping at work anyone?) or on different editors, or after upgrading editors. If as many settings as possible are properties of the map file, then it should reduce the time it takes you to sync up your settings across different environments. That would be ideal anyway. It seems the only ones that ARENT worldspawn are things like -extra/-extra4, -lux, -onlyents... things that arent followed by some sort of value.
is it possible to convert these to be usable as worldspawn as well? If the idea is that you find a good value and keep it for that map - no matter what sort of compile you are doing - then it's a property of the map and it should be a worldspawn value (sunlight, dirt blah blah)
If it's a setting that you keep changing to do different types of compiles (e.g. fast / final / onlyents /dirtydebug etc. ), then it's not a property of the map, and thus should remain as a commandline switch Do -extra and -extra4 gamma-correct when downsampling, or is that even relevant with lightmaps? It is something which makes a huge quality difference when generating mipmaps for diffuse textures. See http://filmicgames.com/archives/327 for something of a discussion.
I did countless tests with the new dirt AO system and found I wanted a strong dirt in corners that worked with finer brushwork detail. I also only added dirt to strong light source (excluded from all small/ambient light sources) and excluded it from most func bmodel entities.
I did notice several maps in the ones I've checked out that disable dirt on some bmodels, like func_doors. Why would you do that? Is it just because they move and their lighting changes enough that they look bad? Just edit/update either file with all the extra stuff you want. I know how to edit the FGDs, I just figured there would be a "standard" stock FGD that people use, like how everyone uses Eric's compile tools now. Strong source lights = no dirt Ambient source lights = AO dirt So you sometimes apply different dirt setting per-light? I take it that's usually for indoor areas? Honey uses strong point lights with many low fill (delay5) ambient lights and THTC uses many strong fill (delay5) lights for large windows and subtle fill lights for the rest. Both systems have different advantages and both create a different atmosphere. They are both pre dirt AO options, but they are useful for understanding lighting. I come from Source multiplayer (TF2, CS) where almost all maps take place primarily outdoors, so we don't really use "phantom" fill lights much since the light_environment and indoor sourced lights take care of most of the playspace. Talking of dirt, I've always felt lights should have optional dirt "falloff" controls.
It struck me when playing around, that I'd want a bright light source to not apply dirt within a certain small radius, and then after this radius, ramp up until it's subject to the full dirt settings. Something like (on the light entity): _dirt_off_radius _dirt_on_radius Should be self-explanatory, but if not: From 0 to _dirt_off_radius units, no dirt. From _dirt_off_radius to _dirt_on_radius, the dirt linearly ramps from 0 to full, and after _dirt_on_radius, it's full dirt. What I currently do is use two lights in the same place: a bright light with dirt 1, and then a smaller light with dirt -1 so that it stops the immediate geometry around the light looking unrealistically dirty. The suggestion above means you can do basically the same thing but with just the one light entity. I'm still trying to visualize what the dirt actually looks like on point lights. It sounds like the light actually casts shadow at its outer reaches, but that doesn't make sense. I'm not at my PC or I'd make a little test.
I'm still trying to visualize what the dirt actually looks like on point lights. It sounds like the light actually casts shadow at its outer reaches, but that doesn't make sense. I'm not at my PC or I'd make a little test.
Point lights don't "cast" dirt, so to speak. Imagine lighting a level with no dirt, then dirt is applied afterwards as a second pass. This dirt is applied over the existing light, so those lights are said to have "dirt on them". For lights that have no dirt (dirt -1), I assume those lights are applied after the dirt pass, not before it, so the light can illuminate the dirty creases. Caveat: the above is a guess, only ericw can confirm whether that's actually how it's done, but I'd be surprised if it's not the case. ericw - is my assumption correct re: 3 passes (1: dirty lights, 2: dirt pass, 3: non-dirty lights)?
If so, where does bounce lighting fit into this? I assume bounce must be subject to dirt. Yep, the 3 passes explanation is correct.
It's implemented slightly differently, but the result is the same: each light is rendered, possibly multiplied by the dirtmap (if dirt is enabled on that light), then summed. Also, interesting idea about the dirt falloff. I don't think it'd be difficult to do. I did notice several maps in the ones I've checked out that disable dirt on some bmodels, like func_doors. Why would you do that? I'm guessing it's the same reason shadows look bad on doors; the shadow should be stationary when the door opens, but in Quake the shadow moves with the door texture. I'm guessing it's the same reason shadows look bad on doors; the shadow should be stationary when the door opens, but in Quake the shadow moves with the door texture.
So it's just to lessen the effect? Disable the dirt so the moving shadow is less noticeable? Also, interesting idea about the dirt falloff. I don't think it'd be difficult to do.
For me, that would be really lovely as it would cleanly preserve the 1/x^2 falloff characteristics of my point lights, whilst also giving me precise distance control over when the dirt kicks in, as well as simplifying the whole setup. I feel like the introduction of all these new features etc is being held back a huge amount.
Higher res lightmaps have been talked about and we actually had an implementation at one point. Turns out they're one of those things that it's nice to talk about but when reality hits nobody really seems to want them. See the comment about "lit2" in the opening post of this thread, even.
This is something that came up a lot when I was doing the original BSP2 design. There is a degree of conflict between what people want and what's practical to implement. One of the overriding design goals of BSP2 was that it needed to be something that people would actually use. It needed to be quick and easy to implement and with a high degree of compatibility. That's why it doesn't have all of the additional features that people might wish for. If you ask 10 different people you'll get 10 different answers, and any given 5 of those answers will probably be incompatible with the other 5. So it doesn't have coloured light built-in, it doesn't have 32-bit textures, it doesn't have high-res lightmaps, it doesn't even change the That's why it's been successful where previous "let's design a new map format by committee" attempts have failed. I think that I've a good idea of the kind of map/bsp format that people actually do want however, and I think it looks a little like Q2 BSP but with embedded textures, BSP2 extended limits and a Q3A lightgrid. Yes, what mh said. See here for the start of a discussion on it when it was trialed: http://www.celephais.net/board/view_thread.php?id=60967&start=382
Feedback was rather mixed. I'm in the "meh" camp. It's funny how, once you start to increase the lightmap resolution, how quickly your thoughts seem to shift to "hmm looks a bit too crisp actually, how can I make this softer?" Heh. My experience is that people asking for a feature typically have a very specific problem right now that the feature they're asking for would solve.
For example: "can I have high-res lightmaps?" - meaning: "I'm shining a light through some grating and I'm not seeing the detail I'd like in the shadows". Thing is, they can sometimes get so caught up in the specific problem they wish to solve that they forget about the knock-on effects of the feature they want. So "can I have high-res lightmaps?" turns into "everything looks like crappy hard-edged Doom 3 shadows". Fence textures were another example. I was asked could player movement be clipped by sprites, but it turned out that the problem was that sprites were being used for gratings/etc. Fence textures were an easy addition, everything works the way it should, and the end result is more generally useful. There's more mileage in asking about what you wish to solve than there is in asking about how you wish to solve it. It's interesting reading my post on higher res light maps. I think I would still be interested in 2x detail (4x at a push) but it would have to be surface-dependent (specific areas only). I think when I did those tests I might have just done it on all surfaces (wasnt needed).
When I said surface flags that was certainly one example. Lots of features have been added to the compilers already that cover functions (_phong on groups, this is done by surface flags in Q2, same with alpha textures and scrolling surfaces). Maybe something that will allow terrain in the future and curved surfaces. I dunno, I was just riffing ideas tbh. My next mapping projects will not be grandiose ones like with ad_tfuma so I am not in the market for new toys and gizmos just yet. I don't think it would look good if a 4x surface was beside a 1x surface. Unless you set things up very carefully there would be quite a jarring effect where the surfaces meet.
One thing that I would like to see added is a way to project textures at full resolution. I wanted to do that with my noirjam map to get a smooth, natural transition between grass and dirt but was unable to due to the low resolution lightmaps.
I agree with the issues that high-resolution lightmaps raise, but better texture projection would be a nice feature to have. It would be a niche addition though, and like mh said, design by committee rarely works out... Sorry I can't get my head around why you'd want to fake texture blending via some kind of textured light projection.
Opening up photoshop and making some transition textures would be by far the best option. If there was enough demand for proper texture blending, it would have to be an engine thing, perhaps done in a similar way to how Quake 3 does it. I got _dirt_on_radius / _dirt_off_radius up and running, if you want to check it out here is a snapshot.
For now the feature is only active if you set both keys, and there is no safety check that the _dirt_on_radius is larger than _dirt_off_radius. This does seem like a cool feature.. here is an (ugly) screenshot with: "_dirt_off_radius" "100" "_dirt_on_radius" "500" http://i.imgur.com/zWQAOtS.png The light is in the upper left of the screenshot, and the dirt is only really visible on the back wall to the right Blend it manually! tool screenshot results screenshot
I never knew I turned that into a tool, but a month ago I noticed someone talking about that tool. I guess Spirit saved off a copy. Wow :) Thanks, that was fast! I've had a play with it and it makes a big difference - that will practically cut in half the number of lights I need. It looks great - torches in corners and alcoves now look correct, and the dirt nicely fades in as the light diminishes. A great addition imo :)
I've never had much success with tools designed to blend textures; in general, my experience with working with
Quake Texture Tool is nice, but in my experience it mangles the colours from time to time. I had to get some blended textures for my current map made by hand because everything QTT produced wouldn't match up when put next to either source texture. In any case, projecting/blending textures is a much simpler, less painful experience that can easily be achieved with a map editor and the requisite format support. If it worked like it currently does, all you'd need to know is the names of the texture you want and how to set up a spotlight. No messing around with buggy tools from the 90s/early 2000s and no messing around with things like GIMP or Photoshop. @baker - looks useful!
@pritchard - sorry still not seeing it - leaving aside the issues associated with having an uber-high-res lightmap, you're still just projecting coloured light - it will just glow, like a stained glass window effect surely? Why would it glow? If you're projecting a texture, not a light, you're not projecting coloured light. Perhaps that's how it works now?
To be honest I just miss being able to paint textures in Cube 2. As far as I know that was done through some kind of "map" of the level, but I don't know the specifics of how it worked. But if you're familiar with that, that's the sort of functionality I'd like to have. Probably a pipe dream... In any case, projecting/blending textures is a much simpler, less painful experience that can easily be achieved with a map editor and the requisite format support. If it worked like it currently does, all you'd need to know is the names of the texture you want and how to set up a spotlight. No messing around with buggy tools from the 90s/early 2000s and no messing around with things like GIMP or Photoshop.
What are you smoking? Why would it glow? If you're projecting a texture, not a light, you're not projecting coloured light. Perhaps that's how it works now?
When you project a texture with a spotlight, you are adding positive light to the lightmap. Let's say you project a green grass texture onto some gravel - all that will happen is you are adding some greenish light to the gravel texture - you'll see the gravel texture brightened up a bit and tinted green You can project a texture and set up any blend func you wish. Do it before lighting, do it after lighting, whatever.
Just because it's commonly used for spotlights doesn't mean it can only be used for spotlights. So project a green grass texture onto gravel and set up the blend as GL_ZERO, GL_SRC_COLOR and you get a straightup modulation of grass and gravel. Set it up as GL_ONE, GL_ONE and you add grass to gravel. Set it up as GL_ONE, GL_ONE_MINUS_SRC_ALPHA and set up the alpha channel of the grass texture and you get a masked overlay - kinda like Quake's sky. All my comments are assuming we're just using the existing system but with just a higher-res lightmap.
So it seems obvious to me that the people who work most on the engines should drive any changes they want to see / would see to be beneficial to the community. So Baker / EricW / Spike... What would you want to see in any future map format?
Regarding the screenshots from the upscaled lightmap experiment. The jaggies were gone, which was nice... But the sharp shadow edges were a bit much. It seems that some quantity of blending is nice. Any changes you make to the map format are useless if noone ever uses them
until them we have bspx, to embed optional stuff that noone else even realises is there. So, leading off of my post in the Mark V thread, is there any particular issue with these compiler settings that might cause lit water not to work?
http://i.imgur.com/q1gWtTZ.png Aha, should be "-splitturb" without the "s"..
qbsp should be printing an error about unknown option I think? Really obscure, odd thing that had me stumped for quite a while! Posting in this thread because it seems to be something to do with the compile.
AD mod - create a misc_textbook and just put (for example) "\\bTest Message\\b\\n\\n" in the "message" field, and "\\bTest Message 2\\b" in the "message2" field (without quotes). If you do an -onlyents compile, the \\b gold lettering breaks and you see the backslash character in the text. If you do a normal compile, then the gold lettering appears properly. Does this happen to anyone else or is it just me? This board treats backslashes different when you preview a post versus actually posting.
In my above post, please ignore the double-backslashes. They are supposed to be single-backslashes (so in my example above I am actually typing single-backslash-b etc. in the message field in the quake editor. How confusing is that! Try doing an onlyents light compile (after the qbsp -onlyents); I think that'll fix it.
the \b handling is in done in light.exe for some reason; it probably should be moved to qbsp. http://i.imgur.com/1poBXfp.png Some of my func_detail gets really dark in the middle and has obvious seams with the nearby brushes. Here's how it looks in the editor: http://i.imgur.com/y6JHK4r.png
Any ideas? I can mask the effect by adding another nearby light but the seam is still visible. Changing the geometry works to fix it as well, which is what I've chosen to do. Hmm, it's tough to say. It could be a few things:
- try a light compile with "-phongdebug" and set "r_lightmap 1" in engine. - try adding "-novisapprox" to light. This disables some light culling that can be over-aggressive and can cause artifacts like this, although it shouldn't be messing up in this case. I'd also say your geometry is overly complex on the floor. You're more likely to get lighting errors and such when the detail is so high. I'd also say high detail on the floor is not always desirable because of Quakes quirky physics.
In my experience with the floor so far it's has worked out well, but I could easily change from func_detail to func_illusionary and use flat clip brushes for movement if it becomes a problem.
I'll try your suggestions soon Eric. as you may encounter similar lighting issues etc. Just keep it clean and simple, Quake doesnt need to be super high poly :)
I like me some polygons, dangit! I'm well aware of the func_illusionary lighting problems, but they all have workarounds and should be minimal in the first place considering my minimal amount of brush overlap.
Was fence texture raytracing ever re-added? It'd be nice to have, my current map uses such textures quite a bit.
It's in v0.15.9. It should work automatically (the old version needed a -fence command line flag, which is no longer needed)
Is it supposed to be reported in this line if it is acting?
Embree_TraceInit: 0 skyfaces 40734 solidfaces 0 fencefaces 0 selfshadowfaces 0 skipwindings I'm noticing that there are no "fencefaces" reported, which makes me wonder if it is actually working. Yeah, it should list >0 "fencefaces" there.
Check that "_shadow" "1" is set on the entity (assuming the fence texture is used in a func_?) Now that more people are trying to implement lit liquids, and Darkplaces already supports it, can you turn -splitturb on by default in the BSP compiler?
It has literally zero negative side effects, and the impact on performance caused by the subdivision should be negligible in any engine nowadays. It's nice that the compiler is already capable of compiling lit liquids, but no one is using this option yet. All of those new maps being released in the last months could have looked a lot better with lit liquids. I'd like to see this happen too.
I think there are still a few decisions to be shaken out regarding lit water, but we're not going to get a useful discussion until a sufficient number of people have had a chance to see what it actually does look like, what all the weird corner cases are, and how it interacts with existing content. I'm not sure about enabling -splitturb in these tools by default; I don't want to push it on mappers retroactively, which is what would happen if people upgrade tools and don't test their maps in DarkPlaces. In the longer run I think it'll be a feature like skyboxes (or phong shading, bounce lighting, etc) where mappers might use it if they're going for a modern look, and not use it if they're going for a retro look.
But I agree the community in general needs to see this in action to evaluate it; DarkPlaces isn't that useful for evaluating the look because the water surfaces doesn't do the swirl effect. I have only seen it in DP and it looks OK but tends to make water look a bit like a solid wall.. I think the warping will help counteract this (as well as careful setup of wateralpha / minlight on the water brushes, from the mapper). We need a Fitzquake style engine with it. I meant to make a patch to Quakespasm for it some time, at least for making test builds to post here. Does Darkplaces have a cvar to disable it? If a map doesn't look good with it, the user can disable the effect.
It's about having options. If lit water isn't compiled into the map, the users have no option. DarkPlaces [...] doesn't do the swirl effect. [...] tends to make water look a bit like a solid wall.. I think the warping will help counteract this
Exactly. In Retroquad it looks great because the texture swirls while the lighting doesn't. Yeah, I compiled e1m2 with lit water and noticed the "solid wall" effect too, but this was even with the turbulent effect.
Another thing I noticed is that the lightmapping tends to make translucent water less noticeable; it's actually more difficult to fine-tune a good value of r_wateralpha that works well. The thing about fullbright translucent water surfaces is that they actually blend with the lighting on the solid surfaces below them. This comes back to the statement I made earlier on about translucent surfaces probably not needing to be lit at all, but yeah, it's something that people are only ever going to be able to evaluate once they see it. Having a cvar to enable/disable options is useless IMO if the cvar isn't exposed to the player somehow. Because most players won't even be aware that it exists. That's a total cop-out; people don't read readmes so you need to pick sensible defaults and unfortunately I suspect that while community judgement on lit water is going to be "it looks crap", people are so drunk on the kool-aid that we're going to end up with a set of defaults that in a years time nobody will want. To me the value of lit water is that even if it is a tradeoff of sorts and can have undesirable effects (I still haven't really managed to see it in action aside from screenshots, so I can't say if it makes water look like a solid surface or not), it's still better than having water that glows in the dark.
That's really what it's about for me - letting mappers use water in dark areas without it looking awful and out of place. The way it is right now looks fine in places like this, but not so much in places like this. You can make it more subtle by increasing wateralpha (it's 0.6 in these screenshots), but then you lose some of that murkiness and uncertainty from the water that a mapper might want. And it doesn't solve the problem completely anyway. By the way @ericw, thanks for the hint about the _shadow key, worked a charm. Too bad my fence textures are too finely detailed and barely let any light through :( mh: Having a cvar to enable/disable options is useless IMO if the cvar isn't exposed to the player somehow.
That's why I'm used to implementing menu options for this kind of thing. And such menu options needs cvars. Lots of engines have options to toggle colored lighting, wateralpha and so on. It's really hard to believe you haven't thought of this possibility. Anyway, even if nobody else implements it in their engines, even if nobody else compiles it in their maps, I'll just keep doing my own thing. Even if everybody else thinks it looks bad. I think Retroquad looks great but i also think it should be a criminal offense that I can't play it ;-;
Let's say I have a lot of fiddly little clip brushes used to smooth over some terrain (turning the collision into steps basically, not slopes). Should the clip brushes be made func_detail, like the terrain, or should clip always be world / func_group, regardless of how detailed it is?
I'm pretty sure it's fine to put them in func_detail, they will behave the same as if they are in worldspawn or func_group.
(Clip brushes are only included in hull1/2, and func_detail is specific to hull0, so the features shouldn't have any interaction) 1) If I want to upgrade to the latest tyrutils-ericw (v0.15.9) on Linux 64 bit, can I just download the Linux64.zip archive, extract it and immediately use it? That's what I tried, and qbsp seems to work ok, but light gives me the error message
error while loading shared libraries: libembree.so.2: cannot open shared object file: No such file or directory. There is a file called "libembree.so.2" in "tyrutils-ericw-v0.15.9-Linux/bin/", though, so I'm confused. 2) When using running light, does it matter in which order I type in the command-line options? E.g. is there a difference between light -bounce -extra4 -dirt and light -dirt -bounce -extra4? Are they both correct? Or both wrong? Do I need to give "bounce" a value? (I've tried various variations, but I find it hard to know when/if I'm doing things correctly, as I'm not sure what the in-game results are supposed to be). 3) This is not a huge problem (yet), but one brush face in a map I've been working on suddenly stopped being lit, both when running light normally and with "-dirtdebug" (which should light all faces evenly, right? That's what it's always done before when I used it). Is there a known reason for this kind of thing? Is there anything one can do to avoid it, or is it one of those mysterious things that just sometimes happens? This is using tyrutils-ericw 0.15.8 and an outdated version of TB2 beta (the reason being that when I last tried to upgrade TB2, I seemingly had to first upgrade my then freshly installed OS, or fiddle around with repository settings to get the necessary dependencies updated to the versions required for updating TB2 -- and I didn't have the time or patience to do so. At some point I will update both). I just mention this in case this might be an issue related to the editor rather than the light tool (in which case I'll just have to live with it until I update my OS and editor). Oh, and my engine is QuakeSpasm 0.92.0. 1. Looks like I messed up packaging the linux binary.
If you don't mind running light manually from the terminal, try "cd"-ing into the "bin" directory and run: LD_LIBRARY_PATH=$(pwd) Otherwise, I'll fix it in the next release. 2. Order doesn't matter, except the map has to come last. There is no parameter for -bounce (there are separate flags like -bouncescale X though). Only a few commands take optional parameters (-soft can take a number like "-soft 2"). The tool should be strict if there are mistakes in the command line options, and refuse to run. For now the manual is the best reference: here, or the website front page. 3. It would just be a bug in "light". Things that have caused black faces in the past: - bmodels (func_wall, etc.) that intersect the world - regular world faces with an obstruction near the center of the face, within 1 unit of the surface. I *think* I fixed all of these for the next version, I should put up a beta or release soon. Feel free to send me your map/bsp if you want me to check it out though. 1. I didn't know there was an alternative to running it manually from terminal; that's what I always do. :) Anyway, I tested typing that arcane string of characters and it works, thanks! That'll tide me over till the next release.
2. Order doesn't matter Thanks for clearing that up! :) There is no parameter for -bounce the manual is the best reference I had already read through the manual and the stuff on the front page a few times, but was still a little confused. The example of the front page is -bounce -bouncescale 2 which made me think that it doesn't take any parameters. But the manual made it seem to me as if do need to specify a value ("n"): bounce n Enables 1 bounce, 0=disable even if set in worldspawn. Available as a worldspawn key. I guess I'm misinterpreting something? 3. Thanks for all of this info. The brush with the unlit face is just a regular unobstructed worldbrush, but it's good to know these things for future reference. Thank you very much for offering to look at the map. If the problem persists, I might take you up on the offer, but a lot is bound to change in the map, so the problem might resolve itself in the mean time. Plus, the file is a huge mess of provisional brushwork, newbie mistakes, textures that have not been properly aligned yet, etc., and though I know no-one but me cares, I'm still too embarrassed to share it in its current state. Hi,
I noticed that color lights have different intensity than the neutral ones. https://flic.kr/p/SQKPAU In the picture all the lights have the "light" key of 150, but the attenuation and the intensity is very different. If that's "a feature", what can I do to make them look more uniform? When you change the color, it reduces the intensity of the colors that you don't want. If a white light has RGB color of 1, 1, 1 and you make it pure blue, the color becomes 0, 0, 1.
You could reduce the brightness 1/2 by making the color 0.5, 0.5, 0.5 I don't think the light program compensates for this and maybe it's what you are seeing. That's not the problem at all here. Look at the image - that's an engine thing. The light program just can't blow the lightmap brightness up like that.
Okay, you're probably right. The picture was so dark I couldn't really see anything other than the white and blue blobs, and I was too lazy to turn the gamma up.
White and colored lights shouldn't have vastly different intensity / falloff, and if anything white will be brighter than colored as Rick was saying.. so something is wrong here.
Is the "_color" key set on the white lights (the dim ones on the right)? The engine's brightness/contrast controls are blowing out the colors so it's hard to tell what's going on. Also assuming that is Darkplaces, you can view the lightmap only by entering "gl_lightmaps 1" in the console. It's clearly amplifying the light instead of reducing.
Somehow, it seems to be adding the color to the light instead of multiplying. It's Darkplaces. Only the color lights have "_color" key. I'm at work right now but AFAIR I didn't use any "_deviance".
If anyone wants to check it, I could take more screenshots with higher brightness or should I mess with any other parameters? I'll check the same settings in FitzQuake and will let you know. Use floats, ie values between 0 and 1.
Values greater than 1 will either oversaturate or be divided by 255, depending on implementation (welcome to the wild west). The lighting in that screenshot actually has nothing to do with tyrlight[-ericw], because the engine you're using is basically ignoring its output and making up its own thing based on the map entities. set r_shadow_realtime_world 0 to get it to behave properly. This'll also boost framerates significantly, so a double win... ericw, how about a feature to ignore/strip certain lights so you can more easily set up rtlights without damaging static lights? maybe Loathe as I am to suggest continually adding fudges to support all the different implementations custom engines expect - on the compile side, would it make sense to always normalise 0-255 values into 0-1 values when saved to the bsp?
I've updated my FGD file for version v0.15.9 of Ericw tools so you can now set phong on brush models and projected textures on lights.
https://dl.dropboxusercontent.com/u/33279452/quake4ericwTools.fgd Tested with J.A.C.K steam release Spike, ah, rtlights explains it. Hmm maybe a key to omit an entity from the bsp could be handy, although in this case the mapper could just use colors values in 0-1.
I kind of hate to add hacks like scaling the "_color" values in the bsp to 0-1, although I suppose it improves compatibility with darkplaces "auto-rtlights" and should be pretty safe. Thank you Spike! As soon as I changed the values into floats, the light got rendered nicely.
Also, when I turned off rtworld, as suggested by EricW, the rendering was pretty close to how FitzQuake does it. Although, I do have to admit it, it's a bit bland this way. If anyone wanted to check a poor presentation of the above, go to https://flic.kr/s/aHskVVmHss. Got this error when working on my map, after I made a brush that was way too finely curved for its own good. Is there any solution other than just having rough edges? :(
More than 64 verts will crash most Quake engines, since engines also contain code that assumes that the max verts in a face is 64. Example: https://github.com/id-Software/Quake/blob/master/WinQuake/gl_warp.c#L148
So you definitely want to keep the tools error and correct your brush instead. New beta:
https://github.com/ericwa/tyrutils-ericw/releases/tag/ericw-v0.15.10-beta1 Has the qbsp.exe -convert valve mymap.map and it will write out a copy of the map in Valve 220 format to mymap-valve.map. It can also convert to "quake", "quake2", "bp" (quake 3 brush primitives). I labelled it "beta" because it's not tested enough, light has a large change to how sample points are positioned. (so unexpected black faces should never happen any more, e.g. this) So it's the black artifacts around the floor tiles? Was that shot with -extra4? I should be able to reproduce it.
re: bounce, good point, it should be opt-in, I guess. "_bounce_styled" "1" worldspawn key? Thanks for testing and glad the No, no -extra4 or soft. I haven't been using those parameters as I test the map. If you like I can create a github issue with the
Also, interesting tidbit but nothing of any real issue: Converting the map to valve format through your tools seems to have reversed the order keys are listed in for TB2. Classnames are now at the bottom rather than the top. Not the case for newly created entities of course.
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) 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. 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. 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? 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. Idea:
When a map is recompiled, compare its entities with the entities in its previously compiled BSP file, and use the radius of each light to determine which surfaces had their lighting changed. This way, when recompiling lights, the light tool can simply copy all unchanged lightmaps from the BSP file, and compile only the modified lightmaps rather than recompiling all lightmaps. Bounce lighting can make this complicated, so I'm not sure if it would be possible. I feel like if you're testing within each light's radius to see what brushes have changed, you're already doing a lot of the grunt work for compiling a new lightmap...
It could work for a rough and messy sketch if you were willing to let a lot of edge cases slip through and accept the odd corrupted face or two, but then you invite the possibility of someone releasing a map compiled with that option turned on... testing within each light's radius
Only for the light entities that changed. Quite often, it will be only 1 light. What I've been thinking of, that's sort of related to that, is making a light preview tool; it would be a small GUI application with a 3d view with WASD+mouselook. You would open a map file and the tool does qbsp and light and displays the result, except the light baking is done on faces near the camera first, and the 3d view updates as each face finishes baking. Then it would refresh whenever the
yeah, what I have always wanted is a tool that lets me edit the lighting in realtime. I think that a diff-based approach to recalculating lightmaps would be fast enough to make this possible. Most edits would only affect one light, which has only local effects. Of course editing the sun values would not be as easily optimized.
I'm not really sure what happens if you use old light data on a new BSP, but wouldn't it be pretty broken if you edited the brushwork around a light that hadn't changed. Say you made a ceiling, put a light on it, ran qbsp/light, then built the rest of the room and tried to patch.
I don't know what that would look like but I imagine it'd be quite bad... Yeah, that would be quite broken.
There are also complexities around light styles, combining lights with the same style, and packing in new lightdata/updating light offsets, which may in theory require to recalc for the entire BSP. Question: Does
Right now I'm on mobile and can't test it. Iirc, separate func_detail / group will be blended if the _phong settings allow it. But other bmodels never blend with each other or world.
Having a real time lighting renderer like ericw would be really neat. If you were able to cull light calculations to the player's view (You'd have to be very generous - bouncing their view around corners to find lights that should cast but would otherwise be missed), you could potentially have an engine that displayed in the traditional quake style, while keeping the main benefits of lighting in real time like moving lights.
I can already imagine a whole set of horrendous edge cases arising from this sort of thing, but it'd be a pretty neat thing to see and something that I'd hope modern computers would have the power to pull off... Yeah, I've just tested, and it doesn't work:
screenshot The back of the column is a func_detail with _phong 1. The front of the column is a func_wall with _phong 1 and _world 1. If _phong 1 worked on mixed entity types with _world 1, we could work around some of the BSP's planar/vertex accuracy limitations by alternating between func_detail and func_wall brushes. This would make the engine clip their planes at the rendering level, which is completely accurate and doesn't produce distortions. quake's lighting logic has some bias on its dotproducts that increses the amount of light on surfaces that are nearly perpendicular to lights (which is important for lights placed near said surface).
You can disable the effect with _anglescale 1 (I think it is now - vanilla hardcoded it to 0.5) the '_phong' key simply calculates surface normals on a per-sample basis instead of per-surface (thus meaning its misnamed as it doesn't change the lighting formula). It affects the lighting, but not the shadows. While it would be possible to push the sample worldspace positions according to the same calculated normals, and determining shadows based upon those, such things would be quite unreliable in practice - for instance, a concave surface curve would logically push those sample positions inside the surface, which would result in all traces being obscured with the surface shadowing itself. so yeah, that's why you get sudden lighting changes on the edge of pillars - because -anglescale is biasing the light on one side while the other side is in pure shadow. if you want to try it anyway, this is the maths I use in FTE for tessellation: vec3 w = p0*bary[0]+p1*bary[1]+p2*bary[2]; vec3 t0 = w - dot(w-p0,n0)*n0; vec3 t1 = w - dot(w-p1,n1)*n1; vec3 t2 = w - dot(w-p2,n2)*n2; w = w*(1.0-factor) + factor*(bary[0]*t0+bary[1]*t1+bary[2]*t2); you should be able to shove something like that into GLM_InterpolateNormal (and convert from glsl to cpp - I already renamed stuff from glsl). You'll then need to return the smoothed position back through multiple callers to the point where its copied into the lightmap samples array. Bonus points if you can calculate the barycentric coords (read: interpolation weights) for general polygons instead of just triangles. like I say, you'll need to clamp the shadow-point to never be behind the surface to avoid the more obvious glitches. once implemented properly you'll get smoother lighting around corners (although due to the nature of traceline shadows, it'll probably still be somewhat sudden without anglescale 1). @mankrip, smoothing between separate models is too difficult to attempt, imho, because smoothing relies on the model having been processed by QBSP. i.e. it involves walking around the mesh (exploring neighbouring faces to a vertex, and neighbouring faces to a face, etc.). If the models weren't clipped against each other, the smoothing wouldn't work.
@spike in current git, I wiped out the "traceline to position sample points" thing. Instead I'm trying to use the same code as phong shading, so exploring the mesh by following connections between faces. So in a concave surface, it should work properly and give world space positions that are consistent with the interpolated normals. Only problem is, it needs some more work.. Pritchard's case in #773 was failing because of t-junctions in the bsp. I want light to work properly if qbsp didn't add t-junc vertices, so I'm making light do it (in memory only). re: GLM_InterpolateNormal, apologies for the current mess I made in the code and weird names.. I tried using the glm library a bit, then decided I didn't like it. (100 layers of indirection/ abstraction for basic vector operations, slow as hell debug builds,..) On the plus side the test suite is growing slowly. Is there an automated way to import the configuration from the non-Steam version?
I've just bought JACK on Steam, and upon launch it didn't detect that the non-Steam version was already installed. Wrong thread. Wrong tab.
Anyway, thanks for the explanations, ericw and Spike. I'm already going to implement something which should serve as a partial workaround, but I'll keep this info in mind for future research. Quake's dotproduct is a simple dot(L,N) * 0.5 + 0.5; i.e a rescaling from -1..1 to 0..1 (excluding the spotlight cutoff for simplicity):
angle = DotProduct (incoming, l->facenormal); angle = (1.0-scalecos) + scalecos*angle; But scalecos is 0.5 (https://github.com/id-Software/Quake-Tools/blob/c0d1b91c74eb654365ac7755bc837e497caaca73/qutils/LIGHT/LIGHT.C#L13), so substituting: angle = (1.0-0.5) + 0.5*angle; And evaluate (1.0-0.5): angle = 0.5 + 0.5*angle; https://github.com/id-Software/Quake-Tools/blob/master/qutils/LIGHT/LTFACE.C#L403 Is it possible to make brushes with fence textures be compiled in a similar way to brushes with liquid textures?
By that, I mean making them become properly see-through. Currently, any brush with fence textures will clip any polygons from other brushes that touches them, which results in open holes where the other brushes should be visible. The only difference to liquid textures is that the pointcontents of fence brushes would have to be set either to solid or to empty. I guess the first case would give problems to the renderer, and the second case would give problems to the physics, but from the top of my head I'm not sure. I'm not sure how much interest there would be in changing how fence textures are compiled as it's already quite easy to resolve the "clipping" by making brushes using fence textures be a func_ brush such as illusionary or wall.
Pic. What's going on there? Any way to get rid of this without anglesensing the shadows from the spikes away?
Apparently it's related to the increased texture scale (2.5-3x). Jury-rebbed BJP light doesn't seem to have a problem with it (but it lacks several feature I require).
Make sure to use v0.15.9, the
If that's not the problem, I'm not sure from the screenshot, could I have a look at the There's a specific problem I'm having with it, when BSP entities partially inside of walls gets darker edges because part of their surfaces is in pure darkness.
If such entities were part of the world, their surfaces would be clipped by the compiler and there wouldn't be any parts of them in pure darkness. But to be part of the world, they would have to be compiled similarly to liquid volumes, without clipping other brushes. Currently I can work around this by making the other brushes that touches them into func_wall entities too, but IMO this isn't the most efficient approach. the renderer doesn't care if something's solid or not, just that its a leaf or node.
same with physics, really. just make sure those fence-solid leafs don't get merged in to leaf 0 like all other solids, and that vis considers them transparent despite solid (can't say I've really looked into the vis tool itself, maybe it already goes by leaf 0 instead). Thanks for the explanation. The BSP tree architecture is something I've not started studying deeply yet.
I also came across an issue with detail brushes. Not sure if it's a bug or simply a technical restriction and downside of the way detail brushes are done in Quake, and also not sure if it's a general thing or only applies to certain special cases.
I had a compact bit of architecure flush to the wall of a building and turned it into func_detail in order to use phong shading on it. The building's wall behind it remained solid world geometry. As it turns out, having the detail brush touch the wall like it did caused the compiler to disregard visblocking for the wall which resulted a situation where a large part of the interior was being rendered despite being completely out of view, causing wpoly to increase by 1500. Making the func_detail 'flatter' by including only the front part of the detail architecture didn't change anything; it seemed to be entirely related to the touching of detail and world brushes on that particular part of the wall. Now, this might be an edge case caused or faciliated by the shape and construction of that particular area (sloped brushes, same brushes for inside/outside etc), but still a potential risk to keep in mind, especially if remaining unnoticed until the final release of a map. If anything, this is meant to raise awareness that excessive func_detailing can be detrimental, too. Perhaps the code can be tweaked to make sure this can't happen, or maybe it something to live with due to the hacky nature of it. Some screenshots to clarify.
The face is the func_detail in question. The wall below is a door, but instead of only rendering the corridor behind it (hell knight), it even draws the atrium way out sight, much of its upper and lower parts. isn't a catch-all.
I have found in a number of my maps that I get a speed gain in compile times but not always ideal results in culling in the game. Good lighting and faster vis time and same, worse PVS splitting.
Source engine func_detail: Good lighting, faster vis time, and clean PVS since it treats them as func_walls. Thing is, I don't know how you would gain the benefits of true func_details (the Source way, the right way) unless the compiler turned them into info_notnulls or func_walls. Otherwise, the mod would need to support func_detail entity in its progs.dat Unless engine support for func_details was added. Currently the compiler de-entity-ifies them into normal brushes. But if they were kept... What you describe about detail brushes in the Source engine sounds close to my suggestion about see-through solid volumes.
Isn't all VIS/PVS data precompiled in quake? Why do we need to turn brushes into a specific kind of entity in order to get a desired effect?
Would it not be possible for VIS to just look at a func_detail, say "I'm going to treat this as if it were a func_wall" and be done with it? How does it work currently? Yeah, I'm going to take another stab at fixing func_detail's PVS issues. mankrip your suggestion sounds good to me, and it sounds like it'll share the same implementation.
How about (assuming I can get these to work :-) - func_detail_fence - same as "func_detail" but doesn't clip away world faces, so it's usable for fence textures. Like func_wall, but doesn't use up an entity. - func_detail_illusionary - same as func_detail_fence but no collision hulls. Like func_illusionary, but doesn't use up an entity, and as a downside it would block gunfire. Not sure if this would be useful? That's good.
func_detail_illusionary would actually be really useful to simulate crouching. The real ground would be lower, with a func_detail_illusionary ground a little above. Of course, this would affect monsters too, so its usage may be limited to small areas. I don't care much about quicker VIS times; all I want to achieve is phong shading and occasinally minlighting on brushes without taking up additional entity/model slots. Although marksurfaces eventually forced me to turn many of them into func_wall after all.
As for the issue I mentioned above, there's a workaround. As it turns out, phong and minlight also work on func_group, so making the big face a group instead of detail gets all the effects without the PVS problems. Good to know, albeit even more hax... LIT2 (see the opening post) supports increased lightmap resolution and we all went round the block with it a few years ago. No clear community consensus formed.
My own opinion is that it's a poor trade off for hugely increased file sizes, and it doesn't even look as good as you'd think owing to losing the soft edges on shadows. It could be useful to add a compiler/worldspawn option to set portal brush contents to CONTENTS_EMPTY, because as it is, using CONTENTS_WATER, portals can't be (partially) placed inside of slime and lava.
By the way, Quake's episode 4 already has maps with underwater portals. So, allowing portals under slime and lava would bring more feature consistency to mappers.
Used black for its teleport texture.
I think you mean teleport. Portal is something created by vis. That's not a terrible idea but I think it would serve better as an entity field: _overridecontents 1 or something to that effect. Just copy the teleport texture and call one copy *lavateleport and the other one *slimeteleport in your wad file.
|
.){kind=link}
|
|
Post A Reply: |
|
| Website copyright © 2002-2017 John Fitzgibbons. All posts are copyright their respective authors. |