I'm away again (yes, I've got a lot of holiday to use up - I worked pretty solidly for the last year on Planet Coaster, only taking a few days off), and the couple of days that I was in the office last week I only briefly got a chance to look at this park. On my work Xeon (which is basically an i7) with a GTX 770 with 16gb of RAM the entire park is GPU bound. Even as more guests come in it continue to be GPU bound, although eventually at I think about the 8k guests level it becomes bound by the D3D submission thread, at which point the framerate was hovering around the 15 - 20fps mark.
Now to talk about why lowering the graphics doesn't really increase the framerate. You've all got powerful gpus, and lowering grapihcal options will do things like reduce the texture memory usage (it'll avoid loading higher resolution textures, which is a big help on slower hardware, but doesn't really increase performance that much on high end cards), and reduce shader complexity a little (again, your cards will chew through this). What it doesn't enormously do is reduce the geometric complexity of the scene. A game like Planet Coaster submits vast amounts of geometry to be rendered (many times that of most titles - including "far better looking" titles like Battlefield / Call of Duty). This arises from two main issues - one is that it is very costly to calculate whether individual pieces are visible or not. We do standard frustum culling to remove objects that are outside the view, but more detailed occlusion culling is just too expensive to perform on hundreds of thousands of objects. Games with pre-authored environments are able to bake out occlusion data in advance, and end up doing dynamic calculations on very few "dynamic" objects. Everything in Planet Coaster is dynamic. The second is how the geometry is submitted. When dealing with other games, 3d meshes (the buildings, the ground, etc. - basically any "model" in the game) are authored in the most optimal way for rendering - buildings aren't built out of individual pieces, or if they are they are processed offline to produce a mesh with the lowest triangle count. Imagine a (vastly simplified case of a) textured wall - you can either render two triangles for the whole wall, or two triangles per brick. Planet Coaster has to deal with things "brick by brick". Also, each brick has to be "drawn" (as in we make a call on the cpu asking the GPU to assign specific textures, shaders, and geometry and then draw it. This is a vastly simplified case and hey, I'm not a graphics programmer! But I do know what we actually do when rendering a scene in Planet Coaster is vastly more complicated than this - we are doing a lot of tricks to minimise the cpu and gpu cost of all of this. But we can't work miracles - Planet Coaster is an expensive game to render, and despite out continued efforts to optimise it we're not seeing any giant areas for optimisation. And this is what optimisation means - it isn't just "make the game run faster", it's about finding areas that are particularly slow (be it by mistakes in code, weird edge cases or just things being used in ways we never imagined) and re-writing them to make them faster. Which we will continue to do, but I can't just load up a park like this and see something which is taking twice as long as it should do. We have extensively optimised Planet Coaster up until this point (for the past two years in fact).
I'll need to do more profiling in a development build to give you more details on what is going on. Not wanting to criticise the park (it's a fantastic recreation of Disneyland), but things like you've got mountains of rock scenery pieces rather than terrain sculpting - the sheer object count for this park is really working against it in terms of performance.
We are continuing to optimise Planet Coaster - thanks very much for providing us with these examples. My performance recommendation is always to minimise object counts wherever possible - terrain can be rendered much more efficiently than thousands of rocks.
Cheers
Andy
