CEONSS

Thanks for the work, Cat!

I am obliged to ask a few questions about the zones:
- why didn't you put portals on both sides of the stairs and the corridors? I've read couple of tutorials and they all recommend to create a "buffer zone" in such places.
- why did you remove the portals from the shaft?
- what is recommended number of zones per map and number of zones the player can see simultaneously?

EDIT:
2Cat: just to be clear, I think this map is ready for testing on the public server. There are no serious (or even moderate) issues in my mental checklist, and I'm out of overall improvement ideas as well. So, when you are satisfied with the zoning it can go right into the action (unless someone finds major problems with it).
2Everyone: a usual disclaimer:
This edit of the map is OK for me. Once it goes to the server, it's public and open for edits. I'd like bugfixes and polish (performance, graphics, pathing etc.) to be posted like minor versions (e.g. 1.1, 1.2) by whoever does it and bigger edits that affect the gameplay (like map layout changes, retexturing) to be posted as separate edits - but it's only my wish, not even a guideline and certainly not a rule.

Maniac wrote:- why didn't you put portals on both sides of the stairs and the corridors? I've read couple of tutorials and they all recommend to create a "buffer zone" in such places.
- why did you remove the portals from the shaft?

In both cases I just wanted to keep it as simple as possible to help avoid bsp errors.

If you type rmode 1 in the in-game console and walk about you can see what your engine is/isn't rendering (rmode 5 to go back). I try and use the fps (stat fps) as a guide when working out what is the best way of optimising a map. It's all just trial and error really.

- what is recommended number of zones per map and number of zones the player can see simultaneously?

The maximum is 64 for zones, for anti-portals I try and keep it 20 or less. If you look at a map such as Spacecargo it benefits from having lot's due to the ways it's been made, a map such as Masterbath really just needs a handful of large areas zoned off.

The players can see the whole map. All that zoning really does it help people's game decide what does and doesn't need rendering, and helps the server decide what data needs to be sent to each client.

EDIT:
2Cat: just to be clear, I think this map is ready for testing on the public server. There are no serious (or even moderate) issues in my mental checklist, and I'm out of overall improvement ideas as well. So, when you are satisfied with the zoning it can go right into the action (unless someone finds major problems with it).
2Everyone: a usual disclaimer:
This edit of the map is OK for me. Once it goes to the server, it's public and open for edits. I'd like bugfixes and polish (performance, graphics, pathing etc.) to be posted like minor versions (e.g. 1.1, 1.2) by whoever does it and bigger edits that affect the gameplay (like map layout changes, retexturing) to be posted as separate edits - but it's only my wish, not even a guideline and certainly not a rule.

That's great. I'll put it on now once I've check it on the testing server, and we can give it a week run just to make sure there are no bugs etc. If it's ok by next weekend we can remove BoF.

Thank you Mani

---edit---

You've probably already read it, but here's a good write up by Wormbo about optimising.

Yeah, that was one of the guides I've stumbled upon... I understand the basics of zoning, but I really have troubles understanding the core of it. Like, why shouldn't you zone off every room as long as you have < 63 zones left? Or why did I get HoM and BSP appearing and disappearing all the time after I tried to copy your zones to a new edit? Or when to put the portal planes above the BSP planes, when to put them strictly on BSP and when to cut BSP? And, most important, how would it all impact FPS?
I have *ahem* a special *ahem* PC, so I have troubles measuring the FPS before/after edit because it acts weird (remember me testing Rail for absolutely wrong result?) - I can see when it gets 2 or 3 times lower on average, but no more than this. It would be nice to have some in-deep explanation of how does the engine treat the zones, but with 10+ years old engine I fear there are none.
All I can say is: Practice makes perfect ftw XD

I'm afraid I don't know enough to give you the answers. I've seen maps made by hugely experienced mappers that have bloody awful performance, which suggests to me that there is no clear - do a, then b and finally c and you'll have the perfect map I just think about it logically at first, try it, make some adjustments and see if it's any better. Then just keep doing that with a game of hot and cold.

Sorry, I can't be anymore help. Unless Peg, Crusha, Wormbo or one of the other actual mappers can give some advice

Maniac wrote:[...]Like, why shouldn't you zone off every room as long as you have < 63 zones left?

At a guess I would say it's whatever's the most efficient for the engine to process. Asking it to make calculations based on your position in the map 64 times every frame or determining what should or shouldn't be rendered in 2 large zones.

On SpaceCargo it can quickly dismiss half of the map, whereas if you had 50 zones in front of you while looking down the corridor of Masterbath, it would have to make 50 calculations rather then, a more efficient, 2 or 3.

Or why did I get HoM and BSP appearing and disappearing all the time after I tried to copy your zones to a new edit?

That's just the bsp tree playing silly buggers. Sometimes you can lower your cuts down to 1 which can fix it, I had the same thing on Omaha.

Or when to put the portal planes above the BSP planes, when to put them strictly on BSP and when to cut BSP?

Personally I never put them above as it always seems to give me that flickering. I also try and go up to the bsp's and not through if I can help it as it seems to mess up the tree.

All I can say is: Practice makes perfect ftw XD

Absolutely, we're all learning

Like Cat correctly noted, the more ZP sheets you have, the more geo-based math calculations will need to be done per frame (client-side) or tick (server-side) to determine what should be drawn or which actors/objects are relevant and need their data to be replicated. Therefore, even if this complexity relationship isn't necessarily 1:1 (I assume ZPs in zones already deemed to be occluded are excluded themselves from further number crunching), it still is proportional generally speaking and thus some kinda resource-draining balance should be considered.
Since "try to make individual zones out of areas only where it helps to do so" borders on the tautological, my more practical advice on the issue would have to regress on the more general, golden fallback tip I've always offered editors: study as many different (but successful) examples of others' work as you can in the aspects you care to learn more about, and apply critical n' differential reasoning where needed. When it comes to average number of zones in ONS maps though, I'd doubt typical CEONSS roster entries are in the higher allowable regions, or even above the half-point, compared to the more indoors, complexly designed [T]DM/CTF affairs of higher relevant actor densities.

Regarding HoM and assorted visual artifacts that might appear after copy-pasting others' zoning work (or anything else containing visible placed actors, for that matter) into a new edit and rebuilding geometry, do keep in mind that UEd has a weird knack for pushing the newly pasted content 32.0 UUs in the positive direction for all axes, so you'll need to readjust everything accordingly in order to return to your contributor's true specifications. You can confirm you've done the job right via text editor comparisons before n' after placement, as everything copied or pasted in the 2D/3D viewports is essentially collections of actors whose non-default values are expressed in text and merely visualized in UEd - a realization whose workflow-accelerating implications blew my mind when I first found out about it .

Regarding whether the ZP planes should just be touching or going into BSPs/CSGs now, the most recent example where I got decent results that I can recount (and I think several others I examined too before proceeding) had them going into solid geometry, but only marginally. Additionally, I remember it also required dozens of micro-repositioning attempts before rebuilt lighting would cease returning freakish results at some tunnel entrance/exit, so do keep that in mind too, if it helps.

With enough patience and a bit of luck not losing your sanity in the meantime, the editor should bend to your will in the end and yield a worthwhile FPS & BW usage improvement.


Oh and one last thing. While it'd probably be more fair to say I'm still just a glorified map editor than an actual mapper (as in author), seeing how my obsessively perfectionist streak makes it pretty unlikely I'll ever attempt to put something together from scratch, let it never be said I don't know how to take a compliment. So cheers for the generous promotion there, Cat .

Thanks for coming by, Pegasus
I am always in doubt, and now I for once have a legitimate reason for this

Pegasus wrote:Like Cat correctly noted, the more ZP sheets you have, the more geo-based math calculations will need to be done per frame (client-side) or tick (server-side)

Here is one of many gaps in my knowledge. The BSP are cut into zones; if the zone is not visible, the BSP is not displayed; so, if zone is visible, it is rendered like always, and if not, it is just skipped, right? And finding out if there are zone portals currently on screen seems to be a lot easier to compute than rendering the whole zone. What am I missing here?

Pegasus wrote:study as many different (but successful) examples

Well, I guess it only comes with experience... I can't even tell if the example is "successful" or not

Pegasus wrote:Regarding HoM and assorted visual artifacts...

Thanks, I know about the 32uu offset on Paste (could they at least let users to change these numbers ffffs??), but in this case I remade the zones by hand rather than copied them via buffer - so, I guess, some of the geometry differences made old zones look bad on a new map layout.

Pegasus wrote:Regarding whether the ZP planes ... a worthwhile FPS & BW usage improvement

I suspect that this part of engine is sucky a bit. I've seen issues with lighting and emitters while working on zoning, and these parts should not be affected by zones at all AFAIK. Well, at least this part has some logic behind it unlike stupid bots crouching and running into walls when a navpoint is couple of uu's out of perfect route .

Pegasus wrote:I'm still just a glorified map editor

offtopic here...
If you want to know a bit more about Epic work process, you should take a closer look at CTF-Faces (the copy of UT99 map). Given the game creators, who themselves used textures named like "finishthismapfast" and single static meshes that contain half of the level geometry, and also given the perfect quality of the editor program itself, everyone who managed to get the hang of the editor camera can be named "map editor"; everyone who managed to do changes to a map without breaking it in process can be named "experienced editor"; and everyone who made the edits that made the map look and feel better and published them to real gaming servers can be called "mapper". So, you should be at least "experienced mapper" here . Just sayin'...

Maniac wrote:... Or why did I get HoM and BSP appearing and disappearing all the time after I tried to copy your zones to a new edit?...

If your geometry is good -on the grid- and you work on the bSP after zoning, you must right-click on a brush, select ALL nonsolids (greens ones) and order them to last, if not, the brushs between the first nonsolid sheet, and the lasts ones will be disappearing, beyond the recomendation of peg of the lag of copy / paste ...you must do this anyway before the last rebuilding.

.............

Yeah, sorry I could not join you, my ISP did bad to me. As long as you guys liked it, we can try it again today - I hope with better results