SO Performance problems?

[cpy]

Here we are again, big maps big performance problems. But there are many small maps? Wrong!

Spaced out is ONE BIG map that is separated by hidden black zone and pretty much all rocket interior and other planets are just one map separated in chunks so performance is horrible more you discover.

Could you at least separate them to different CPU threads so we can use more than 2 cores now? I think it would be very safe to separate outer space, and planets with their landed space ship areas.

Thanks!

[tnankie]

couple of (maybe) subtle points.

1) there isn't free pathing over sub map borders. This is a huge performance saver as pathfinding takes quite a bit of resources.

2) separate threads may help, but there is still the issue that all the clocks need to run at the same simulation tic rate or else time dilation/relativistic space travel (which may or may not be considered a bug/feature).

[babba]

The famous threading topic

This came to my mind

[The Plum Gate]

The only connecting feature that may be of relevant is the teleporters and any co-ordinated or concomitant research being done ( multiple like research stations ).

Separating all the maps into sim threads should be relatively easy - any of these time dependent coordinated exchanges or progress things could be done through a thread communication channel. 

[tnankie]

There is literally a relativistic problem with space travel if those are allowed to desync. you move to a small chunk that is less loaded and hence running faster time passes faster more resources are consumed. It's not just a problem with syncing transfers.

(Whereas shifting the entire navigation/path-finding system to a separate thread might be awesome!)

[Gurgel]

4 hours ago, cpy said:

Could you at least separate them to different CPU threads so we can use more than 2 cores now? I think it would be very safe to separate outer space, and planets with their landed space ship areas.

I expect the engine does not support that without major changes. It is sort-of obvious to do hence I think there must be a good reason for it not being done. On the other hand, pathing and pipes are naturally segmented with this design, so there is at least some improvement.

[cpy]

Try not to post things you dont understand tnankie.

Threading different worlds that are absolutely not connected via anything is not a problem to split threads. Pipes run in their own thread and you don't see problem with it and it runs in same world.

Game world would run in 1 thread per isolated world and you'd have let's say 8 worlds 8 threads and they all do just one tick... wait for rest, do one tick wait for rest. Or maybe even 10 ticks for all I care they are not connected they don't need that precise sync.

[EricS]

1 hour ago, cpy said:

Game world would run in 1 thread per isolated world and you'd have let's say 8 worlds 8 threads and they all do just one tick... wait for rest, do one tick wait for rest. Or maybe even 10 ticks for all I care they are not connected they don't need that precise sync.

 

Agreed, even at one sync per tick, you'd have minimal overhead from the sync.  Lock/unlock one shared value, a thread sleep, and a thread wake per thread per tick.  Just to be clear, that's one of each per thread, not just a wake per thread, and you wouldn't have the sleep/wake for the last thread to complete their work.

 

EDIT:  I can see the possibility that the engine doesn't allow for multiple simultaneous simulations, but that's about the only real hangup.  They're using Unity for ONI, right?  Considering that Unity now allows you to have separate rigid-body groupings to be run in separate threads, I'd be surprised if this were really an issue.

 

 

[cpy]

CIties skylines run on unity and that bastard can eat all cores on your CPU, so I don't think unity is the problem.

[MavadeK]

With my good old i5-3570 I have FPS issues only with extensive use of jet suits. Everything else runs smoothly

[Gurgel]

1 hour ago, cpy said:

Threading different worlds that are absolutely not connected via anything is not a problem to split threads. Pipes run in their own thread and you don't see problem with it and it runs in same world.

And even if things are connected, if you just sync rarely it is not a problem either. It is even less of a problem if you can predict movements, like in space travel. There is also one big sync point in place per cycle anyways and that will do nicely for almost all activities. If you (rarely) need to sync a teleport or rocket arrival between two worlds, that is _easy_. We are not talking one world running several cycles in front of another here. In fact, even syncing everything, say, once per second would probably still give almost the full performance benefits of having each map on a different CPU (as far as available).

46 minutes ago, EricS said:

EDIT:  I can see the possibility that the engine doesn't allow for multiple simultaneous simulations, but that's about the only real hangup.  They're using Unity for ONI, right?  Considering that Unity now allows you to have separate rigid-body groupings to be run in separate threads, I'd be surprised if this were really an issue.

It still needs major adjustments to the game system and maybe they are running on an older API version. Doable, but probably not urgent enough considering it works for most people and they are concentrating on content at the moment. There could be a "much more planets" or "much bigger planets" DLC in the future that does exactly this optimization.

BTW, what is a "rigid-body" grouping in Unity? Would that be a set of things like built tiles and the like?

[Khullag]

well don't expect world simulation to be multithreaded, since Klei started developing ONI in Unity long time ago, they used regular gameobject way of building the game and it's not very multithreading-friendly. now there's DOTS framework in Unity which is built ith multithreading in mind (and CPU-cache friendliness & etc) but it's still not fully done by Unity devs.

so Klei can:

- either rework the core of the ONI still using Unity's old gameobject way = a loooot of work and gazillion of potential bugs and crashes. plus it will affect both base game and DLC

- or rewrite the whole game into DOTS = even more work (like really writing game from scratch) and again it will affect both base game and DLC. plus even more bugs and crashes

just forget about "thread per world" idea. best we can expect is as someone above mentioned - if they move some systems like "pathfinding" to separate threads - this can happen.

[babba]

[EricS]

6 hours ago, Gurgel said:

BTW, what is a "rigid-body" grouping in Unity? Would that be a set of things like built tiles and the like?

Rigid-body groups in Unity would be for games like Kerbal Space Program or Besiege where you're creating vehicles by connecting multiple smaller parts together at connection points, and the physics simulation handles the interactions between the parts.  I don't think anything in ONI would use that type of physics simulation, as it's the kind of simulation where a force applied to one part will cause all the parts to move.

 

If you create a single rocket in KSP that consists of 500 parts, the physics simulation has to run in a single thread and you will be bottlenecked there.  If you create two rockets that consist of 250 parts each and aren't connected to each other, then each rocket can (but not necessarily run in a separate thread allowing the calculations to be spread across separate CPU cores, allowing the simulation to run faster, though not necessarily at twice the speed.

 

I mentioned that because a single group of rigid-body elements in physics simulations are one of the hardest things to split into separate threads because every part winds up affecting every other part.  The last time I looked into it a few years ago, there weren't any practical products actually splitting up connected groups, just academic research papers.

 

 

 

[Gurgel]

14 minutes ago, EricS said:

Rigid-body groups in Unity would be for games like Kerbal Space Program or Besiege where you're creating vehicles by connecting multiple smaller parts together at connection points, and the physics simulation handles the interactions between the parts.  I don't think anything in ONI would use that type of physics simulation, as it's the kind of simulation where a force applied to one part will cause all the parts to move.

If you create a single rocket in KSP that consists of 500 parts, the physics simulation has to run in a single thread and you will be bottlenecked there.  If you create two rockets that consist of 250 parts each and aren't connected to each other, then each rocket can (but not necessarily run in a separate thread allowing the calculations to be spread across separate CPU cores, allowing the simulation to run faster, though not necessarily at twice the speed.

I mentioned that because a single group of rigid-body elements in physics simulations are one of the hardest things to split into separate threads because every part winds up affecting every other part.  The last time I looked into it a few years ago, there weren't any practical products actually splitting up connected groups, just academic research papers.

Thanks. I also think ONI does not have that. Rockets only have a start and landing animation, in between that they are "not there as physical objects". And yes, that is an area where things get tricky. From a long time ago when I looked at this, I would think you can only parallelize this well if you go full finite-element simulation.

Now, there would be tons of areas where parallelization would be simple in ONI problem-wise. But I think the real killer is Dupe pathing and planning and all the rest may not be worth it performance-wise. If you have different maps, then you can, obviously, run the pathing completely separately for each one. That ONI does not seem to do that seems to indicate there is a problem with the engine or the API or the ONI code doing this. It is also quite possible Klei wants to get the content done first or that somebody is actually working on this in parallel but is not there yet. Before (single map) parallelizing this would be quite hard and may not have given good results anyways. 

[babba]

I experienced hundreds of crashes in Kerbal Space, on several different computer systems over several years. Kerbal is/was wonderful...but for me it was a giant game (physics) pc crash party, basically/effectively utilizing a single core. After the initial hype the game basically got dumped by the devs - My experience and opinion.

I am glad that Klei did not fully screw up the tech foundation of the game and is able to deliver the base game/dlc rework mix game at some point. IMHO messing with the map stuff delayed the dlc content delivery by 1 year, my opinion.

Over time Klei seems to regularly improve things, its a long process. Many game developments have been terminated by attempting multi threading in failed or incomplete tech attempts. Just needs the wrong tech person at some game dev helm and a few million dollars are down the drain and people get jobless and studios go bancrupt.

The dlc currently seems to have yet sold very little compared to the base game, to be a financial success it would have to sell 100x times more IMHO. Touch wood

Is Klei banking on multiple dlc`s, ONi2, end of the line or (in)game transactions  Interesting to see where it will all end. Praying for a more or less crash fresh ONi at some point ( crash free again...base game took +2 years for me to be finally crash free, just ahead of the first dlc access ).

It was so nice to experience and play a crash free ONi base game after all the game development years !

I am just hoping that the next possible ONi dlc builds on the existing (map) tech and existing game content, I would not like more years of crashes, delayed content delivery and incompatible savefiles.

Perhaps in 2-3 years also the hardware crysis will improve again and people will be able to buy faster cpu`s again at value prices then. There surely will be more Klei patch notes a la "we improved your dupe toilet water works by 17.38%" in the future.

On the CCP forum they have a thread where users are concerned about what happens with EvE Online if Iceland sinks?

"What happens with ONi if WW3 starts?" Important !!!!!!!!!!!!!!!!!!!!!!!!!!!! @minespatch

[minespatch]

1 hour ago, babba said:

"What happens with ONi if WW3 starts?" Important !!!!!!!!!!!!!!!!!!!!!!!!!!!! @minespatch

I'm not sure how to answer that.

[cpy]

You don't need to buy faster CPU, devs need to thread games more. I quit KSP so many times because of endgame lag I lost count. ONI too, I hate lag and I hate when game runs like crap and CPU usage is like 8%.

[marioespinho]

I don't really understand much about processing and such, so my question is: Can they do anything about it at this point? Could they "patch" the game to perform better than it does?

To be honest i also get a bit annoyed because after the third asteroid things start to run slower and there isn't much i can do about it. I understand that's how it is and i still enjoy my time, but i wish the game would run a bit better that it does, specially now that we aren't limited to a single asteroid and want/need? to go to the others sooner or later.

[babba]

9 hours ago, minespatch said:

I'm not sure how to answer that.

Art is welcome

1 hour ago, marioespinho said:

I don't really understand much about processing and such, so my question is: Can they do anything about it at this point? Could they "patch" the game to perform better than it does?

IMHO Klei will continue to improve the game speed over time. In my opinion they have talented tech staff and will do their best. Having the game running in one big map can have the advantage to analyze well where "most game speed is lost" and to see what brings the most speed optimization output, if worked on. I think threading and optimization attempts are always a tradeoff what the development software supports, staff technical skills and experience, if time budget is available in the development schedule, what hardware mix the players have and assessing, before working on threading, how long a game could be crashy if certain game tech things are tried to be changed.

I find it was a brave choice to rework the map system, in order to deliver content for it.

One of my first forum posts back then had been multi core complaints - Klei devs are using cpus with the game themself and know about the issues. However, customers always wants "everything"

I do wonder if the update today will make me play ONi again, it would be nice. I`m soooooooo ONi hungry ! World generation, regolith, big maps...Hoping for base game content in the dlc.

[cpy]

Solution is simple then. MORE DOTS!

Spoiler

Besides once game simulate atmospheric environment with pressure system, gas volume, liquid volume, all you can do at that point is pray and throw more cores at it. Until some magic guru coder makes some heavenly optimized algorithm for simulating atmospheric things. Thank god you don't have to calculate temperature from pressure too. You'd have like a 1FPM tops. (frames per minute).

[The Plum Gate]

A thing causing lag in this game is the large number of building animations all being told to key frame at the same time.

I noticed this when looking at zoomed out views, everything is chattering away in sync.

If they handed these draw calls off to separate threads, this might help.

Only a few things need true sync animations, mostly dealing with duplicants interaction.

---

Also, they could offload entire systems of simulatiom calculations to a vulkan, or openCL stack to reduce bottlenecked data return times from simd operations.

[Payamb]

I wish there was a flag to disable building animations and compare the frame rate. I’d be happy to trade off animations with more fps. 

[The Plum Gate]

18 minutes ago, Payamb said:

I wish there was a flag to disable building animations and compare the frame rate. I’d be happy to trade off animations with more fps. 

Yes, even some options on limiting the building animations would be nice ( like restricting building animation to only  displaying feedback status bars ). Batteries and other tanks come to mind.

[Sasza22]

Nobody is talking about the testing systems Klei adds to their games while in beta. They track a lot of things and slow down the game. I think there was a way to disable those but i don`t remember how. When they game goes live they will turn it off so performance should be better than now.

Besides that they actually added some multithreading a while ago after they released the base game. It was mostly for the pipes but it did improve performance a bit. If they did that then it is possible to patch some multithread logic in. But i`m pretty sure they won`t address performance until they are done with the content.