 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
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.
v0.15.10-beta2
I've been working on qbsp, and did a rewrite of func_detail to fix the vis problem. The big change is, func_detail no longer seals the map (which makes more sense anyway IMHO). No more of this! (baker's shot of a way-too-big-PVS from some spot in ad_mountain). Also, I added a bunch of func_detail variants (illusionary, wall, fence) described in more detail on the release page. Thanks for the suggestions, mankrip, and Spike a while ago. This is still bleeding edge so it's marked as a beta, and I still haven't fixed the light issue you reported Pritchard. I didn't think that had ever cut vis. I know it doesn't in GoldSrc/Source. Was func_detail something third-party FGDs added to Quake?
Yeah it was something added later to the Quake tools - afaik originating in Quest.
It's not that func_detail blocked vis, but certain setups would cause bogus portals (what negke is reporting in #835) resulting in bogus vis results. light: styled lights no longer bounce by default, set "_bouncestyled" "1" to enable.
Just want to confirm this means bounce is disabled on id's lightstyles "flicker, pulse" etc.? Is that set in worldspawn or on the light entity or both? Yep, it's for flicker/pulse and also lights that start off and are switched on. The "_bouncestyled" key is on worldspawn and affects all the flickering / switchable lights in the map.
(The first release I did with bounce lighting didn't support having those lights bounce; now they can, but it's opt-in.) I'm still running a 32-bit system, I didn't realize that doubling the bits would also double file sizes. Makes sense.
would it increase compiling time if i added "_phong_ to my "func_detail" entry in FGD and thereby all my func_detail?
would it increase compiling time if i added "_phong_ to my "func_detail" entry in FGD and thereby all my func_detail?
If "_phong" "1" is set on every func_detail there will be a little overhead, maybe 10% slower, but nothing major.
The main thing I would watch for is unwanted smoothing. The default _phong_angle is 89 which might be a bit high (face normals up to 89 degrees apart will get smoothed together). Check with a "-phongdebug" compile and set r_lightmaps 1 in the engine to see what is getting smoothed. downloads:
https://github.com/ericwa/tyrutils-ericw/releases/tag/ericw-v0.15.10 - light: add "_shadowworldonly" bmodel key - only cast shadows on world, not other bmodels. - light: switchable bmodel shadows (requires QuakeC support, see light manual). - light: accept "_minlight" in worldspawn as an alias for "light" - light: handle degenerate faces, print out the vertex coordinates - qbsp: misc_external_map prefab system (see qbsp manual) - qbsp: don't write unused texinfo - qbsp: rewrite outside filling similar to q3map - qbsp: revert change to SubdivideFace which was increasing faces a bit (see 53743dd) - qbsp: add -expand option to dump the hull expansion to a "expanded.map", from q3map - qbsp: add -leaktest option to abort compilation when a leak is found, from qbsp3 - qbsp: fix handling of duplicate planes, which was causing id1 maps to leak - qbsp: try to get more reliable leaf content assignment (see a910dd8) - bsputil: --check: print BSP tree heights at the first few levels of the tree - bsputil: --check: check for unreferenced texinfo, vertices, planes - bsputil: --check: print number of used lightstyles - misc: travis-ci now runs qbsp on all id1 maps, the build fails if any maps leak Weren't there changes to how func_detail brushes are handled? My map's more like a sieve now...
In other news, the removal of the Reload pointfile button from TB was a crime. A CRIME! There is far too much clicking involved now. Do you know if that lighting bug I reported when the beta first came out was ever fixed? It's still an open issue on Github, but flying around my map I haven't spotted anything particularly nasty (by quake lighting standards) It was never my intention to use func_detail to seal my map. Think of it more along the lines of func_detail sealed my map, so when I ran QBSP it didn't catch the leaks and instead allowed the map to be VISed etc.
Most of the map is actually func_detail. And most of it is capped off with far simpler world brushes to seal it. But I missed a good two dozen tiny corners and gaps it seems, and that wasn't revealed until now. Anyway I'm sure that's the least of my bad practices when it comes to VIS. Half of the map is in a giant box right now... I know it's a disruptive change, and makes a lot of existing maps leak, but it was necessary to fix the longstanding bug with vis seeing through walls when func_detail is used.
qbsp has an -omitdetail flag now which should make it easier to see the worldspawn leaks in-engine, or hide all func_detail in trenchbroom; hopefully it's not too bad to seal up the leaks. Do you know if that lighting bug I reported when the beta first came out was ever fixed? It's still an open issue on Github I think I still need to do some work on that. However, there are 2 things that will help for now: - enable phong shading on the ground - seal the map (the way I have light set up currently, it needs t-junctions in order to find neighbouring faces.) A func_ that actually behaves as a func_ now!
Pritchard: ah the box trick. I used that for a section of a map once with a lot of angled brushes. Tsk tsk, pure mapping laziness. ;)
|
|
| You must be logged in to post in this thread. |
|
| Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors. |