 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
do work if they include at least one brush (face?) with a visible texture. i made such a door by accident in sm108.
yes, but even then, there's an engine bug where the physics bounding box of the door will only include the visible brushes. So to make it work reliably, you can't have any clip brushes sticking out past the bounding box of the combined visible brushes.
So I was mapping away and hit ctrl+s to save my map. However, instead of hitting it once, I hit it twice by accident and WC crashed (presumably whilst saving the map). I was a bit worried, but the map seemed to have saved fine and loaded up ok. The filesize wasn't weird either, so I assumed all was ok.
I continue mapping... I did notice later whilst mapping that some unimportant brushes had vanished from my map when I reloaded it. Presumably, one of these brushes was half saved or something. Perhaps it's just a dodgy brush I managed to create with the clipper - but this normally crashes qbsp, so perhaps not. Anyway, the question: How the fuck do I find and eliminate this brush? I could copy all the changes from the new version of my map into an older version, which would probably eliminate the warning, but it seems like lots of hassle for nothing. I won't convert to Can I find the coordinates of this brush with qbsp at all? The only info I got was that it was a brush with no faces and that it was using the texture hstn0. There are a lot of other brushes using that texture, and I can't find it using a text editor because I don't know exactly what I'm looking for and the Currently it is not a major problem (I hope), but if you, the A-team, or anyone else can help me, please reply. Holy crap, 8000 brushes in 1 Q1 map file? Haven't you run into map size/face/etc limits by now? How long does the beast take to fullvis? Also, screenshots plz.
I pwn! Of course, I should probably have tried harder to fix it before posting the above message.
For other people having problems with Rogue brushes, esp. those using Worldcraft, here are some tips: 1. Check to see if there is a brush with centre on the origin - in Worldcraft there should be a cross handle if there is. This could be the culprit. 2. In WC it is entirely possible to create invalid brushes if you don't know what you are doing, and often when you do. The worst kind are thin slivers created by cutting along a plane of a brush using the clipper. Try to be careful not to do this, because the slivers will crash bsp and can be hard to track down. 3. If you can't find a problem then try exporting only visible stuff to a map file and compiling. At first hide large chunks of the level. Once the problem dissapears, you know roughly which area the problem is in. Gradually export less and less visible brushes until you get something manageable containing the error - maybe a few hundred brushes at the most. This is easy to look through in the editor, and can also be checked with notepad without problems. Tyrann has more in his map :)
I will probably be adding another 3000-4000 brushes. Hopefully it won't fuck up. The only thing I have to watch out for is the lightmap size and model precache problems. I want this to run on fitzquake, so don't want to exceed any limits like that. The level isn't THAT big. It isn't small by any means, and packs a lot of gameplay into it, but it's no Marcher Fortress. It's not in a large style either, so no massive areas filled with 3478327 monsters and a quad - I wanted to make something a little simpler and small scale. I'm kind of regretting it now, but I think that I can still make it fun without changing what I have much. If I can be bothered to make the planned follow up maps, then they will be on a larger scale (as with most current big maps). It takes about 15-20 minutes to fully compile (light extra, not extra 4) I think. I have a pentium-m 2ghz 512mb system. When it is finally released, you will see that it isn't particularly spectacular scale wise, and that is probably why it doesn't take a long time to compile. That and perhaps my brushwork is decent. I dunno. There are some old shots on my website http://than.leveldesign.org/ Maybe you can see from the screens that it has a fairly detailed look? There are lots of areas, and the detail level is fairly consistent. r_speeds don't really top 1000, but they are probably higher than usual. I've been using this for a while to remove faces in my current map, and up until now I hadn't had any problems with it. However, recently I have started seeing blotchy, horrible lighting on a couple of walls in my map. Here is a shot of what I am talking about: http://than.leveldesign.org/files/blotchyblotchy.jpg
I am certain skip caused this, because I disabled skip and the error was not present - all the lighting was fine. Does anyone know why this happens and how it can be fixed. I run skip last of all, so perhaps I should try running light afterwards instead. If nothing can fix this, it would be nice if there was a -removesurf <texname> switch in Aquire or Tyrann's versions of light ;) ;) ;) p.s. the dodgy lighting occurs in areas at the boundaries of the level for some reason. Well, Tyrann had said it had some bugs (and that he wasn't using it cause of that?), I never ran into any myself... I guess it probably has higher chances of happening on large levels.
I don't know how skip works, but you could try running vis after skip. If the vis data set is large (>1MB, e.g. when fastvis), skip might have capacity problems.
There are probably numerous references to skip in this very thread, but I'll explain it again, since I'm in a good mood. In fact, since I'm such a nice guy, I've uploaded it to my site here: http://than.leveldesign.org/files/remove_skip.zip (26kb)
The skip removal tool is a small utility made a long time ago by Tyrann. It was never officially released, and I recall him saying he lost the source code to it. As it works fine as it is, I guess he never bothered to write it again and update it. Anyway, the skip tool removes all surfaces from the visible hull of a BSP. The original intention of this was to remove surfaces that could not be seen by the player, such as those in high up places above where the player can reach, on the unseen sides of doors etc. This is probably still the main use. However, this also allows for a few cool tricks (creating invisible doors for one), that you can find out about by reading the previous posts in this thread. I just noticed I made a rather large mistake in my explanation:
Anyway, the skip tool removes all surfaces from the visible hull of a BSP. Should be: Anyway, the skip tool removes all surfaces using a texture named "skip" from the visible hull of a BSP. i have found that at about 10000 brushes, you start to run out of clipnodes, no matter how much you clip brushwork, just because the amount of areas that are present take up so many of the clipnodes.
careful! I had exactly the same type of lighting artifacts in the secret map of Contract, towards the end of its construction:
http://kell.leveldesign.org/screenshots/contract-blotchy.jpg I was using Tyrann's lighting util by then, but to make use of entity compression for the secret map, not skip. I don't think skip was even in the version I was using. Maybe it's just a knave thing o_o I have tons of arches that can be clipped, so if I run out, I will try clipping them. There's also not much rock in the level (there is a bit, but not like something like februus or czg07) so perhaps I'll be ok.
Anyway, as I said, the lighting glitch was fixed by using skip before light. I will try it before vis next time and see what happens. Wtf is entity compression? Wtf is entity compression?
It's not really compression, but it reduces the amount of entity text present in the compiled bsp by removing key/value pairs from the light entities which are not needed after the lighting stage. WC - try the most basic tool included - "check for problems" You�ve probably already done this, but if not; with Q1 it seems to be alot more finnicky and can find illegal entities, though with visgroups yor best bet is removing all before you try deleting a single part of one group - buggy behaviour (WC 1.6a) tends to seemingly randomly hide / delete depending on the order you originally did stuff in . . . 20 versions ago
either way - looking forward to the release I'm sure everyone who knows the answer will tell me this map is basically doomed, but I'm trying to figure out a reason for this weird occurence. DuBSP is reporting that my map has leaks. What's unusual about it is that: 1) it only reports the leak while filling, but not while generating hulls. 2) it refuses to generate a pointfile, even when using -oldleak. I'm in the process of isolating parts of the map and compiling them individually but, maddeningly so, it always seems to be a different entity reached while filling.
For anyone feeling curious/helpful, here's the compiler dump. DUBSP Disunion Level Compiler by Eric 'Riot' Lasota Based on TreeQBSP v1.62 by Greg Lewis. Input file: manatees.map Output file: manatees.bsp ---- LoadMapFile ---- *** WARNING 06: No info_player_deathmatch entities in level 2439 faces 410 brushes 35 entities 50 unique texnames 627 texinfo Processing hull 0... ---- Brush_LoadEntity ---- 383 brushes ---- CSGFaces ---- 2277 brushfaces 3088 csgfaces 1580 mergedfaces ---- SolidBSP ---- 2052 split nodes 832 solid leafs 1221 empty leafs 0 water leafs 3329 leaffaces 3096 nodefaces ---- Portalize ---- 1221 vis leafs 3309 vis portals ---- FillOutside ---- *** WARNING 10: Reached occupant at (-112 352 88), no filling performed. ---- MakeFaceEdges ---- ---- GrowRegions ---- Processing hull 1... Processing hull 2... Processing hull 3... ---- WriteBSPFile ---- 490 planes 9800 3533 vertexes 42396 2130 nodes 51120 627 texinfo 25080 3226 faces 64520 1701 clipnodes 13608 1294 leafs 36232 3467 marksurfaces 6934 12835 surfedges 51340 7955 edges 31820 50 textures 451444 lightdata 0 visdata 0 entdata 3037 2.359 seconds elapsed Bytes used: 4108697 thanks for looking. That when sealed (i.e. no openings to the grey void but only the mystery leaks) the map DOES create a workable
i had something like this i ne_marb... basically, it was some complex geometry in the terrain area (where the shore is that leads to the cave) that was messing it up. you couldn't atually see any leaks but it was there... basically, i just ended up redoing a fair amount of brushes in that area to a much simpler look as it is now.
so that would be my only suggestion: find areas that have complex geometry (terrain, complex trims, etc) and try removing them and replacing them with simple placeholders. When the problem goes away, you know you've found the culprit(s), and can simplify/fix/remake/whatever sorry i can't be of more help. one last thing, i'd suggest trying out aguire's bsp compiler, it might have more luck on complex geometry ...by actually generating a pointfile so I could track down the leak. Thanks to biff, bal, and necros for suggesting it. Still a mystery why there were no leaks detected while processing the clipping hull but at this point I don't particularly care. :)
|
|
| You must be logged in to post in this thread. |
|
| Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors. |