Jump to content

The game needs optimization badly.


link12313

Recommended Posts

My computer can run star citizen better then this game in it's current state. It runs all my cpu and gpu cores at max and strains this system harder then any other game I own. Here are my specs. The game has the detail level of something from the mid 2000's right now. So there is no reason for it to overload a Ryzen 5 and Nvidia 1660.

DxDiag.txt

Link to comment
Share on other sites

I agree, however I am allowing for the "Its beta" arguments to be valid for now.

 

What I don't agree with is bullsmacking nonsense like this effluent lifted straight from their own FAQ:

 

Quote

Performance (Expected FPS (e.g. <60 is ok…)
This is not a first person shoot-em-up game.  A high FPS rate is not needed.  Anything over about 30 FPS isn’t going to be visible to your eye (Movie theaters project at 24 FPS).  Issues like “Pending Operations” and server lag are going to be a much larger issue for you than frame rate.

https://docs.google.com/document/d/1qzsYBxgM0_bXrecBhfJJ__4n_43ZCrIY5r-X5fskKZo/edit#heading=h.s18k14uker8h

 

 

That has to be the worst cop-out, justifying ignoring performance issues in a game. It shows their ignorance like no other.

 

- Movies and TV are a low frame rate, because people are sitting and only watching it. They are not in control of it. Its easier on the eyes with the pre-defined motion and scenes. Frames blend from one to another in various technologies across film and digital, to where the issue of being low-rate is not "perceived" as being "terrible".

 

- Games are in the hands of the controller. The moment you drop it to a pathetic 30fps, then all manner of discomfort is created. It lags, its unresponsive, and being in control of the direction of action is hindered.

 

- Anyone who "claims" that you don't see above 30fps, is a blind fool. And those who say you don't see more than 60fps "so there is no point to a 144hz monitor" are clearly idiots who have never played a single game on a 144hz monitor at 90+ fps.
 

- Arguably, DU IS a First Person Shoot-em-up game the moment they added 'tools' in hand you have to aim and use ad nauseum, and 'weapons' on ships that you need to 'aim' and blow up other people in a 'PVP' setting. So that excuse that DU isn't an FPS, making it acceptable to have piss-poor frame rate performance, is just downright apalling.

 

- Even a top-down RTS with low frame rate sucks. So where is the rationalization here?

 

Anyhow...... one can be hopeful they pull head from the dark crevasse and will actually improve the abysmal performance this game has over the course of the beta period. If not, then I can see many, many subscriptions getting cancelled.

Link to comment
Share on other sites

1 hour ago, link12313 said:

My computer can run star citizen better then this game in it's current state. It runs all my cpu and gpu cores at max and strains this system harder then any other game I own. Here are my specs. The game has the detail level of something from the mid 2000's right now. So there is no reason for it to overload a Ryzen 5 and Nvidia 1660.

DxDiag.txtUnavailable

You cant really compare the two games though, whilst SC is visually impressive all of the assets are fixed and locally stored, DU's main overhead is caused by the sheer scale of the game (single shard) and the fact all the assets are player made, meaning that the game has to cache / render on an going basis.  Two VERY different games from that perspective.  Just because a game looks impressive, doesnt mean it should be more PC hungry (something I always called the 'Witcher 3' argument).  Your concept that graphics is the only thing that effects performance is a bit flawed.

The good news is that optimisation is happening on an ongoing basis, the game is LIGHTYEARS better than alpha, and has also seen great strides since the hell hole that was full beta launch.

Link to comment
Share on other sites

16 minutes ago, Moosegun said:

You cant really compare the two games though, whilst SC is visually impressive all of the assets are fixed and locally stored, DU's main overhead is caused by the sheer scale of the game (single shard) and the fact all the assets are player made, meaning that the game has to cache / render on an going basis.  Two VERY different games from that perspective. 

Yep, very different requirements. Voxel-based games also tend to offload a lot more to the GPU, so even with simple graphics, it can be taxing in a way that SC will never be.

 

Static assets with physics are really well understood -- and extremely well optimized by GPUs. People have been working with static assets for decades; optimization techniques and hardware are highly evolved and baked into any commercial engine like SC's Amazon Lumberyard.

 

DU has to do a lot more math to represent objects of less detail because they are represented with voxels. Their collision and geometry is far more complex...plus they have to stream to your machine via network. 

 

It's a lot easier to make mistakes working at that low level of GPU/shader programming, even before networks come into play...so plenty of room for optimization! :D  

Link to comment
Share on other sites

12 hours ago, Frigidman said:

I agree, however I am allowing for the "Its beta" arguments to be valid for now.

 

What I don't agree with is bullsmacking nonsense like this effluent lifted straight from their own FAQ:

 

https://docs.google.com/document/d/1qzsYBxgM0_bXrecBhfJJ__4n_43ZCrIY5r-X5fskKZo/edit#heading=h.s18k14uker8h

 

 

That has to be the worst cop-out, justifying ignoring performance issues in a game. It shows their ignorance like no other.

 

- Movies and TV are a low frame rate, because people are sitting and only watching it. They are not in control of it. Its easier on the eyes with the pre-defined motion and scenes. Frames blend from one to another in various technologies across film and digital, to where the issue of being low-rate is not "perceived" as being "terrible".

 

- Games are in the hands of the controller. The moment you drop it to a pathetic 30fps, then all manner of discomfort is created. It lags, its unresponsive, and being in control of the direction of action is hindered.

 

- Anyone who "claims" that you don't see above 30fps, is a blind fool. And those who say you don't see more than 60fps "so there is no point to a 144hz monitor" are clearly idiots who have never played a single game on a 144hz monitor at 90+ fps.
 

- Arguably, DU IS a First Person Shoot-em-up game the moment they added 'tools' in hand you have to aim and use ad nauseum, and 'weapons' on ships that you need to 'aim' and blow up other people in a 'PVP' setting. So that excuse that DU isn't an FPS, making it acceptable to have piss-poor frame rate performance, is just downright apalling.

 

- Even a top-down RTS with low frame rate sucks. So where is the rationalization here?

 

Anyhow...... one can be hopeful they pull head from the dark crevasse and will actually improve the abysmal performance this game has over the course of the beta period. If not, then I can see many, many subscriptions getting cancelled.

Erm you do realise that is a community driven document, NOT their own FAQ lol  Make your 'ignorance like no other' comment seem a bit ironic tbh 

"This FAQ (Frequently Asked Questions) document is a volunteer driven community effort to address the most common questions raised in the game.  It is NOT a training manual, but rather a quick answer source of information."

Link to comment
Share on other sites

11 hours ago, Moosegun said:

DU's main overhead is caused by the sheer scale of the game (single shard)

This should only apply to the server, not the client.

  • Pure gameworld: KSP is much larger, without loading times. Eeloo, the outermost planet, has an apoapsis of 567,748 SU
  • Voxel planets: Space engineers and similar games also have voxel planets, although they are smaller, but they are multiplayer and can be mined down to the core (Space engineers). And also runs on older hardware. I was still playing space engiers with my old AMD Phenom II and a Readon HD 7850.
Link to comment
Share on other sites

21 minutes ago, runner78 said:

This should only apply to the server, not the client.

  • Pure gameworld: KSP is much larger, without loading times. Eeloo, the outermost planet, has an apoapsis of 567,748 SU
  • Voxel planets: Space engineers and similar games also have voxel planets, although they are smaller, but they are multiplayer and can be mined down to the core (Space engineers). And also runs on older hardware. I was still playing space engiers with my old AMD Phenom II and a Readon HD 7850.

These are not games with thousands of people on the same server though, yes this is server based but it effects the whole core game code. 

Were you playing SE with several thousand other players on the same server?  No you werent, in my experience SE turns to shit once you go multiplayer, kind of proving the point.

If you are saying making a game where you want thousands of players in the same space has NO effect on the client side coding........ then sorry, will have to disagree on that one

So to clarify - the sheer scale of the game in terms of size AND players

Link to comment
Share on other sites

3 minutes ago, Moosegun said:

If you are saying making a game where you want thousands of players in the same space has NO effect on the client side coding........ then sorry, will have to disagree on that one

The player should only know the players in the immediate vicinity, and every character looks the same here. Other MMOs have no problem displaying 100 players in one place with personalized characters. The client does not care whether there are players 5km away, the server does not send any information to the client and does not exist for him.

 

I can't quite understand where the bad performance of the markets comes from. Due to the frustum culling, only objects that are visible from the camera should be rendered and with occlusion culling objects that are obscured by others should also be ignored. But with DU the presence of other ships alone affects the performance, without them at all in the field of vision the camera are. And with GPU instancing you can reduce massive drow calls when displaying the same objects (engines, wings, windows, etc.)

 

One reason could be a netcode that is not suitable for MMOs. e.g. to sync every frame/tick of every player and ship with the server and also to wait until the server has sent everything. With a large number of players / ships, this would always lead to bad frame rates. I also hope that DU don't use rollback or other netcode techniques that have no place in MMOs.

Link to comment
Share on other sites

34 minutes ago, runner78 said:

The player should only know the players in the immediate vicinity, and every character looks the same here. Other MMOs have no problem displaying 100 players in one place with personalized characters. The client does not care whether there are players 5km away, the server does not send any information to the client and does not exist for him.

It isnt the characters that are the issue, it is the unique customer voxel creations that cause the issue. Other games with 100 player in one place have very little difference between each character and those difference are limited to a range of specific options and locally stored assets.  This game is dealing with hundred of unique player created constructions.

EVERY other 'MMO' has issues with this that use voxels building, infact most games struggle when you get more than a few player constructs in the same place (see Empyrion even SE etc).  No game has done voxels on this scale.  The different is that as the contructs are unique, so surely the game has to generate this object on the fly (or cross reference them with cache versions). You actually see this if you visit a market you have been to before and one you havent, i have very little issue returning to D3 market, it loads fine, it is my local market i visit all the time.  When i travel to other markets further away, that i dont visit, that is when I have some issue loading assets.  Even then it is generally not too bad if I dont approach too fast. Speed being the other big issue they need to cope with, as you can travel a long way very quickly in this game (5km is NOT far).

Link to comment
Share on other sites

10 minutes ago, Moosegun said:

It isnt the characters that are the issue, it is the unique customer voxel creations that cause the issue. Other games with 100 player in one place have very little difference between each character and those difference are limited to a range of specific options and locally stored assets.  This game is dealing with hundred of unique player created constructions.

As far as I know, DU using a mesh server and only sent the mesh object, not the voxel data. Except that GPU instancing is not possible here, these objects do not differ from other 3D objects. And even generating the voxel to mesh of a single object only needs to be done once and can be cached, not every frame. 

Modern graphics cards can handle thousands of draw calls (but also depends on the engine), 100-200 unique meshes should then still be easy to manage if placeable objects are batched and frustum and occlusion culling works properly. The terrain seems to work at least reasonably well as I have 30-40 FPS in my territory (but could be better). The terrain should also have a smaller voxel resolution (I estimate 1 meter)

Link to comment
Share on other sites

I can say performance has improved since the dark days of the prebeta beta.  My GPU went from 100% load 90% of the time to barely going over 85% load.   My frame rates are more consistent.  The server is far more stable, and pending operations and network errors and random crashes are a lot less frequent.  

 

To be honest NQ has done more in one month than most other game companies do in 6 months.  

 

 

Link to comment
Share on other sites

Yes, performance has improved. Anything else would have been the death of the game.

But to summarize the point runner78 is trying to make. DU being a single shard MMO, is purely a server problem. The client resource requirements only apply for what is shown on the client monitor. So when you think about it, if the server/network is struggling to deliver the construct mesh/voxels in time it should lead to less CPU/GPU not more on the client side. Simply because there would be less data to render.

 

Compared to other voxel games, the CPU and GPU usage is very high and the resulting graphic does not match. Here is an example of a modern voxel engine. And again remember that thousand of players, single shard etc. is (or at least should be) a server problem.

 

Link to comment
Share on other sites

17 hours ago, Frigidman said:

Anyone who "claims" that you don't see above 30fps, is a blind fool. And those who say you don't see more than 60fps "so there is no point to a 144hz monitor" are clearly idiots who have never played a single game on a 144hz monitor at 90+ fps.

I studied Digital Multimedia in college and the topic you are talking about is a bit more complicated than you seem to think it is.

 

The idea that people do "do not see more than 60FPS" is actually a fact (the actual frame rate humans cannot perceive is slightly lower than that, but 60FPS is nice round number), but you seem to be confusing "seeing more than 60FPS" with "recognizing 60FPS".

 

When we say people cannot see higher than 60FPS, we are saying there are frames flashing by so fast in the video that the human mind cannot register the data fast enough in individual frames and the information is lost. This was tested and proven in a well-known experiment. Full black frames (static pictures of nothing but black) were inserted into a video of full white frames. People were asked to watch the video and identify when the full black frames appeared. At a framerate somewhere in the 50s, all participants were unable to accurately identify where the black frames were in the video--they appeared and disappeared so fast that the human mind did not register them among the sea of white frames. So, yes, it is an established fact that humans cannot see more than 60 frames per second. There is no physically possible way with the limitations of the human body to read data on a screen fast enough to register information from one solid frame when the frame shows at a rate faster than 60FPS--there needs to be some kind of coherence or context for the frame to actually register as part of a set of frames viewed together.

 

That said, you are confusing seeing 60FPS with recognizing 60FPS, which are two different things. While humans cannot distinguish data from individual frames at 60FPS, if we placed two videos side by side and played them at different framerates, of course you can tell there is a difference--the difference is happening often enough that our brains can register it and tell us. But here is the thing, there is ANOTHER well known experiment that tells us we actually do not recognize the difference between the framerates compared to each other at different times. Recognizing the framerate difference and identifying the framerate difference are two different things. Just like before, if we put two videos side by side and asked a person to tell us which was playing at a slower framerate, we can usually expect a correct answer--humans can perceive a difference in framerates with direct comparisons. But, if we change up the experiment and show the videos at different times while not side by side, humans cannot accurate tell which video is playing at a faster or slower pace--we know there is a difference, but we do not know what the difference is without the other video being present to directly compare. In other words, without direct side-by-side comparison, we cannot tell if different framerates are faster or slower after certain speeds, we can only recognize them as different.

 

All of that said, when game developers make animations for video games, they develop those animations at a specific frame rate, usually 30FPS or 60FPS. So, no matter what you do, you cannot actually make that framerate faster than the developers made the animation. There is "interpolation" technology out there that "increases framerates", but all that really does is insert static image copies in between frames. Basically, instead of having 1 static frame showing for 1 second, interpolation copies that frame 9 times and speeds up how fast the frames show, so now you have 10 identical frames showing over the duration of 1 second. All that is doing is inserting more visual data into the video without changing the physical difference--you still get the same, unchanged image playing over 1 second. Although it is important to note that our brains recognize the difference between seeing 1 static over 1 second compared to seeing 10 static images over 1 one second. While it is possible to interpolate frames into an animation between keyframes using advanced software that dynamically redraws frames (this is how we get HD remakes of video games), this is a process that cannot be done in real time as we play the game. So, yeah, if the game was developed at 30FPS, you are not getting better graphics by interpolating frame copies, you are just making your computer much work harder to create a change that you recognize as different.

Link to comment
Share on other sites

3 hours ago, Sparklepuss said:

 

That said, you are confusing seeing 60FPS with recognizing 60FPS, which are two different things. While humans cannot distinguish data from individual frames at 60FPS, if we placed two videos side by side and played them at different framerates, of course you can tell there is a difference--the difference is happening often enough that our brains can register it and tell us. But here is the thing, there is ANOTHER well known experiment that tells us we actually do not recognize the difference between the framerates compared to each other at different times. Recognizing the framerate difference and identifying the framerate difference are two different things. Just like before, if we put two videos side by side and asked a person to tell us which was playing at a slower framerate, we can usually expect a correct answer--humans can perceive a difference in framerates with direct comparisons. But, if we change up the experiment and show the videos at different times while not side by side, humans cannot accurate tell which video is playing at a faster or slower pace--we know there is a difference, but we do not know what the difference is without the other video being present to directly compare. In other words, without direct side-by-side comparison, we cannot tell if different framerates are faster or slower after certain speeds, we can only recognize them as different.

 

Thats all on videos. You don't have additional factor of player controlling what is happening on the screen + muscle memory + reaction and prediction of movements. As far as i know there are (not really scientific but good enough) tests which shows that higher frame-rate is easier on our brain - easier to predict what will happen, easier to track movements, etc. Thats one thing.

Now animation - you are partially correct - depending on which animation technique will be used - this what you said was especially true in 2D world. Fortunately animation technology went ahead. Especially with meshes with skeletal animations  as much frames can your machine pump, as many different frame there will be between two different "key" - so set by animator - frames. 

Link to comment
Share on other sites

3 hours ago, Sparklepuss said:

When we say people cannot see higher than 60FPS

Try waving your mouse around on a 60fps monitor compared to a 120 or 144 fps monitor. 60 fps, clear gaps between draws. 120/144? Much smoother, smaller gaps.

And that only takes a few seconds to see and only requires an OS install.

 

For a better understanding, see this "test-ufo" site. Or the top level. Take a look at the various things there (if your monitor can support them). And then ask if you still believe that the human eye cannot see more than 60fps and notice that more than 60fps is smoother.

 

For a different comparison, take the fastest human sprinter. 10m/s, 100m in 10s. At 60fps, that would be 1 frame every 16 centimeters. It's quite obvious eyes don't work on an fps basis.

 

Or driving on the highway at 80km/h. If in a game, it would be 1 frame every ~.37m, yet looking out the window and one can focus on details perfectly. Try doing that in a game.

Link to comment
Share on other sites

impossible to play for me. just crashed into the ground because screen FREEZE LAGS. im almost out of money i have no vehicle left i have to walk 5 million miles to buy scrap and walk another 5 million to the destroyed ship. NICE. network errors every 30mins. nobody gives me a ride. so much fuuuuun

Link to comment
Share on other sites

The human eye is capable of sensing hundreds of FPS. This fantasy that the human eye can not detect much more then 60fps is not based in science. Every military on the face of the earth knows this. Every eye doctor will tell you the same. As soon as tech allows it you will see 200-400 fps standards.

Link to comment
Share on other sites

On 9/26/2020 at 11:38 AM, runner78 said:

As far as I know, DU using a mesh server and only sent the mesh object, not the voxel data. Except that GPU instancing is not possible here, these objects do not differ from other 3D objects. And even generating the voxel to mesh of a single object only needs to be done once and can be cached, not every frame. 

Modern graphics cards can handle thousands of draw calls (but also depends on the engine), 100-200 unique meshes should then still be easy to manage if placeable objects are batched and frustum and occlusion culling works properly. The terrain seems to work at least reasonably well as I have 30-40 FPS in my territory (but could be better). The terrain should also have a smaller voxel resolution (I estimate 1 meter)

Cheers, some really interesting stuff i had to go read up on lol.  I do see what you are saying but why is it that when they make server side only updates, such as changes to industry, it made a big difference to my machines performance / fps. Genuinely interested.

Link to comment
Share on other sites

I am not an expert.

yet it seems so damn easy to understand that DU's graphics are inferior to that of any contemporary game because the other games are all pre-built 3D models, while the voxel doesn't work that way.

the game is tough because the possibilities offered are gigantic.
At least when it comes to creating with the voxel. You really have no idea what you can do with the voxel, if you did you would immediately understand why there is such a difference.

And anyway DU has great graphics

 

Need only a lot of optimization, ok. Will arrive. We are in beta. Keep calm and patience.

Link to comment
Share on other sites

Try playing VR at 60fps.  Barftastic.

70 FPS is considered an absolute minimum. 
90 FPS is needed to satisfy most people sensitive to motion. 
some say that it’s only around the 120fps-150fps mark that things start to feel “truly real”

Link to comment
Share on other sites

There are three aspects to fps that are equally important. Rate, latency and jitter.

 

- Rate is obvious, how many frames per second is shown.

- Latency is the delay from user input until the result is shown on the display. This goes hand in hand with fps, but not 100%. You could theoretically have 240fps and 1 second latency.

- Jitter is how even the distribution of all the frames per second is delivered to the monitor.

 

DU appears to have a lot of jitter, making the FPS feel even lower that what it is. This could be improved by increasing the frame buffer, since latency is not critical in this game.

And on a more technical note, having jitter issues is often a strong indication of un-optimizaed 3D rendering pipelines.

 

Link to comment
Share on other sites

On 9/26/2020 at 10:52 AM, Moosegun said:

These are not games with thousands of people on the same server though, yes this is server based but it effects the whole core game code. 

Were you playing SE with several thousand other players on the same server?  No you werent, in my experience SE turns to shit once you go multiplayer, kind of proving the point.

If you are saying making a game where you want thousands of players in the same space has NO effect on the client side coding........ then sorry, will have to disagree on that one

So to clarify - the sheer scale of the game in terms of size AND players

Good point, SE only needs two players with a large ship to be able to mess up a server beyond repair

 

Link to comment
Share on other sites

10 hours ago, Moosegun said:

Cheers, some really interesting stuff i had to go read up on lol.  I do see what you are saying but why is it that when they make server side only updates, such as changes to industry, it made a big difference to my machines performance / fps. Genuinely interested.

In such a case the problem could be the networking, too many synch points in a frame, where the client is waiting for the answer / download of the data, or poor client code to apply the data.

Link to comment
Share on other sites

Just now, runner78 said:

In such a case the problem could be the networking, too many synch points in a frame, where the client is waiting for the answer / download of the data, or poor client code to apply the data.

So it is possible for server side changes to effect client side performance? 

Link to comment
Share on other sites

39 minutes ago, Moosegun said:

So it is possible for server side changes to effect client side performance? 

Yes, if some network operations in the client are not frame-independent. Or too much data is sent from the server to the client and the client network thread is busy. But that is only a guess, but these are all problems that have a lot of optimization potential.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...