why portal flow is taking to long?

[Sgt Frag]

Whilst you seem to grasp the mechanics of hints, you don't seem to understand the process of vvis.exe.

I understand it. And I never meant that hints are gonna drastically slow down compile time.
Merely that they make more vis-leafs, more vis_leafs increase time to compile because vis has to calculate each one and what it can see.
He was originally asking how he could cut time so I pointed out that more leafs=longer compile times. (even if it's only in seconds)

There really isn't a huge difference in compile time from a small (optimized) map to a large map as far as vvis goes, so I didn't mean to be -um, I don't know, confusing?

Between my smallest map and largest vvis is probably between 5-20 minutes. (my comp is pretty fast)
Now lighting on the other hand could be alot larger time diff.
-------------------------

From the pics I'd say a few things could be improved for compiling AND framerate in game.

1: I don't see a problem with the pyramid as far as vis-leafs go. Like Terr said though a hint across the top could help to stop splitting leafs as much. It won't help optimize any (as far as blocking vis goes, although it will clean it up and make fewer leafs), and there isn't alot you can do about that except fitting skybox to it....

If you only want square leafs (no reason but if you do...) then you could actually make the pyramid like a stepped myan pyramid, then just have angled func_details between the stairs to make it look trianglular. But I wouldn't do that.

2: skybox: All the details up top around your map should be skybox, it would help performance and cut down quite a bit on vis time.
At the same time you could make the tip of the pyramid end at the level of the skybox. Then it would have NO leafs above it that are basically worthless anyway (doesn't seem players can jump that high).
Right now it looks pretty close to that same level so you are pretty much set.
-----------
With that said the major issue you have is your map is one huge open area and the ONLY thing that blocks vis is the pyramid itself.

Around it you have HUGE areas of openness. players will be able to see the entire map almost all the time. It's gonna slow down framerate in game AND take along time to compile even if you do as I say above.

It would help your map alot for gameplay (sniper site lines, framerates, etc...) to close it off alot. Put some buildings on the other side of the 'road' (grey tex, I guess it's a road) and even make the road half as wide to pull those buildings in closer.
Fill in the edges of the map with buildings/cliffs to take up alot of that open space.
(less airspace = shorter vis compiles).
It'll also make it look more interesting and give more areas, corners, nooks for players to hide/take cover.
And add more stuff to block vis and sitelines.

Even inside the pyramid you have that huge long tunnel that gives players no cover and doesn't block vis from one side to the other like some walls with doorways could.

 

[ricardojvc6]

well possibily i could use the batch compiler it maybe works it could be much easier. Hints and areaportals and occuluders will be placed soon because i need to understand how to work with them

 

[grazr]

I understand it. And I never meant that hints are gonna drastically slow down compile time.
Merely that they make more vis-leafs, more vis_leafs increase time to compile because vis has to calculate each one and what it can see.
He was originally asking how he could cut time so I pointed out that more leafs=longer compile times. (even if it's only in seconds)

There really isn't a huge difference in compile time from a small (optimized) map to a large map as far as vvis goes, so I didn't mean to be -um, I don't know, confusing?

Between my smallest map and largest vvis is probably between 5-20 minutes. (my comp is pretty fast)
Now lighting on the other hand could be alot larger time diff.

Well you're half way there. You're not wrong in the fact that loads of visleafs increase portal flow dramaticly, because essentially they do. But there's 2 relationships regarding that factor.

And this is for everyone really: As a general rule, the first port of call for optimisation comes with the layout.

Frag: Lots of leafs will always be worse than less leafs, if you can help it. But it all depends on the map.

Portal flow length depends on a number of things. I think this is where I came across confusing. As i left a number of assumptions in your hands. Such as layout.

The amount that is calculated per visportal contributes to portal flow length (you know that really slow bit at the end? this is the calculations being made after the portals are assigned). A portal that can see a lot will take as long to calculate than many that do not see much (on a grand scale, as it's like a sea-saw balancing portal count and portal visibility, if you have the extreme end of either scale such as a simple map, this does not play out the same).

So, loads of visportals seeing not a lot will compute just as fast as a moderate amount that see many faces. Give or take. Map size contributes to this factor. In this (ricardo's) case we have a worst case scenario, a lot of small visleafs seeing a lot of the map. Which makes the portal flow insane. One step would be to reduce the number of portals. Another, is to improve layout and visibility.

I note however that i am drawing a fine line on something here. As the benefits are purely circumstantial to map sophistication, and a good map layout increases the benefits expenentially. So my illustration on such a small scale would actually probably play out incorrectly. But the assumption should be made that the complexity is much more than what is shown. As i cannot be arsed to draw out a detailed map for the sakes of arguement.

This layout reduces the potential calculation cost involved in calculating the visibility per portal. The calculations will be simple and efficient.

This layout trend will be seen throughout the majority of FPS games, depending on the engine. It closely mimmicks CP, A/D CP, PL consistantly, and in a more complex state, CTF and TC and other game modes.

Lets take a look at a less efficient layout. The layout will involve open area's that look into other open area's. For instance: imagine this is the size of a full map, with very wide and open area's.

Now, you're probably thinking "yea yea, i know all this already. Hints 101. Stop wasting your time".

But there is a relationship between portal sight and portal flow.

Lets say i change the layout by lengthing a certain passageway: subsequently increasing portal count by 2.

Now, despite the fact that we increased our portal count. The calculations involved in the final process in vis are a lot less per (particular) portals.

In 3d. We see the potential calculated data for rendition.

This is an extreme case, but assuming on a large scale, the potential would be to shave a quarter off your portal flow time. Despite the fact that we increased our leaf/portal count.

What ricardo has here is an extreme case of around 75% of the map being able to see 75% of the map via around 100+ visleafs. Unfortunately a case of a lack of research on the author's part on the engine mechanics, which has lead to a poor layout choice on top of neglected detail optimisation methods.

I'd include solutions but you covered the basics pretty well in your third paragraph.

 

[ricardojvc6]

that tutorial its very good i think it will help in small areas but on the stairs case how it will work putting hints there? is because some parts of my map has to manny stairs

 

[Sgt Frag]

edit: i didn't see the last few posts:

You explained that well grazr.

The best thing to do for your stairs is simply to func_detail them ofcourse. that gets rid of all those tiny leafs you see in your pic. Better just to have one leaf there instead of 20 little ones, because either way your stairs can all be seen).

Probably the best way to use hints on your stairs is like a floor/ceiling (horizontal) instead of vertical. So when you are above them and aways away you can see down into them. BUT, there is probably already a split there because of the hole in the floor to them.

re-edit

[/IMG]

This shows why just adding hints doesn't work.

The green line is the edge of the leaf without hints. The red line is a new leaf created when you added the hints.
So all the way down the wall you have created about 6-8 leafs that don't do anything.

Better would be to put a wall along the stairs so from this view they'd just be completely blocked by a terrain brush. That would limit sitelines. Adding that hint only complicates the situation and doesn't help block the leaf at the stairs from seeing into the leaf where the camera is, which would be the point of adding a hint there.
A wall would work even though it might change your artistic vision. But we're talking about performance first, artistic vision second.
----------
pre-edit

Honestly I don't think they will do much for you.

Sure it's good to use them to learn how, but it needs to be in a useful situation or it won't teach you anything.

Using open areaportals in the doorways is one thing you could do that could help.
Basically just put a brush to fill in each doorway, put areaportal tex on it, make it a func_areaportal. Done.
That will cull objects that can't be seen through the portal directly even if they are in a leaf that can be seen. That includes players so if a player is inside and one is out, but don't have a direct line of site they wont be rendered.
That's easy to overlook when looking at wireframe by yourself in game, player models have lots of polys and when you have 10+ of them it can help alot.

Hints only cut current leafs into smaller ones. This is good if being smaller they will not be able to see into others. But in your map there isn't much to block sitelines anyway, so I really don't see them doing much good at all.
You might be able to place a few but they'll have minimal impact at best.

Occluders are the same. They will block ALL objects directly behind them from player. However they need to be in a wall (func_detail) or inside a very large object that blocks the view of objects so players don't see objects just disappear for no known reason.
Again, you don't have anything to block views to hide occluders inside of, so you won't see much benefit there either.
----------------

I think what alot of people miss in optimizing is that you really need to optimize your level as much as possible without portals, hints and occluders.
If you level is poorly optimized then all the hints, portals and occluders in the world can't help.
All they do is help optimize more IF possible.

So closing in your terrain, limiting sightlines, lowering the 'roof' to the top of the pyramid and putting everything above in the skybox is gonna give large improvements in performance.

THEN you will have more smaller areas that will more easily be optimized further with hints and occluders. But without closing off the map more I don't think you'll get any noticeable performace differences and you might even make it worse.

Hammer (like most games) just can't do well with enormous open spaces. That's a limitation we have to work around.

 

[evanonline]

Seriously, I had it when I forgot to func_detail a bunch of stairs and it cut a huge hunk of time off my compile time when I did. func_detail up 'dem stairs if you haven't already!

Optimization seriously baffled me in my earlier stages but it becomes very simple to understand after a while. Optimization itself relies on having solid level design to begin with. ...which neither of my first two maps have.

 

[JoshuaC]

I think those stairs have more visleafs than my entire tomb map.

 

[Open Blade]

Big open maps where you can see almost all of the map = bad

As probably many mappers here have learned the hard way (I did as well), big open maps are a nightmare to optimize. I think most new mappers don't realize this and thus they make a really big open map. I was no different at first, making huge massive open area's cluttered with props.

I know it can be hard to understand alot of this visleaf stuff so I try to put things into more simple terms. Your map layout, and how you seal off areas of your map from other areas using world brushes and skybox will do more for optimizing your map the hints, at this level anyway.

Now, my rule of thumb is that I want my entire map segmented into at least 3 equal sections and they all must be sealed off from the others, via world brushes, skybox and areaportals. Those 3 sections include of course smaller areas which have their own areaportals thus sealing them off even more but they do contain outdoor areas. That's the key. Insides are easy to optimize placing a ton of func_detail and areaportals but you want your open outside areas divided up into smaller outside areas. Doing that with world brushes, skyboxes and areaportals. Hints are important too and I still don't fully know how to use them best, but I think all of the experienced mappers here agree that you really want to try avoiding just having one massive open area that contains most of the map. Not only for optimizing reasons but even more so for game play sake.

 

[ricardojvc6]

right i func_Detailed the pyramid, stairs.. all of them , doors windows and some objects i got some things like this much open visleafs like manny of them have disapeared http://img238.imageshack.us/img238/7537/pic6.jpg http://img131.imageshack.us/img131/4932/pic7.jpg http://img354.imageshack.us/img354/8673/pic5r.jpg

 

[JoshuaC]

Much better! The map already is gonna run alot more efficiently now that those have been func_detail'd.

 

[Sgt Frag]

Not sure if you'll get better results with or without the pyramid itself func_detailed.

Before it probably blocked some view, but maybe not enough to count. The (I assume) 4 very large doorways on each side of it could remove any benefit of it blocking view.

Best way to tell is to try each version with +showbudget typed in console.

If it's better func_detailed you can probably gain performance by using 8 occluders.

One on each side of each door to the corner. double sided (no draw on brush, then put occluder only on the 2 main faces).

So you'd basically have an occluder pyramid hiding inside the func_detail pyramid walls. That would completely block all objects behind any of the pyramid walls from rendering. Would probably even work better that having the pyramid walls themselves trying to block views.
And 8 (12 if you put them above doors too) occluders will probably have a very minimal impact since there are so few.

I used about 8 in sandvich (which is one huge room) and it barely even registers in +showbudget, but cuts down on ALOT of model rendering throughout the map from all views.

 

[ricardojvc6]

yes, the compile like gives an error whend i compile i'm not sure what is it it just freezes and do more nothing i think func_detail'd to much things so it gives errors

 

[lucky]

So long as you didn't func_detail anything sealing the world..

 

[ricardojvc6]

i didn't.. nothing on the skybox its func_detail just stairs doors windows pyramid some wierd things

 

[Darksoul]

You could do what Valve does with huge buildings in the middle of large open areas; they cover them with occluders, take a look at the sample maps in SDK content. The secondth capture on the secondth stage in Dustbowl that building has an occluder all over it, in arena lumberyard the entire middle building is covered in occluders...I'm sure Valve knows best.

 

[ricardojvc6]

well i have func_detailed the all entire map just now and it seems to not stopping at portal flow and i have another problem the compile freezes..i wonder what is the problem. to manny func_details or.. low RAM?
i didn't func_detail displacements walls and floors and nothing what is from the skybox

 

[Vigilante212]

are you func_detailing each object seperatly? If you are dont Make the entire stairway one func_detail. Post some more screenshots and the compile log if you can. Also a good program to compile with is VBCT (Valve Batch Compile Tool) This makes it so you dont have to have the resource hog hammer running while you compile.

 

[ricardojvc6]

valve batch compiler doesn't work seems to give an error when I try to compile and the valve compiler seems to freeze i think i don't have manny options to choose a compile

 

[Psy]

Ricardo, visit [ame=http://forums.tf2maps.net/showthread.php?t=1429]this thread[/ame] to see how people make use of func_detail.

 

[ricardojvc6]

Ricardo, visit this thread to see how people make use of func_detail.

that help me alot psy
now map works i have already compile it and it worked now i just need to know to upload it to the forum do i need to use a link like mediafire or ...FPSB