Sorry your browser is not supported!

Got the weirdest slow down. It happens in two very different places. One is in a short hallway, three segments, with and "L" in it. What's really weird is the slowdown happens in one direction while you are headed towards the "L" but when you head in the opposition direction away from the "L" and towards an open space there's no slowdown. The Towards direction is headed roughly in the direction of a large open area with a moderate amount of geometry in it but there are no slowdowns in that area and the speed increases before you get there.

There's a second slowdown in an upper area of an open space. There are a lot of railings with transparencies in that area but the slowdown is very specific where it is and other equally bad parts have no slowdown what so ever. There were no characters on the level so I added 6 or 8 randomly about to see if it made things worse but it had no affect. Both slowdowns are in an areas that are maybe five foot square in scale. Potentially I could live with them if it was a real level and not just a test but I'd love to know what's causing them?

I've been trying to test the boundaries and see what slows the engine down since in all the posts I'm finding half the people say certain things slow it down and the other half say those things won't slow it down but others do. I have found certain things like active doors and I found teleports and lifts will. I avoided all those things in the test level. There were no windows but there were alot of transparent bits, railings and such. There are a lot of open areas but the joke is it ran fine still with all the railings and open areas. The slowdown happened quite suddenly and I was mostly adding some lights. I'm guessing it must have something to do with lightmapping but that lead to other issues.

First I deleted at least half the level and the slowdowns were still there. I have read that even deleting elements may not get rid of them completely so there maybe no way to correct the problems. It's the biggest reason I haven't started on the physical level for the Nvidia contest because I'm afraid of putting in a lot of work and having it slow to a crawl and I can't correct it. I definately plan to save often when I do.

In another possibly related problem. No matter what I set it at FPSC creates lightmaps. I can go into "Build" and turn off all lightmaps and it still builds them. Also I can change them, no lightmaps, soft light maps, full light maps, and it has no affect. At first I thought it was because I had level illumination set to zero but I reset that and it still happens. I also restarted the software but it didn't help. Just slows down the testing and I will say I noticed it took longer to generate the lightmaps after the problem slow downs happend.

Long winded but the issues had to be fully explained. It's really tough figuring out what slows down the engine since I've had it slow down on simple levels and had it run fast on very complex levels where I broke a lot and what I was told were the rules.

Also happens to me in a small area of a level im making.Dont understand why.

because the portal syste mstill needs some work in my opinion, press i think its [ or ] on you keyboard while running a test game and it will show you what is being rendered, you will see what i mean

That's something else I wasn't aware of Storm 6000, thanks

At first I didn't realize the point but it really answered the question and gave me some hints on how to avoid it in the future. Basically it's trying to render all the levels in your field of view. I had a thought that may have been the problem all along but it was hard to see what to do to fix it without the "[". It really got clear when I found the way to avoid the slow down was to turn sideways so you are looking away from area of dense polys. Normally with a game engine it'll render within a room or field of view. I wasn't expecting it to try to render everything through all the levels. It would be easy to avoid except for the conditions on the Nvidia contest make it hard to avoid. You need to zig zag the levels and don't go too dense with the number of hallways. If you can see more than a couple of levels at anytime in the "[" mode you have a problem.

Thanks Storm 6000! Massive help.

no problem im glad I could help out, its great for level design optimization, its a shame we dont have better control over the portal system so we could customisze it to work best for the particular level, it would be better also if it reacted based on whether doors were open or not although it does not seem to as much as I would like but at least it doesnt try to render the whole level or any rubbish like that, if you look you will also see it renders polys on the outside of your segments this is so you can them to have rooms withing rooms ovbiusly but it need to be better controled if possible because you have the parts of your level the player can never see being rendered

It's definately changing my level layout. Fortuantely I hadn't started to do the final layout because I wasn't sure what was causing it. I feel more confident with going ahead now. It seems like the two biggest issues are line of sight for the parts of the level and AI on the characters. I take it using Way Points can help with that issue.

I thought it through and it seems the best way to avoid issues with a limited footprint is to lay things out in a circular or spiral pattern so it limits what can be seen within your field of view at anytime. Really glad I made the post. I was stumped on this one since there were no active elements and I was still having a slowdown. I thought it was stalling as it loaded more geometry I had no idea it was trying to render in an Xray fashion.

Belseth,

The issue you refer to is the Serious Lagg issue related to culling of polys and FPSC poly counts which can be erratic to say the least. It can appear in indoor and outdoor levels but is likely to be more serious in those outdoors. It can indeed be influenced by the "Tile" or build level height you are on in actual gamepaly in test or final game rum the same. Its probably more likely to crop up near level extremities so the further away you are from the centre point of the level world the more likely it is to be serious in its effect. Typically it is restricted to small areas of a level and so can fps can quickly change from good to seriously bad over very short distances and the direction of view can have a serious affect on the poly count readouts being vastly different when looking in different directions and sometimes semmingly rather incorrect to the player or gamemaker. FPSC sometimes just does not see what you do. It reads polys as its sees them when compiled by the engine as it makes its calculations. In doing so would make decisions as to what it decides should restrict the polys to view from any given player position in the scene and from any given view direction of course which is where that influence comes from. In effect in its calculations the compile process would take into account what is commonly referrred to as level leaks and see through them in returning unusually high poly counts. Unlike BSP engines of some years ago when such leaks would be impossible to accommodate and compile failure or level corruption or crash could occur - thankfully that is not the case in these days in FPSC but the resluts can be as you see. It is very difficult to be sure of building levels to ensure you avoid this as the engine compile process does not always see what the level designer does in all instances and makes its own decisions and it seems some objects perhaps have naturual flaws in them allowing leaks to occur. If this crops up you can only try and build it out by re - designing levels. Building smaller less complex levels may cut down the opportunities for this to occur but its no guarantee either.

I am no BSP tree compile process expert so I can only give a layman explanation of how I see the problem causes.

Both the issues realting to distances from centre world point and directional view as mentioned have been well known issues and have been seen in numerous BSP type engines over many years though not all equally to the same extent.

As far as I am aware there is no fix on the horizon in the near future with regard to this issue for FPSC.

It's odd that everyone mentions outdoor levels because generally I find it's the indoor levels where the problems occur. I've even found looking up can often solve the problem since you are seeing less geometry. Just glad I have a better idea what's causing the issue. It's making sense also why I had some large levels with no problems yet I ran into trouble with fairly small levels. You really have to be aware of line of sight. Room dense environments are very bad. Better to break things up into as many levels as possible and offset things as much as possible. A lot of people mention large rooms or large open areas cause problems but I find those help if anything. That "[" once you realize what you are seeing definately illustriates where the problems lay. I am going to also do a test level in a modelling software so I can check line of sight before I build anything. Better to layout a quickie grid in something like Modo to check layout line of sight. Grid paper or Photoshop are helpful but don't accurately show you line of sight.

Belseth,

Its simply not true that either large rooms, large levels, complex detailed levels, or line of sight in themselves necessarily cause either Serious Lagg Issue or low fps.

There are many factors involved and every user will find differeing results depending currently especially on which engine version they use, their system and set ups overall and indeed their level design and content.

I have complex outdoor levels where I have a line of sight the whole length of the world size one end to another and achieve max fps and in a small corner facing a wall with nothing beyond can have 5fps. Line of sight or whats in view or numbers of polys have nothing at all do do with the issue of serious lagg as far as the level designer is concerned.

You can fill the FPSC world with complex content indoors and include many hundreds of entities I have well over 600 and have no lagg whatsoever.

Current versions with anything more than a few characters in view at any one time can see return low fps but its not relative to the Serious Lagg Issue. There are numerous issues realted to paths, physics, collision and script errors and many other issues which can also cause fps drop offs.

The issues are many and complex and experience using FPSC is the best helper in each individual case. Everyone can follow good basic design principles which should help too but they alone will not be enough if you want creatively flexibly designed levels - much use of every and all optimising techniches and methods will be required to maintain the maximum fps speeds needed for fast gameplay.

In indoor levels if slowdowns occur look for reasons for a possible leak and seal everything in an outer perimiter of completely enclosed walls - you add polygons in theory by if you know you seal a leak and indeed there is one if fps drops then the result will be less polys in the compile and faster fps.

Drawing levels accounting for line of sight on paper may help but FPSC compile wont always calculate polys in numbers as you see line of sight should make them. FPSC sees around corners and through solid walls to far away places when it wishes ignoring human logic. Seal leaks and look in wireframe mode to find uneccessary polys being dawn out of sight even at opposite ends of a level to player position when out of view from any location and take steps to remove them and you wont go far wrong.

If you are happy with very small simple levels and you game can accommodate that then you reduce opportunity for speed reducing factors to creep in to your games and lessen the need for any form of optimisation but again thats no guarantee.

Hard work is the ultimate solution.