 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
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. How do make elevator buttons that move with the elevator?
so how is done now? some trick as in half-life, like a fake button on the lift and triggers at the corresponding spots in its extended positions? but how could it be done (preferably without hacks) that it only works when the lift is in the right position? maybe with a skip/clip door blocking the trigger that was just used after the lift starts moving, while unblocking the other... a very basic question... I'm guessing some sort of crazy setup with trap_spikeshooter logic gates would do the trick. Still you can't make the button move first then move with the elevator though.
using a really huge button that moves outside the playable area when pressed. I might do something similar but better looking in the next map just for the heck of it.
...is use a mod like pox extras, that lets you attach buttons to lifts, moving water that actually works and have all manner of particle effects.
There is more stuff in there too. I don't think I've seen a map using this mod yet though :( http://developer.chaoticbox.com/quake.php yes ok. but i'd like to figure out how it could be done in vq (the manual way).
fern, where is it? - i couldn't find it in the map. sounds like this way it would only work for one-time lifts or lifts that go back into their starting position after some time. but i am thinking of a toggle lift (door). dunno about the logic gates thing. the button movement could be simulated through doors or trains with a button0 texture (and a button1 texture at the same spot on the lift itself) which then moves into the wall, so the button looks like it's been pressed. this method would still rely on the trigger, though, and only work if the lift/button was adjacent to a wall. it's the scarab button on the final lift, and the trick is basically the same as you described in your last paragraph.
i've been trying to get into this a bit and i've found i have absolutely no idea about a lot of the stuff this engine can and can't do...
for example, are there any major engine limits similar to edict limit of quake1? can you make rotating brushes? how does clipping work for bounding boxes? anyone know the answers to these questions? :P I don't think there are any real engine limits, you'd be hard pressed to reach them if they're were I think.
Can't remember about rotating brushes, but if it's possible it should be obvious from the func_s available. What do you mean about clipping on bounding boxes? For when you fire at models and such?
|
|
| You must be logged in to post in this thread. |
|
| Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors. |