#170 posted by metlslime on 2015/10/23 02:11:15
i believe that was true in quake 2 light compilers, but not quake 1. (unless somebody added the feature to quake 1 light compilers)
#171 posted by ericw on 2015/10/23 07:28:07
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.
#172 posted by Lunaran on 2015/10/23 07:42:04
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?
Yeah
#173 posted by ericw on 2015/10/23 08:00:30
That's implemented, the -gate option. I think "-gate 1" means to cut off lights when the brightness would be 1/255.
#174 posted by JneeraZ on 2015/10/23 08:11:17
I think enabling the multithreading a few years back was the most significant speed boost to light.
#175 posted by ericw on 2015/10/23 09:48:08
Warren, yeah, for sure, the threading is amazing.
Lunaran: lol, you prompted me to take a closer look at the "-gate" switch, and seems it was broken in�tyrutils (was calculating a bounding sphere that was too large). I was wondering why using like "-gate 25" wasn't speeding up maps with lots of delay 2 lights. I think I fixed it..
Right, So There's No Gain From Running Vis Before Light Really
#176 posted by czg on 2015/10/23 11:39:51
#177 posted by - on 2015/10/23 17:45:11
I've been using -gate 10 forever... are you saying it's done nothing forever!? :(
#178 posted by Rick on 2015/10/23 18:10:55
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.
Scampie, Me Too!
#179 posted by mfx on 2015/10/23 18:29:52
Gate -10 seems to light faster than gate -1.
A tiny bit.
Correction
#180 posted by mfx on 2015/10/23 18:57:42
-gate 10 versus -gate 1.
Scamp/mfx
#181 posted by ericw on 2015/10/23 19:29:26
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
#182 posted by - on 2015/10/23 20:18:25
Wow, yeah, map I'm working on went from 18secs to light to 8 seconds (only option was -gate 10) nice!
#183 posted by - on 2015/10/23 20:21:37
...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!
Yes
#184 posted by mfx on 2015/10/23 20:24:24
2 times faster now with -gate 10.
#185 posted by Lunaran on 2015/10/23 21:23:30
so, what does the number after gate actually mean then?
#186 posted by ericw on 2015/10/23 21:49:39
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.
#187 posted by ericw on 2015/10/23 21:53:10
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.
#188 posted by - on 2015/10/23 22:26:23
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.
#189 posted by PuLSaR on 2015/10/23 22:35:39
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?
#190 posted by Lunaran on 2015/10/24 05:22:34
127 is full brightness, 255 is 2x overbright.
That's what I was wondering, thanks.
PuLSaR
#191 posted by ericw on 2015/10/26 05:55:56
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.
New Release V0.15.3
#192 posted by ericw on 2015/10/26 21:51:57
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.
I've Just Tried It
#193 posted by PuLSaR on 2015/10/26 22:29:05
and -gate really speeds up the light process
_surface_spotlight Sounds Neat
#194 posted by mankrip on 2015/10/27 02:45:36
Also, a question: Does surface lights follows the shape of the fullbright texels, or maybe the luminance of each texel?
|