Sky brushes should not have outside faces
Closed this issue · 7 comments
Currently the tools will create all faces for a sky brush, even if that face is only exposed to the void. This means with some engines, when noclipped outside the level, I can't see into the level because the outside sky brush face blocks the view.
Sky brushes are just solids, so it shouldn't create outside faces. I haven't seen this in the dev builds, at least.
Sky is a separate content type in Q1, it's similar to solid though (seals map, etc.)
This is working correctly at least for a minimal box map. (It's sealed, I just hid one side of the box for screenshot:)
We have a unit test simple_worldspawn_sky that checks that the bsp->dfaces array only contains 1 sky face.
@hemebond any ideas how to repro the issue?
@ericwa It actually looks like perhaps this engine (FTEQW) is rendering the back-face of the sky faces, so I've gone back to the devs to check.
I'm still working on trying to replicate the issue with a test map.
The closest so far is the usual issue of not being able to see out of sky brushes when inside it. This suggests either the internal faces are being generated, or the engine is rendering both sides intentionally. This happens in DarkPlaces too, but not QuakeSpasm. So I'm wondering if it's something those two engines are doing.
Is it intentional for faces that touch sky brushes to not be culled by the compiler? I often add "skip" to any surface touching sky brushes to prevent this.
Okay, it looks like this might just be caused by the poor geometry of the level I'm still rebuilding. Many of the structural walls are pyramids, a result of convert a .obj to a .map. This appears to be causing faces to not be culled and even VIS portals to include "outside" areas.
This can also affect the collision as it's also possible to fire rockets through some of these thin walls (usually those on an angle).
I'm currently trying to compile using the brushbsp branch of the tools and it's even less forgiving of those thin brushes so I have a lot of leaks to fix.
As far as engine differences, I just did a quick test with a 2 brush map:
When noclipping into the sky:
- Quakespasm: can't see any sky faces
- tyrquake: can't see any sky faces (screen gets an underwater tint + water warp effect though)
- fte mar 1 2022: can't see any sky faces (screen gets a water warp effect though)
- darkplaces 2014 stable build: here, whenever the sky brush is on screen, the entire background (which is the gl_clear solid gray in other engines) is rendered as sky. Still, if I noclip inside where the sky brush is, I can still see the floor.
So, none of the engines I tested appear to be rendering the sky faces as 2-sided.
I'm still not sure if there is a tools bug that only manifests in more complex maps.
Is it intentional for faces that touch sky brushes to not be culled by the compiler? I often add "skip" to any surface touching sky brushes to prevent this.
This is unintentional - the expected behaviour is that they're culled.
I just fixed a face merging bug in fa89045 which will hopefully help (the reported bug which prompted that fix was the opposite - a face which was partially covered by sky, and partially in the playable area of the map, was getting wrongly deleted. I think that commit will also fix cases where visible faces partially covered by sky were having the sky-covered part wrongly staying in the final .bsp.)
I'm currently trying to compile using the brushbsp branch of the tools and it's even less forgiving of those thin brushes so I have a lot of leaks to fix.
Ok - brushbsp is now the main branch. If you get cases that look like false identifications of leaks feel free to report :)
Latest brushbsp looks good, properly building the sky test map:
I also recompiled another map with it and it fixed the sky issue there (testing with FTEQW main branch build).
Before:
After:
