The only issue they should address in QoL2?

[hwfanatic]

I'm a dupe since August 2017, and I've played ONI with a friend at his place for a long time. I've seen the game grow and become better and more complex over time. I've become addicted to ONI and lost countless hours of sleep because of it. Needless to say: I love it.

The only issue I currently have with the game is the absolutely, unbearably abysmal performance beyond the first cycle. I start the game at 60 FPS, watching it gradually decrease to 30 FPS at cycle 450, 15 FPS at cycle 900, etc. You know there is something wrong with the code when the CPU and GPU utilization doesn't even go above ~10%*.

So if there is anything, anything at all you guys at Klei really need to work on in the QoL2 update, that would be the performance optimization. At this stage, I don't see a point in releasing an update for any other reason.

 

What are your gripes?

 

*) I've also upgraded my PC in the meantime with no apparent change in performance.

 

EDIT:

Prior to posting this topic, I've taken every possible step to reduce the amount of calculations: from limited excavations, to making only a single path to all destinations, to storing a single element per compactor, to having only 12 dupes per base. I've also upgraded my CPU+MB+RAM considerably.

I've gone above and beyond my duty as a player. I feel like I've done my part. Now it's time for Klei to do theirs. I've never even reached cycle 1000 because I just can't be bothered with all the lag. Hopefully this will change with QoL2, because it would be a shame if I had to stop enjoying ONI just because the code is cumbersome. I'd take simplified calculations any day over lag.

[KittenIsAGeek]

Part of the performance issue is the extra code to help debug problems.  This will go away once ONI enters production rather than pre-release.  

However, ONI is a game that does a LOT of internal calculations.  The graphics are, by modern systems, very simplistic and hardly using your card at all.  Most of the game calculation time is spent doing calculations inside your CPU.  Each cell with gas, for example, calculates whether or not there's a shift in pressure with its neighbors, a shift in temperature with its neighbors, AND a swap of elements with its neighbors.  If there is, then the changes are applied and moves to the next cell in the sequence.  Each liquid tile has the same calculations done.  Solid, un-dug tiles are less intensive as they only check if there are thermal transfers that need to be done.  Then there are calculations for critter movement, calculations for dupe tasks, calculations for dupe movement, etc.  Since, currently, most of ONI is single-threaded, that means that only one processor is used to complete ALL the calculations.  If you have a CPU with 4 processors, that means you'll see a 25% continual load on your CPU, even though your FPS are dropping to, say, 15.

Finally, ONI doesn't calculate areas of the map you haven't discovered yet, so early in the game when most of your map is black, the game pretty much just ignores those areas.  You can prove this by pausing sometime early in a new game, say cycle 30, then turning on debug, and scrolling to other areas of the map.  You'll probably see fish swimming through air, or water above gasses.  Using the thermal view you'll also see hot and cold elements in direct proximity that haven't started to transfer their energy yet -- especially when a cold biome is slightly overlapped by the oil biome.

This is why as your game progresses, your FPS start to go down.  There's a lot more that I haven't discussed yet, but basically it means that ONI in its current state will run the almost the same on a dual-core Celeron as it will on an 8-core i7, provided their clock speeds are the same.

[Nitroturtle]

4 minutes ago, KittenIsAGeek said:

Part of the performance issue is the extra code to help debug problems.  This will go away once ONI enters production rather than pre-release.  

However, ONI is a game that does a LOT of internal calculations.  The graphics are, by modern systems, very simplistic and hardly using your card at all.  Most of the game calculation time is spent doing calculations inside your CPU.  Each cell with gas, for example, calculates whether or not there's a shift in pressure with its neighbors, a shift in temperature with its neighbors, AND a swap of elements with its neighbors.  If there is, then the changes are applied and moves to the next cell in the sequence.  Each liquid tile has the same calculations done.  Solid, un-dug tiles are less intensive as they only check if there are thermal transfers that need to be done.  Then there are calculations for critter movement, calculations for dupe tasks, calculations for dupe movement, etc.  Since, currently, most of ONI is single-threaded, that means that only one processor is used to complete ALL the calculations.  If you have a CPU with 4 processors, that means you'll see a 25% continual load on your CPU, even though your FPS are dropping to, say, 15.

Finally, ONI doesn't calculate areas of the map you haven't discovered yet, so early in the game when most of your map is black, the game pretty much just ignores those areas.  You can prove this by pausing sometime early in a new game, say cycle 30, then turning on debug, and scrolling to other areas of the map.  You'll probably see fish swimming through air, or water above gasses.  Using the thermal view you'll also see hot and cold elements in direct proximity that haven't started to transfer their energy yet -- especially when a cold biome is slightly overlapped by the oil biome.

This is why as your game progresses, your FPS start to go down.  There's a lot more that I haven't discussed yet, but basically it means that ONI in its current state will run the almost the same on a dual-core Celeron as it will on an 8-core i7, provided their clock speeds are the same.

From my experience, the two major things causing performance issue are pathing and materials.  I'm currently playing a 2000+ cycle base, with over half the map in a vacuum.  Performance unpaused on triple speed is 20-25 fps, which is playable, but obviously not ideal.  If I put all of my dupes on break and lock them in the main base, performance jumps to 50-60 fps.  So while temp and liquid/gas calcs might have some impact, none of that changes by locking the dupes in the base.  Same with automation, liquid/gas piping, shipping, etc.  This has led me to believe it's either pathing or materials (or a combination, as more materials cause more pathing calcs.  I've also eliminated all duplicate pathing routes, so my dupes only have one path to any location on my map.  My next step is to try to move as many materials as possible to a single location and then try locking that off and see if it helps.

[chemie]

I was building some liquid pipes on a 300 cycle base and dropped to 10 fps while they were building so there are many factors at play.

[Lawnmower Man]

7 minutes ago, Nitroturtle said:

[...] My next step is to try to move as many materials as possible to a single location and then try locking that off and see if it helps.

Perhaps it is sufficient to simply put all the materials of one element together so it doesn't have meaningful pathing choices for fetching it?

[Nitroturtle]

3 minutes ago, chemie said:

I was building some liquid pipes on a 300 cycle base and dropped to 10 fps while they were building so there are many factors at play.

Yeah there's definitely some stuttering any time pipes are changed, which obviously due to piping calculations.

 

2 minutes ago, Lawnmower Man said:

Perhaps it is sufficient to simply put all the materials of one element together so it doesn't have meaningful pathing choices for fetching it?

Yeah I'm doing that as well, it just takes forever.  I have never had a storage area setup in my base and instead use a limited number of general sweep-only compactors that I empty as needed.

[KittenIsAGeek]

21 minutes ago, Nitroturtle said:

From my experience, the two major things causing performance issue are pathing and materials.  I'm currently playing a 2000+ cycle base, with over half the map in a vacuum. 

I highlighted an important part.  Large areas in vacuum will not be doing any calculations.  If, on the other hand, you had large regions with mixes of low pressure gasses (which I've seen in many newbie bases), your results would be vastly different.  Additionally, if you used the sandbox tool to clean the floor of debris, you would probably improve your performance as much as locking your dupes inside your base does.

Basically, ONI does a LOT of calculating.  If you can limit how much calculating is done, you improve performance.

[Nitroturtle]

Yeah I'm not sure how it would compare if those areas were filled with gas.  They were previously filled with tiles, and I didn't see much difference by making them vacuum instead.

[KittenIsAGeek]

7 minutes ago, Nitroturtle said:

Yeah I'm not sure how it would compare if those areas were filled with gas.  They were previously filled with tiles, and I didn't see much difference by making them vacuum instead.

Solid tiles only calculate heat transfer.  Most biomes are rather uniform in their temperature distribution until you start doing something with them, so there isn't much calculating done.  That's different from debris, since a pile of debris will be multiple elements with multiple thermal properties all at the same location.  They'll undergo continual thermal calculations as their temperatures slowly homogenize.  This is why large banks of storage bins can also cause problems.

Spoiler

The stored elements will be continually interacting thermally with the storage bin until temperatures settle within a threshold where thermal transfers can no longer take place.

[MorsDux]

1 hour ago, KittenIsAGeek said:

Solid tiles only calculate heat transfer.  Most biomes are rather uniform in their temperature distribution until you start doing something with them, so there isn't much calculating done.  That's different from debris, since a pile of debris will be multiple elements with multiple thermal properties all at the same location.  They'll undergo continual thermal calculations as their temperatures slowly homogenize.  This is why large banks of storage bins can also cause problems.

  Hide contents

The stored elements will be continually interacting thermally with the storage bin until temperatures settle within a threshold where thermal transfers can no longer take place.

that is why you are better off storing only 1 element type / container for the majority of your containers.

[KittenIsAGeek]

Yeah, @MorsDux,I picked an especially bad storage unit as an example. 

[avc15]

Something you should be aware of, in QoL, Klei factored gas & liquid piping systems into their own separate threads. That might not seem like a huge deal but it will really have a huge effect on bases that are several thousand cycles old. Each new layer (!) massively increases simulation complexity mostly because of heat transfer mechanics.

I wouldn't be surprised if we see more aspects put into their own threads, such as pathing. But here's the point - if you disable logging, or wait until the update lands in stable branch, QoL performs magnitudes better with old bases than expressive did.

[Guest]

6 hours ago, KittenIsAGeek said:

Finally, ONI doesn't calculate areas of the map you haven't discovered yet, so early in the game when most of your map is black, the game pretty much just ignores those areas.  You can prove this by pausing sometime early in a new game, say cycle 30, then turning on debug, and scrolling to other areas of the map.  You'll probably see fish swimming through air, or water above gasses.  Using the thermal view you'll also see hot and cold elements in direct proximity that haven't started to transfer their energy yet -- especially when a cold biome is slightly overlapped by the oil biome.

This has not been my experience, unless I am missing something. Examples of heat calculations happening behind the fog of war that I have seen are meteor impacts and the neutronium base of geysers/vents/volcanoes. When I expose the space biome around cycle 200, I can see the heat from impacts that started at the beginning of the game, diffusing down to the top of the biomes. The neutronium base of vents pulls heat from their surroundings. I have discovered vents after several hundred cycles and they have already reduced the temp of their surroundings by several degrees. I have always assumed that if the game is calculating heat behind the FoW in these instances. it would be doing it for all tiles behind the FoW.

Also, I just started a new game and manually moved a dupe around the map to expose the entire map, and my game still played at 60 fps for several cycles. 

6 hours ago, Nitroturtle said:

From my experience, the two major things causing performance issue are pathing and materials

This is more inline with my game experience. Pathing much more so than materials.Reloading save games also has a performance impact. 

[Oni Noob]

The biggest one they need to resolve is they must allow plastic ladders to replace the old ladders

[cblack]

21 hours ago, Nitroturtle said:

My next step is to try to move as many materials as possible to a single location and then try locking that off and see if it helps.

Let us know how this turns out.  I'm a the point where I'm hesitant to do anything else in my game because the FPS is so bad.

[Nitroturtle]

3 hours ago, cblack said:

Let us know how this turns out.  I'm a the point where I'm hesitant to do anything else in my game because the FPS is so bad.

Before even bothering with it, I decided to load up the game in debug and instead just delete everything.  I saw a little improvement, but not as much as I'd hoped.  Really each thing in my quest for better performance has helped a little, and overall the base is playable though still usually below 30 fps.  It doesn't help that I added 5 more dupes either, but whatever.  I was planning to start a new base yesterday when I mistakenly thought the preview would be available.  At this point, I'm starting to lose interest in the current base as there's not much left to do at all.

[RonEmpire]

The game gets really bad over time, and its not related to increase dupe count or critters count.  I keep my critters all wild.
I really can't understand what the issue is -  it just gets really bad  fps and lags - and the only thing I can think of is the actual reports accumulating or a possible memory leak of some sort that impacts performance.

Its not related to pathing to find objects as I have them sweeping everything on the map and its now centralized by the storage unit. on the ground.    Even at times, where they're idle and have absolutely nothing to do - the game has a bad fps.

It slowly (very slowly) gets worst per cycle.   Uncovering the map shouldn't lag the game that bad.     I'm still scratching my head trying to understand the game performance issue.


I couldn't play my 3600+ cycle game anymore - it got so bad in lag.     I restarted a new map seed  and trying to just minimize use of automation logics this time around.    not taming any critters and keeping them all wild.    reduce digging everything up and just minimize  all the debris and keeping everything in  a central spot so they're not having to path all over the map- cut down on anything they need to fetch etc.  -  its great in the early part of the game.  im enjoying the low fps but  as the game goes by  even with a self sustaining base.  i'm noticing the game performance difference changing over per cycle.     but my base hasn't changed much.   maybe  the rocks and shove voles are doing something up in space area that i'm not seeing.  or something else is going on in the molten biome.  no idea but its something over time causing slight performance.  

now that I have FPS counter running all the time, i'm a bit more attentive to the performance issues.



I had a theory to test out- where I would take my 3000+ cycle game and go to sandbox enabled and just delete everything.  and then compare it to a cycle 1 game with everything deleted to see what the difference is.  (besides save lagging- since ALL reports are saving- which is the major source of lag during auto save)

But the game crashes a lot and hangs, when I even try to start using the delete paint.  BlackHole crash report.    It's pretty bad when you barely can do anything late game.

Here's another thing that comes to mind.   with 3000+ close to 4000cycles, its like 2-3 months of game play basically (almost a full time job just playing the game).     And obviously devs, aren't actually playing their games to this cycle count because it would take away from their actual job in working on the game-   I really don't think they test the game from actually playing it- at late game level.

 

 

[Exoros]

I would like to see an improvement in Power control station(never used it upto today).

[KittenIsAGeek]

58 minutes ago, Exoros said:

I would like to see an improvement in Power control station(never used it upto today).

The PCS is pretty good already.  Yes, it does use some refined metals, but the rewards are well worth it.  Refined metals are no longer a limited resource on most maps, and the use per generator is fairly low.  It is especially useful when you either have a generator that runs almost continually OR you have a limited fuel supply.  

For example, a well built electrolyzer setup can power itself with the hydrogen it produces.  If you also tune up the hydrogen generator, you can often supply quite a bit of your base operations as well.  Or perhaps your nat gas geyser just went dormant and you haven't reached the oil biome yet.  Want to extend your gas supply until you get your boiler built?  Perfect time for a PCS.

 

[Craigjw]

Do you expect a game that has 2D graphics and not a shred of any real spangly graphics FX to put your graphics card to the test?  I would suggest that you either downgrade your graphics card or stop winging about the lack or graphics card mutilation.

[cblack]

4 hours ago, RonEmpire said:

It slowly (very slowly) gets worst per cycle.   Uncovering the map shouldn't lag the game that bad.     I'm still scratching my head trying to understand the game performance issue.

I think the #1 thing that worsens performance is revealing more of the map, as it just gives the game more to simulate.  The problem is, without revealing more, you're just stuck in the middle with no geysers, and not much to do.

4 hours ago, RonEmpire said:

Here's another thing that comes to mind.   with 3000+ close to 4000cycles, its like 2-3 months of game play basically (almost a full time job just playing the game).     And obviously devs, aren't actually playing their games to this cycle count because it would take away from their actual job in working on the game-   I really don't think they test the game from actually playing it- at late game level.

In other games like this, e.g. Factorio, I know the devs load up massive bases (I suspect created by players) and use that to stress test their game.  I suspect the ONI devs do the same, or are at least planning on it.  Or rather, I hope they are...

Perhaps Nitroturtle could provide them with a stress testing save?

[Lawnmower Man]

1 hour ago, Craigjw said:

Do you expect a game that has 2D graphics and not a shred of any real spangly graphics FX to put your graphics card to the test?  I would suggest that you either downgrade your graphics card or stop winging about the lack or graphics card mutilation.

I feel that they could use CUDA or similar to do most of the physics on the GPU.  Thermal and fluid diffusion calculations feel well-matched to shader pipelines, but I'm not an expert on those, so just guessing.  Maybe they will do a big perf pass when more game details are finalized and try something like this.

[avc15]

On 1/24/2019 at 9:01 PM, nonoxyl said:

This has not been my experience, unless I am missing something. Examples of heat calculations happening behind the fog of war that I have seen are meteor impacts and the neutronium base of geysers/vents/volcanoes.

Shortened context a bit here - a few things. First, fog of war is a gradient, and it's not really clear where the active map ends and the "simulated" map begins.

Undiscovered areas aren't just frozen, but they do appear to be "simulated" - some kind of simplified set of computations. But, the "simulation" seems to begin a fair way past the fog of war. So, that way tiles you can actually see behave like there's something on the other side.

This is what we've pieced together from all the various things klei have said about the fog of war, and every time they've mentioned such a "simulation", how it always seemed to apply to things that are out of view.

[The Plum Gate]

This is the kind of game that could use the vector math capabilities of a GPU for at least some calculations - and they're using unity's engine ( which got some Vulcan love love not to long ago).

My impressions of FPS are a bit odd, I have steam FPS counter and it never dips below 50 since I play with radeon chill enabled for 50 to 70fps. I don't usually see what the upper end of the fps count is with it off. Im playing on a 3440×1440 panel and the game runs smoothly until I start panning around. And then there's this odd hitching a cogging that goes on ( but oddly no drop below 50 fps ). This usually starts after much fog of war reveal.

Vega 64 strix is a nice card, wish AMD would get ahead on its drivers ...its always something with the vega cards, always.

I haven't paid much attention to what's happening with threading on the processor, but the GPU has always been low utilization. It doesn't leave the first two low power states. And the game looks like it was optimized for 2 gig cards on account of the 1.9 gig of vram it reports when running.

[avc15]

18 minutes ago, The Plum Gate said:

This is the kind of game that could use the vector math capabilities of a GPU for at least some calculations - and they're using unity's engine ( which got some Vulcan love love not to long ago).

This is absolutely true but it's another reentrance and/or (at least) syncing problem the same as multithreading.

We got 2 new threads with major tasks put onto their own cores in the newest unstable branch but most people haven't seen it do work yet because of debugging. And there's no indication yet whether they have plans for additional threads.

Let's see how it plays when this version goes into live. For me, it seems like a huge improvement.