Has anyone found Occlusion useful yet? I have tried a few different types of projects and on all of them I have had to lower occlusion to less than 10 or better still, off. For the majority of maps it is still fairly unhelpful. I can see it working in really small doom style maps, but not much else. The main issue is it's way of hiding smaller objects when they are way, way too close. Also the odd redraw of some objects when you turn around (very intermittent, but happens often).

I'm very disappointed with it to be honest and was expecting it to be really useful. As it is, visually, I'd probably be better off disabling it and going back to my own occlusion script. At least with that you can alter the draw distance and such as you need. The built in occlusion, for me with one slider, is never going to work for all game types, or it seems that way. I know this is aimed at being easy to use, but a bit more control would be far more useful to anyone making a game. Have a big open world style game and you will immediately run into problems. After all you will have large open spaces and it is just rubbish having bushes and stuff popping up right in your face.

You shouldn't have to build your map around the occlusion, you should set the occlusion to suit your map. At the minute you can sort of, but hell it's hardly worth the bother with most maps, I end up just turning it off ( although you lose most the speed from the update ). Setting it to 10 or less actually doesn't really give you much of a speed increase, but can still have pop up. You can also see much flickering of objects when you are inside a building with glass windows ( eg. the new building interiors in the DLC ). Shadows still pop up badly as well to add that into the pot (you can't do anything about that at all).

It still needs a lot of work from where I'm sitting. I did a lot of specific tests and maps for occlusion over the beta, but even so the end product feels broken still. If it can't be made to work as is, options should be given to alter it to help on maps with larger draw distances. I literally can't remember a commercial game having pop up of late, of any kind. You occasionally see texture updates as you get closer, but even that is pretty rare.

I haven't tried the xmas build as yet, it may fix it, but than again it may not.

Well, I''ll try to write fine, after many wine+champagne bottles, (named "cava" heree in Catalonia, the net smaallest free country araond tthe word), LOD does not have nothinnf to do with Occlusion, if not, why not????, both does the same, well almost the same. (not wine emoticon here)

3com

I've use the "Occlusion" and work fine for me. Must be reduced at 75% or more less to not show the enemies behind the walls.

It's not going to do much on outdoor maps where you can see for miles, and you'll want it less than 10 to avoid pop up.
If you can use the terrain, or walls, or buildings, to limit the range of vision then you can turn it up to gain some FPS.

I tested occlusion at 0 and at 11 on 2 maps. Both maps saw increases in framerates.
Morning Mountain Stroll = +5 FPS with no pop up
Get to the River = + 15 FPS with pop up, but much better than reducing camera distance to get the same framerate

If entities had a setting for "occlusion factor" or something would be nice. Say you had some barrels in a building that wanted to occlude, but also had barrels along a path that you didn't want popping up. You set the "occlusion factor" at 100 for the barrels in the buil;ding, but only 50 for the barrels on the path. Occlusion works as normal for the barrels at 100, but the barrels at 50 can be seen from twice the distance at the same occlusion setting.

I found it helpful on a forest where I added a ridiculous number of trees (I think the lightmapper said around 2,000?).

Without occlusion it shows 2,139,480 polygons, with it there is 1,023,418. That's a saving of 1,116,062 polygons because of occlusion!

There was also the boost from 21 FPS to 44 FPS. Fog and depth-of-field help to keep the illusion that the entire forest is being rendering at once.

Personally I find the same as DVader, having a relatively low end system and open world style levels in the main.

I have spent a few weeks even re-creating/replacing largely my content and bought some new trees and alike from the store to replace most of those I had been using as the store ones make better use of LOD.

I have around 350 entities in a level which is hardly any in a large world, never mind a largely open world terrain style one.

I don't find any benefit from either Occlusion or LOD systems and turn both them off as what little benefit they can return is more than cancelled out by the popping up of entities popping up unacceptably during game play at all ranges looking like a visual graphic equaliser playing notes of a tune That together with the veg system draw of grass as you go kills any respectful presentation of your hard work, so I have to set the veg quality as high as possible too within reasonable balance....effectively meaning that one is between a rock and a hard place.....

Fewer entities and veg and no popping or more and popping, neither of which is useful. Of the two choices the popping of entities and veg (not to mention the textures and shadows popping of course) is the worst of all and unacceptable during game play so one is left with reducing entity numbers which need to be increased vastly and impossible to even consider for me. The only other option is to abandon open worlds completely or restrict them to deserts or Mars where there are no trees or other terrain entities needed and where no equivalent number of rocks exist either. i.e. a barren (ish) landscape. Or possibly restrict your actual game area to a fraction of the area of the GG world which most GG demos do quite effectively within the game play area as you know.

Inside the editor one has some options (though none help in this instance) but in the compiled games things can get more difficult as your in editor level settings - set by you perhaps to benefit your own game needs are overwritten - by just three choices which don't necessarily match your development ones where all your settings may be finely tuned and mixed and matched to maximise them to your benefit. Compiled games can thus show less fps than your in editor test ones or more perhaps if you choose lowest quality in compiled game but resulting in a lesser quality. i.e. a compiled game does not necessarily run and display with all settings exactly as you set them up in editor as you may have used lowest settings for some things and highest settings for others. I can understand the reason for this compiled game choice of settings of L/M/H of course as the easy end user option perhaps for choice of graphics quality from that point of view.

I guess users findings will vary depending upon many factors and preferences. Despite I am sure many thousands of additions to the engine and a vast amount of work a lot of the basics (most of them) are still desperately in need of attention as they have not improved a great deal for years for me personally and have deteriorated or been removed in many instances as we await them to be updated again or re-added/added as part of the feature list or released to end users as non hard coded items.

Indoors or out no difference, much it seems still needs to be added/updated/improved and some basic stuff given attention some where along the line.



EDIT UPDATE :

I have a few more comments on this :

I have just spent some time trying to optimise some things to see what I can improve on fps returns :

Basically I have simply removed a lot of "Small" Trees/Bushes from a level to test results.....

I have an open world - its not flat so has hills and mountains Yes. Now in test run in editor if I move to an area away from entity populated areas where a lot of those entities are now removed and look back towards the area (from where I would not have been able to see them anyway). where terrain hills block the view to where they were - I now have almost double the fps from my viewpoint? so deleting them adds fps. Clearly the terrain we have does nothing to block the camera view (only to player view) and any entities out of line of sight - entities which cant be seen are still drawn and calculated as far as the engine is concerned. Before removing these entities the camera/player would not have been able to see them, nor any other entities blocked from player view by the terrain in front of the player but the engine still computes them?

We have integrated LOD and occlusion but that does not seem to affect or impact at all here in an open world where Terrain hides much of the existing entities at any one given time/camera viewpoint? LOD and Occlusion should not be needed in this instance as the Camera should by default only "draw" any polygons, from any source that are in (Player/Camera) view which is why presumably we still have so many draw calls? Why is the camera/engine calculating entities that are hidden from Camera/Player view? but in this case not hidden as far as the engine is concerned so it seems. Entities are always drawn and calculated if hidden from Player/camera view by the Terrain, must be the case or otherwise why does my fps go up by almost doubling if I delete entities which cant be seen by the camera and should not be calculated anyway?

Further to this. I don't have enemies in the level - took them out as they don't work well anyway....

I do however have some AI characters in the level - I have some animals. i.e. "Wolf" now these are set not to spawn at start and are spawned by Trigger Zone and I had presumed that might help fps/performance as not all animal entities exist in the level all at once. At least that's what I thought.....

If I bypass the "Wolf" Spawn Trigger Zone and move to the area where they will spawn without triggering their spawning they cant be seen as they have not been spawned yet but still attack and hurt me. Question is are the Wolf entity models just hidden until spawned by the trigger, whilst still existing and being calculated and a drain on fps by the engine? Whatever, in any case I should not be attacked and health lost if the wolf cant be seen by the player.

Much like the trees referred to no matter what world object we speak of if it cant be seen by the player/camera it should not exist and or its ploygons need be calculated by the engine and should be loaded/unloaded on the fly by default - unless needed to do so and be overidden by the user via the user LOD and occlusion management systems.

Perhaps I am incorrect and don't understand how,when,where and why these things should or do work but seems to me that as a default any world object or entity, their polys and AI should not be calculated by the engine if it is not in direct view of the Camera/Player or otherwise in a large complex level that could amount to a considerable performance loss.

)-:

Maybe I am completly wrong, but all you describe has nothing to do with occlusion Occlusion is a technic to calculate Thats all
http://www.geforce.com/whats-new/guides/ambient-occlusion#1
What you mean is culling and nobody said anything about culling in this update. Port to C++ and Occlusion. Everyone was so happy with the new update, so I was quiet, but on my Pc I get ca 10 FPS on each level, so not really a big performance update in my eyes. Why there is a slider which is called occlusion and if I moved it, pop ups appear, I can´t say.

What I thought what we get after all this Performance weeks is something from this:
http://docs.cryengine.com/display/SDKDOC4/Culling+Explained

But I did not see this anywhere, but we should write good comments on steam. That was important.

Also after I ask which return statements we get from the new weapon commands, I get a copy of the blog entry(which I read, because otherwise I never heard of this commands) and the answer I should find out myself with trail and error. Easy game engine where you should do their homework yourself...

Its strange ...
Even with the occlusion right down and full detail my fps have doubled
I could never have done this before ... The whole thing just runs faster for me overall .

I`m also getting 28/32 fps, but before does not, (12/16 fps), with my crappy card, this is too much, I thought.

3com

Frame rates in game seem the same to me according to the figures I get but everything definitely responds a little better (AI fire more, you run and can fire quicker etc)
And even at sub 20fps it still feels playable which is great because we all know frame rate drops fast when really building a full game.

The biggest thing I'm happy with is the editor though, it used to really crawl for large levels but now it's much better.

Personally I don't get any difference with occlusion, no frame rate change, no popups or such... I can set it to 100 and see it does clip distant objects so I know it's doing something but it doesn't seem to alter the fps for me. (I'll admit I haven't really played with it much though)

It seems some are experiencing the issues I mention and some not. It also sounds as if it is the slower machines having the issues.

I have a low speed system compared to modern ones, my CPU for instance is about 10 times slower than a good I7 (from benchmarks). I have a 660 GTX video card which is okay, but not exactly a high end card compared to any 070 or 080 card. I have yet to find a modern game that won't run on it and when I say run I mean run play-ably. Even GTA 5, which I expected to have to lower things down, ran fine, even at 2K which it defaulted to. It is then quite the shock to see that running so well and then go load in my 6 houses and a few trees GG map to find it choking... I agree performance is better than it was, but the fact I can't use occlusion in any meaningful way, means most benefits (that I can see) are lost and I'm pretty much back to the same place.

I don't expect GG to have the same power as the GTA 5 engine, but surely we could get a little closer than 6 houses and a blank map? Without having to drop shader effects and such? I've been around here since the start and I'm a fan, but I also see that GG seems to be stuck at a level now and cannot seem to get out from it, even with the recent C++ conversion. In honesty it is actually worse in some areas than it was. Terrains look like repeated carpet still (yet they used to look much better), graphics have that jagged glitchy look that games had in early 2000. When you come out of a modern game and straight into GG you notice it massively.

The DX11 stuff may help with this, but I'm starting to think it's as fast as it is ever going to get. I personally believe the draw call rate is the main offender and until something is done to improve this GG will always struggle on an average system (which lets face it, is the majority of potential customers). You should not be seeing 1000's of drawcalls with such a low number of entities and a terrain. Especially if you are using the same image for most of the entities!

I digress however and am sure if the Occlusion worked effectively would certainly help to maintain speed a lot better. I get a big difference with occlusion on 100 rather than 10 (in general at least 30 fps or more). It still struggles with the draw call issue in places at times though , although I'm not sure how TGC could integrate, it while keeping it simple off the top of my head. Still, if you have 100 buildings in a scene and you can get away with it only using one diffuse texture for all of them, and thus only 3 draw calls for all the houses (the normal and specular) things should fly along! At the moment, those 100 houses would be using 300 images, even if they are the same ones and hence 300 draw calls I call that inefficient and a big reason why our games chug compared to others.

Fair enough many would not be able to take advantage of this as they do not make their own media. But you will notice quite a few store items that already support this anyway, and have one single diffuse, normal and specular texture for several items.

Nothing to do with occlusion, but....



Good question....From what I've noticed, when you "Destroy" an entity, it becomes invisible and ceases to interact in the physics system, yet it does exist and it's script continues to run and the engine continues to update it's position. If "Spawn" is opposite of "Destroy" then the wolves are always there, just invisible and able to pass through walls etc.

You might try setting your wolf script to "default.lua" then when they are spawned use "SwitchScript" to change to your wolf script. This should prevent them from doing anything before they are spawned.

If you watch this video, you can see at 0:18 when the entity is "Deactivated and Destroyed" that it's script is still running, and it's coordinates are moving because the "Distance" keeps increasing. Only after changing the script to "default.lua" does it finally become inactive, though it does still exist in the engine.

https://www.youtube.com/watch?v=SqLc50CCjsU

Thanks for that wermer. Removed the trigger zones for spawning now anyway as they are not ideal in other ways either in this case. Replaced them with spawn on player proximity in script which is much better in many ways.

Whatever. It does not solve the central issue of entities effectively always existing as a drain on the engine and level performance in some way or other to a greater or lesser degree. To overcome that we need to be able to load and unload load entities on the fly at runtime I guess, as specified or managed by the game designer (preferably via flexible internal user choices/editable/definable mechanisms), so they don't exist at all, unless needed and have no or less impact on performance, if not needed during game play, though not hard coded and for that we need TGC help perhaps? Of course there is always some trade off and such systems themselves have an impact by the nature of the math an such like they need to call upon during gameplay and so on. There's always a cause and effect, benefit/drawback at some stage and an optimal ideal balance beyond which a benefit may be cancelled out - at least in theory. I am no game engine design engineer so cant help there.

Just seems to me whether it's polygons, textures, AI drain or anything else needed by world level content, by and large I don't see a point in it existing and draining performance during game play if its not part of the scene or game play at hand/to view.

Relevant whether you or your end users have a low end or top range system.

Presumably at the moment "all" content of whatever nature used by a game level is by default loaded at level/load run time and in the main permanently exists ticking away in the background, eating performance whether or not its needed at any one location in the level and continuously throughout game play at least at some level.

I can think of some more things end users can do to help their own games performance perhaps but most will rely upon help from TGC in designing the engine internally at the core. No matter what end users do their scope and impact is limited to what the engine will allow and provide for at it's core.

I can confirm that scripts continue to run even when the object is deleted. I don't think it drags performance down drastically, but obviously when we are struggling for frame rate everything helps. I sent a mail to Lee or Ravey about it quite some time ago when the performance update had just begun. If you destroy an entity, it should stop running scripts and exit memory completely you would think. That certainly doesn't happen at the moment. I wouldn't be surprised if that has something to do with the bugs you can find when making a multi-level game.

I'm having the same problems as DVader and Uman with open world levels. The lua command helps somewhat in that I can turn off occlusion culling when the player is in areas where popping occurs, but of course lose the benefit of the occlusion (even setting to '1' doesn't help, has to be off completely).

There is a 'notanoccluder' fpe setting for entities that do not shield others (e.g. if transparent), but I think a 'notanoccludee' flag is also required so that entities are not culled by the occluder in any event - this would probably help with some of the open world issues in that mountain range (entities) and other items like this could be excluded from the occluder and may make this aspect more useable. Yes it should 'just work' perhaps, but even if it performed better than it does now I still feel there would be times when this flag would be needed (some manual tweaking / fine tuning always needed perhaps, but the capability has to be there to allow it).

I don't think the GG terrain is acting as an occluder from what I can tell, seems to be more distance and camera view angle. I've no idea of the difficulty (or if it's even possible in a practical automated way) to add this feature.

The one technique I'm trialling now to improve FPS is to use an entity as the terrain and remove/hide the GG terrain. This makes dramatic FPS improvements, but obviously is much more difficult to generate and change. Also currently I have to match the underlying GG (hidden) terrain to the geometry of the entity terrain to enable the AI to traverse successfully and to ease other entity placement on the level. It works but sucks up a lot of time .

Cheers.

Hi All, thanks for the feedback. I am warming to the idea of a few rounds of bug fix updates before I delve into adding any more features in 2016. I am sure you will agree Some quick requests:

@DVader : Can you send me a small stock level which shows your 100 houses scenario (maybe a custom house model) and I will see what the engine is doing, as the engine should batch common texture models during the lightmapping stage and reduce the draw calls significantly.

@Uman : I am surprised the entities are active and attacking you even before they are spawned. Can you send me a stock level (with any necessary custom model or scripts) showing this when I load and run so I can trace the bug, thanks.

@cybernescence : I do think the occluder needs a little more work. Despite Ravey's belief that making entities disappear after a certain distance is good, I think it's just putting people off using occlusion and I think the 'disappear after X distance' should perhaps be a different feature.

One thing I have noticed lately with the occluder is that when it is on a lot of simple animated objects lie doors and my on rusty pipe valve are effected by it no matter the distance.

It may be something done wrong with the models but I don't know what, but with the occluder on using a door script on them you open them and they animate fine, you close them and they animate closed, but as soon as you turn the camera or move away the object completely disappears, it's still there because the E prompt is still showing and when you hit E they animate and reappear.

If you turn off occlusion in the text tabs the models work perfectly.

I thought it was just my model but I've come across quite a few small animated models like this lately. Ones that come to mind are my own Rusty Pipe Valve (26028 on the store) and Valuable Assets 4 Door (animated) free models (23413, 23414, 23415 & 23416 on the store).

As I say, i'm not sure if it's the occluder or something wrong with the models, would be great if someone could take a look at the models and see if they can find out why this happens and let me know, that way if it's something wrong with the models I can try to find out how to avoid it in future.

it's a good feature it just needs a little bit of fine tuning when it handles the "scale" of the objects as it doesn't seem to be getting the correct result.
i.e. why does the bigger house disappear before the smaller house (same object but slightly smaller in scale)?
and why does the skyscraper disappear before the scaled up barrel?
it also needs to be a little more lenient on when it cuts smaller objects at higher settings (but a combination of scale fixing and better slider setting might fix that automatically)
all objects are static and stock (the barrel is adjusted to static, the rest are default as static)

Seems like Lee's answer is 'or not'.

To weigh in here, I was never clear on what kind of occlusion the engine was talking about until recently. I thought much like a previous user that it meant ambient occlusion. Turns out it is more of a culling system, at least in practice (not sure if this is by design or not).

While I've noticed issues at extreme distances with popping items and inconsistencies - my issues can be summed up as:

- Using transparencies. Small objects (and sometimes large) will flicker, delete, etc from close range when viewing through a window or transparency. I assume this is because the culler is thinking it's a solid wall and as such, not necessary for viewing. It made this scene:



Very difficult as the red siren, warning sign, and warning strips kept disappearing randomly. Interestingly it happened more often the CLOSER you were to it. You'd think it'd be the other way around. Disabling occlusion fixed this.

- viewing through transparent decals. Specifically using something like the lightray decal and viewing other decals behind it seems to cause the occluder to remove them.

it may already have been suggested but i think you're supposed to add notanoccluder = 1 to the fpe of any semi-transparent entities.

I'll give it a whirl tonight.

unless the setting is something other than notanoccluder = 1, it's not working.

knew i'd seen it somewhere
https://forum.game-guru.com/thread/213813
not tried it myself though, maybe it's from the FPSC settings.

Hi Lee,



email sent with necessaries.

Thanks

Peter

Was this ever fixed? Coming back to GameGuru after a while, I see more popping in and out of entities and shadows than in previous builds! It actually looks worse.

Not yet, but there hasn't been any update since the xmas build. The reason I posted about it, was that it seemed no one seemed to be getting these issues. I end up having to turn it off altogether. I even get better speeds with it disabled, which seems to suggest something is not right. It would be nice to have it working properly for the next update.

I agree. It looks like GC (garbage collector) does not work as expected.

3com

Hi Dvader. Definitely seeing this too, and it really doesn't seem to matter how I tweak settings, there is always noticeable pop up of models and shadows. This wasn't an issue in the previous build.

Whenever i turn to a side it loads all entities in the map...

I would say it still needs work. Ravey who implemented the first version seemed to be happy with a certain level of 'pop', but I myself find dialing the occlusion slider down to 10 to be insufficient as you also dial down all the performance benefits as well. The ideal of course is running around with no pop (except of course for small distant objects that are hardly noticed by the eye) and I think we have a way to go. The good news is that the underlying system is pretty good, able to process the occlusion queries on a second CPU thread at high speed, and we just need to change some threshold values so its less aggressive at higher values until the 'my building disappeared' issue goes away Mark it down as a bug for me to fix!