josepezdj wrote:
Well, here is the bible about it (one of them). Read it and you will understand a lot of things

That's a very good guide, I used it many years ago to learn about map optimization and the visleaf system. I wasn't aware it was still around.

josepezdj wrote:
Well, here is the bible about it (one of them). Read it and you will understand a lot of things

This seems extremely helpful.

Off Topic: did you see my newest comment on the damask page? I am at a loss for how to get the cube to the bluegel area with the final button.

It is not mandatory to use areaportals into each level (other than always at the entry and exit doors). If you have a large area maybe you won't be able to use many of them anyway, since they are used to avoid rendering an area that is not in use and the player cannot see or access to. However (I had to learn this from my own mistakes ), the brushes themselves that are not func_details and separate rooms create visleaves in order to avoid rendering everything all the time, so depending on the player position only certain leaves are active in a given moment and the entities inside those are the ones being rendered in that moment. Alternately, you can use the skip/hint brushes to help the engine to know what visleaves can "see" others, reducing the chances that the compile will calculate by default.

For an open map, there's a brush entity you can try apart from skip/hint / no-drawing and func_detailing, the Func_viscluster

EDIT

Test Subject #54067 wrote:
Off Topic: did you see my newest comment on the damask page? I am at a loss for how to get the cube to the bluegel area with the final button.

Yes I saw it recently... I just replied today, go check it

TheTobbell wrote:
Do you know what i mean?

Yeah, I already knew what you meant in the beginning Even though it's an open area, aren't there any walls in? didn't you make rooms for your puzzles? Well, those walls should divide the player's view then and can be your first optimisation. I'd suggest you to test your map once that it's finished before messing around with optimisation. Then (only when you have compiled at least once) you can check out the portalfile in hammer (Menu > Map > Load portalfile) to see the visleaves in which the compile divided your map... Depending on what you see, you could improve one or other thing... Check out all of those bluen lines and follow them to see their origin. Normally, 90 degrees lines are ok, but other angles are not good (unless that you created them deliberately by using skip/hint brushes because you wanted to introduce a specific division where a couple of corridors meet...) Unless you have a ton of crossing blue lines filling up your map (if this happen check out why are those lines there first, what brushes are creating them, and if those could be tied to func-details), the func_viscluster won't help much...

Also I'd suggest you to decompile one of Valve's open maps (there are many) and check out the optimisation they used... this helps a damn lot

TheTobbell wrote:
But i thinked about that and how i can optimize that

THAT is the way You MUST prethink in all possible optimisation problems while you're mapping, I assure you that is far better than to remake a level or some parts of it again and again because of lagging problems Just read that guide and keep in mind all the knowledge that you can get from it before building the layout of an open area.. I'm sure it will help a lot to don't regret about the steps you take

lord_blex wrote:
...it would be kind of uncomfortable to use a weaker computer to test how the map performs in harsher conditions..

Get someone with a weak computer to test it.

ChickenMobile wrote:
Get someone with a weak computer to test it.

But that way I can't instantly see if what I've done actually does anything good or not. I haven't done any optimization before, so instant testing after every single step would be nice