 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
There can be a lot of reasons why a sealed map suddenly starts leaking on places that make no sense. Almost every time a leak traces to a light or entity it gets really hard to find the abused polygon.
One thing I am surprised about is.., that tricky outcome with different compilers. I mostly use Ericw tools, but not long ago I had the same embarrassment with an old large map that suddenly started leaking. It fainted on me and it really did hurt. So I left it behind. Then, some months later, I compiled it again and I used another compiler version, and to my surprise it compiled fine. It isn't always the construction of your map, sometimes the compiler version gets screwed. Thank you! I was starting to have my suspicions about the compiler being at fault (ericw tools 0.18.1). I am, however, very grateful for the hard work put into his compiler.
Then I discovered that some of my brushwork was on an 0.5 x 0.5 grid, instead of a 1x1 grid. I changed that brushwork to go on a 1x1 grid, and the map stopped leaking.
Although it doesn't help you fix this, I can at least provide a bit of insight to why it can happen. The first thing is to realise that faces in your map get stored as floating point values in the BSP. Floating point format is subject to rounding errors when the face is angled, and that could produce a leak.
The other important point to realise is that your entire map is an interconnected structure. Decisions made in one half of the map can cause splits to be built in a different way elsewhere. The exact way the splits are built could cause one calculation to round a float differently compared to the previous compilation. This explains why: - a leak appears even though you didn't change the brushes in the area (the other areas in the map had a cascading effect that changes how the compiler handles the earlier sections) - the leak doesn't appear when you compile this bit in isolation (that eliminates the cascading effect) - changing to a different compiler can make the leak vanish (the chain of cascading calculations could be different in each case) I think that local mitigation is probably a sensible move, rather than bad practice. Boxing your entire map is obviously no better than leaving the leak unfixed. Having simple cuboid brushes sealing things up behind complex brushwork is more pragmatic. It might even help the compiler make better choices about how to do the calculations, as if they insulate this area of the map from changes cascading in from elsewhere. The backup brushes get culled as if they weren't there, but that doesn't mean they were redundant. Excellent explanation, Preach. Thanks!
I'm not the person who asked the question in #20892, but this is really valuable knowledge. Can you use an engine to edit create
I know you can make rt lights in DP but I am looking for a way to make a There was a tool made by MH which would automatically generate colored lighting on existing BSPs from the greyscale lightmaps, by using nearby textures for color hints. It does not allow tweaking or editing AFAIK.
Called "MHColour", it's not easy to find. These seem like it: https://www.quaddicted.com/files/tools/WinMHColour2010.zip https://github.com/dsvensson/mhlight If the light entities are still in the map, could you:
1) extract the entities as plain text into a 2) add color keys to selected light entities 3) merge the 4) run the BSP through a coloured-light aware light.exe tool to generate the I know there are tools out there that can do steps 1) and 3), but will have to let someone else remember exactly what and where they are. Also worth considering that without knowing the exact light.exe tool and settings used on the original compilation, you may not get exact fidelity when re-lighting the map. Probably can get close with some trial and error I imagine, and in some sense changing the lighting is the objective... One last worry is that the Good info. Yeah there are quite a few options to extract and "inject"
Over on Discord Woods made me aware of a commandline option in ericw's tools to extract All of this might make it into a video as well. Hello! I was wondering if someone could take a look at my map to figure out why it's leaking. I've read through the Quake 1 Tool Tips and have tried replacing the broken brush, but it still leaks at the exact same spot, no matter how I change the brush.
The QRK for the map and QuArK's output files (.map, Sometimes it's not the leaky brush itself that's the problem, but the brushes surrounding it.
In this case, the brush that the pointfile travels through (the north wall in the nailgun room) looks fine. But there are a few brushes nearby that don't seem to be on-grid, notably the little octagonal recess housing the flame, as well as the cylinders in each corner. If you set your map grid to the lowest setting and zoom in on the vertices, or the points where the cylinders intersect the wall, they don't always line up: https://ibb.co/7kFb5RM https://ibb.co/jzwJ1Vf This doesn't always break things on compile, but it can do. Assuming QuArk has some kind of vertex tool it might be worth tweaking them. Moving each cylinder so the center of the brush lines up with the corner of the room might help, too. As the title says, thank you for your response! Once I finish my homework, I will do the changes that you have suggested. One question that I thought of when I read your reply was that QuArK's grid can go below what I assume is 1 map unit, all the way down to
Apologies, I did not know QuArk's grid went down to
Actually I'll expand on that. Where possible, I personally would not go lower than 1 unit for anything structural (or even 2 units, since I spent many years in WC1.6a with that as the minimum grid). That's not to say you can't of course, but it can lead to various issues
I'm sure it would be fine going lower/off grid for detail brushes Thankk you! Using what you have said I will try to fix the leak! Once I finish my assignments it's off to the map!
does anyone know if https://github.com/ericwa/ericw-tools is able to export a GLTF or FBX model, with the level textures and lightmap?
|
|
|
|
|
|
| You must be logged in to post in this thread. |
|
| Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors. |