 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
I've added this little area this afternoon. It's actually the starting area. My map has more than 7,500 brushes no I may need to scrap some ideas and carry them other to another level. I haven't even made the silver and gold key areas yet.
I've also changed my image hoster since imgur blurs my pictures for no reason and they look like ass. http://uppix.net/1/e/2/6162d433fd88317f079225969d3a0.jpg http://uppix.net/c/6/6/f56a4e56184b90d4d838889a3af4b.jpg brushes aren't really a measure of how close to the limits you are. check out the stuff that qbsp outputs right after compiling (or use bspinfo on a finished
18087 planes 361740 65325 vertexes 783900 29085 nodes 698040 1743 texinfo 69720 56641 faces 1132820 58573 clipnodes 468584 15487 leafs 433636 64691 marksurfaces 129382 236371 surfedges 945484 127066 edges 508264 447 models 28608 96 textures 2493028 lightdata 1639628 visdata 863654 entdata 193675 vertices, clipnodes, faces and marksurfaces are usually the ones to max out first, but sometimes nodes can too. it depends on how you map. in most (all?) modern engines like fitzquake, the limit for vertices, clipnodes, faces and marksurfaces is 65536. limit for nodes is 32768. these limits are actually a limitation of the limit for nodes is actually: nodes + leafs together must be less than 65536. (in some/most high limits engines)
Thanks for the info guys. I'm used to Source and its brush limits so I've been quite careful with the complexity of my brushwork since the level is quite big and has a lot of detail.
It compiles well for the moment and I've only reached the node limit because of a leak, so I guess I'm good for the moment as long as I don't make it twice as big. sealing the leak will usually net you a lot more room to expand a map because the compiler can remove all the extra faces outside of the map which lowers all the counts (verts, nodes, etc...) quite a bit.
also, hl2 has an explicit limit on the number of brushes?? Yeah there's a certain threshold with HL2 you absolutely cannot go past, otherwise you'll get the awesome MAX_MAP_BRUSHES error in your compile window. The limit is something like 8,192 as far as I remember. This happened to me a couple of times, and there's also the t-junction limit that's pretty annoying when your map is full of func_detail.
As far as I remember displacement surfaces are counted as brushes with HL2 but I might be wrong on that one, I haven't used those in a long time. I always wondered why hl2 maps tended to be so small, I just figured it was to speed up loading time. I wonder why valve put in an artificial brush limit like that. Did the old id tools have a brush limit?
As far as I know, modern qbsp will accept any number of brushes, it will only halt when you go over a bsp format limit which would not be able to be loaded into an engine anyway. I don't know about the old id tools, but I do know that GoldSrc's tools had a similar limit, but 90% of the time you reached the MAX_MAP_CLIPNODES thing before hitting the brush limit anyway, if it wasn't the dreaded Allocblock:full madness that made me ragequit GoldSrc level design at that time.
It's great to hear modern Qbsp can handle a lot of brushes. clipnodes are one of the few things that you can reduce without impacting the map too much simply by filling in (or covering up) bits of the map that the player can't reach with clip brushes.
inset lights, unreachable terrain and such. that said, i've rarely hit max clipnodes before hitting other things like max vertices. if you do find yourself getting errors, http://user.tninet.se/~xir870k/tooltips.txt is a great resource for figuring out what is causing them. someone post more screenshots!
I would but any screenshots I might post are from a map that's (hopefully) almost done anyway. tonynfish...
my maps as well are hopefully. my coiling waterfall goes well. http://members.home.nl/gimli/fall01.jpg then my mr big got too big. http://members.home.nl/gimli/big00.jpg my torment is almost done. http://members.home.nl/gimli/tor00.jpg bleh! shot 2: his ambient sound needs to be FEE FIE FO FUM, and trigger the earthquake effect when he walks!
It'll be interesting checking out all this new stuff, looks like way way more new stuff than your last release. Mike, screw your babies, have my babies ;) Those shots look fantastic, looking forward to playing it!
it seems today is the day for pixel pimping!
http://www.simonoc.com/images/design/sp/its4.jpg (large image 1.5Mb) Was messing with TROR in an old, unreleased Duke mod of mine recently. Wish this Eduke feature came years sooner when I actually required it the most. :(
Screenshot~ oic, tror = true room over room, so that is proper geometry then. i'm surprised it took so long to do... it was the main reason I went for quake mapping over door/duke3d. :P
I remember using sprites and sector over sector (which wasn't necessarily over, and could be in exactly the same place just entered from different angles iirc) in duke3d! the entire engine was hax!
nice and tidy looking shots. And thanks everyone for all the great-looking Quake stuff. It's indeed shaping up to be a great year.
|
|
| You must be logged in to post in this thread. |
|
| Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors. |