 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
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. :)
Is it possible for you to rebuild the fr3n1m3 map using my qbsp? It's got those annoying tjunction sparklies. Or if you'd send me the zipped
I asked for a link to yours and got txqbsp and treeqbsp. Whatever I used, it worked. But what am I SUPPOSED to be using? I hate those sparklies just as much as you. :)
my compilers, you don't have to do anything special; they both default to tjunction padding (= no sparklies). It's some of the old compilers (e.g. dubsp) that default to no tjunctions (= sparklies).
But I was under the impression that I already WAS using your compilers. Is this the wrong URL or something?
http://user.tninet.se/~xir870k/ my initial request above was for the released fr3n1m3, which as far as I can see has the sparklies, i.e. it's either built with an older compiler (e.g. dubsp, which you also asked about before) or using my compilers and adding the -notjunc option (definitely not recommended).
The URL is correct, sorry for the confusion.
|
|
| You must be logged in to post in this thread. |
|
| Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors. |