 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
I apologize for the inappropriate language in a prior post under my account name. I was in the middle of a lenghty question when I was pulled away from the computer I was using. During my absence, a coworker of mine thought it would be amusing to put a childish remark. Again, you all have my deepest apology.
OK let's try this again... ALthough I'm new to mapping for Quake, I have been using worldcraft/hammer/J.A.C.K. for over twenty years. I've come accross pretty much every compiiling error that you could possibly think of. I'm very aware of the main culprits when it comes to leaks (entities in the void, func_detail/func_wall not sealing the map, actual holes etc...) The problem I'm having seems to defy all logic. I'm getting leaks in areas of the map that I have essentially completed and have done exactly zero modifications to in weeks. I can compile that map and everything goes according to plan, then I will open up a new room or pathway, I'll do some work in that new area and then BOOM, a leak in some random obscure area that I haven't touched in ages. If I copy and paste the isolated problem area to a new file and compile it works just fine. I can replace a brush that the pointfile indicates, I can shuffle brushes around, I can completely rebuild the area in the exact same way or in variations that seal the map, nothing seems to work. I've had to resort to putting brushes behind seams in order to fix some of my problems, which after decades of experience I know it is a really bad fix. I feel like my map is quite literally a sinking ship. Efforts to solve these issues are really slowing down production. Any help would be greatly appriciated
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. |