Jump to content
Sign in to follow this  
Chud Patrol

Dev report

Recommended Posts

GPU information is fine and dandy, but when are we getting word on Vikendi coming to live? What about the update that is allegedly coming in January? I’d like more information on what’s going on, other then hardware and network “potential” fixes. 

  • Like 3

Share this post


Link to post
Share on other sites
38 minutes ago, Chud Patrol said:

GPU information is fine and dandy, but when are we getting word on Vikendi coming to live? What about the update that is allegedly coming in January? I’d like more information on what’s going on, other then hardware and network “potential” fixes. 

 

It's a dev report... What did you expect?

 

I appreciate the level of technical detail in the updates, I'd rather have stable gameplay and a higher FPS than live Vikendi.

 

What's wrong with just playing Vikendi on the PTS for now?

  • Like 7
  • Thanks 3

Share this post


Link to post
Share on other sites

What I don’t understand is they say 1080p is the most common resolution but it doesn’t seem like they are going to give the option to choose that... seems odd.

Share this post


Link to post
Share on other sites
11 minutes ago, beavykins said:

What I don’t understand is they say 1080p is the most common resolution but it doesn’t seem like they are going to give the option to choose that... seems odd.

I don't get it either, 1440p minimum except most people are running 1080p TVs...

 

I myself have a 4k TV but I'm running an original Xbox :(

Edited by Baal0r

Share this post


Link to post
Share on other sites
1 hour ago, Baal0r said:

I don't get it either, 1440p minimum except most people are running 1080p TVs...

 

I myself have a 4k TV but I'm running an original Xbox :(

 

Funny, I have the x running on a 1080p tv.

 

Here’s to hoping the “performance mode” gets another update before going live. Some sort of increased frame rate at 1080 would be nice.

Share this post


Link to post
Share on other sites

1440p is often referred to as 2k. There are numerous resolutions that people call 2k, and this is one. It sounds like they have made improvements of about 20-40%... which will be anywhere from 6 - 12 fps. 
They are unwilling to allow a setting on the Xbox One X that isn't higher def than the OG or S can do. That much is obvious... because with the fps gained by 1440p, it should be a bit better with 1080p. My guess is they are between a rock and a hard place on this because they feel they HAVE to make it run at a resolution higher than 1080p yet us Xbox One X gamers are demanding better FPS. 

The solution is a simple one. Games have done this for years for various reasons. Add a hidden dev menu that allows manual selection of various resolutions and graphical options as well as a frame counter and ability to disable or set vsync to what we want. Leak the button combination to get to this menu. Everyone will be happy this way. We can adjust our settings to our liking and you can claim the game runs higher than 1080p at over 30fps and you're being very honest. 

Some other things to consider.... give us a "forced model" mode. People only really wear custom clothes for the lobby when people will see them. The rest of the time they couldn't care less. So once the players get in the plane, have it wipe the custom clothing and player models from memory and use a single one for all other players. 

Give us an alternate fire/explosion/smoke animation. Something generic that achieves the same goal but isn't so costly to the performance. 

  • Like 1

Share this post


Link to post
Share on other sites
10 hours ago, DR. Intellect said:

1440p is often referred to as 2k. There are numerous resolutions that people call 2k, and this is one. It sounds like they have made improvements of about 20-40%... which will be anywhere from 6 - 12 fps. 
They are unwilling to allow a setting on the Xbox One X that isn't higher def than the OG or S can do. That much is obvious... because with the fps gained by 1440p, it should be a bit better with 1080p. My guess is they are between a rock and a hard place on this because they feel they HAVE to make it run at a resolution higher than 1080p yet us Xbox One X gamers are demanding better FPS. 

The solution is a simple one. Games have done this for years for various reasons. Add a hidden dev menu that allows manual selection of various resolutions and graphical options as well as a frame counter and ability to disable or set vsync to what we want. Leak the button combination to get to this menu. Everyone will be happy this way. We can adjust our settings to our liking and you can claim the game runs higher than 1080p at over 30fps and you're being very honest. 

Some other things to consider.... give us a "forced model" mode. People only really wear custom clothes for the lobby when people will see them. The rest of the time they couldn't care less. So once the players get in the plane, have it wipe the custom clothing and player models from memory and use a single one for all other players. 

Give us an alternate fire/explosion/smoke animation. Something generic that achieves the same goal but isn't so costly to the performance. 

Thing is people are acting like graphics are the issue when clearly that's only part of the problem.

 

PTS runs fine most of the time but they still have the issue that the GPU is ticking along nicely but multiple squads get in the same area and the frame rate tanks.

 

The other issue I don't understand, why does Unreal engine not instance cull automatically as the fov changes?

 

Surely instance bounds checking only happens within the view frustum so you'd expect trees and stuff outside of that to not be drawn?

 

(For scoping in for example).

Anyway, point is there's still a lot of engine work to do that a few graphics sliders aren't going to fix.

Edited by Baal0r

Share this post


Link to post
Share on other sites
1 minute ago, Baal0r said:

Thing is people are acting like graphics are the issue when clearly that's only part of the problem.

 

PTS runs fine most of the time but they still have the issue that the GPU is ticking along nicely but multiple squads get in the same area and the frame rate tanks.

 

The other issue I don't understand, why does Unreal engine not instance cull automatically as the fov changes?

 

Surely instance bounds checking only happens within the view frustum so you'd expect trees and stuff outside of that to not be drawn?

 

Anyway, point is there's still a lot of engine work to do that a few graphics sliders aren't going to fix.

"Fix" no of course they aren't the permanent solution. They are all steps in the right direction and at this point that's what we need. They aren't culling all the instances of trees outside of the field of view because the time to load more is greater than the amount of time it takes to change the view. Thus partially rendered textures. 

Share this post


Link to post
Share on other sites
1 minute ago, DR. Intellect said:

"Fix" no of course they aren't the permanent solution. They are all steps in the right direction and at this point that's what we need. They aren't culling all the instances of trees outside of the field of view because the time to load more is greater than the amount of time it takes to change the view. Thus partially rendered textures. 

 

That makes no sense whatsoever.

 

They are instanced trees, adding more costs nothing because they are already in memory, read up on GPU instancing.

 

Rendering more trees costs more GPU time.

 

Rendering more detailed trees also costs more GPU time.

 

Changing lod levels on scope zoom is the issue, it even states that in the dev blog.

 

The issue is that when you scope all trees within the original view frustum are rendered but at a higher lod level (more detail more GPU time).

 

It's nothing to do with loading. Culling tree instances is virtually zero cost by the very virtue that not rendering is much less expensive than rendering.

Share this post


Link to post
Share on other sites
1 minute ago, Baal0r said:

 

That makes no sense whatsoever.

 

They are instanced trees, adding more costs nothing because they are already in memory, read up on GPU instancing.

 

Rendering more trees costs more GPU time.

 

Rendering more detailed trees also costs more GPU time.

 

Changing lod levels on scope zoom is the issue, it even states that in the dev blog.

 

The issue is that when you scope all trees within the original view frustum are rendered but at a higher lod level (more detail more GPU time).

 

It's nothing to do with loading. Culling tree instances is virtually zero cost by the very virtue that not rendering is much less expensive than rendering.

It certainly makes sense. Even though they are exact replicas of one another, they still are separate copies in memory.... but you just want to be combative and tear down anything anyone else has to offer so that's fine. 
I'm certain the level of detail is a high cost and reduction in level of detail is paramount as the dev report says, but there is a difference between less lod and not rendering those at all... which is what you initially suggested. Now it appears you're arguing against your own suggestion quoted above. It's an insane argument that you're trying to make. 
I'm not going to continue to engage with you because you're clearly one of those people who aren't that bright but think they are a genius. Sorry Charlie.

Share this post


Link to post
Share on other sites
6 minutes ago, DR. Intellect said:

It certainly makes sense. Even though they are exact replicas of one another, they still are separate copies in memory.... but you just want to be combative and tear down anything anyone else has to offer so that's fine. 
I'm certain the level of detail is a high cost and reduction in level of detail is paramount as the dev report says, but there is a difference between less lod and not rendering those at all... which is what you initially suggested. Now it appears you're arguing against your own suggestion quoted above. It's an insane argument that you're trying to make. 
I'm not going to continue to engage with you because you're clearly one of those people who aren't that bright but think they are a genius. Sorry Charlie.

 

Ah, the armchair devs again arguing against the dev blog with their pseudoscience.

 

I suggested that culling the view should already happen due to the view fov narrowing on scoping not sure where you got the idea that I contradicted myself.

 

Culling means not rendering, instance culling means not rendering instances.

 

Zooming in with a scope renders all instances in the original field of view at a higher lod hence the frame drops.

 

Not sure who you are arguing with, but there's definitely no loading happening which is what you said.

 

 

Share this post


Link to post
Share on other sites
1 minute ago, Baal0r said:

 

Ah, the armchair devs again arguing against the dev blog with their pseudoscience.

 

I suggested that culling the view should already happen due to the view fov narrowing on scoping not sure where you got the idea that I contradicted myself.

 

Culling means not rendering, instance culling means not rendering instances.

 

Zooming in with a scope renders all instances in the original field of view at a higher lod hence the frame drops.

 

Not sure who you are arguing with, but there's definitely no loading happening which is what you said.

 

 

Armchair dev calling people armchair devs. That's rich.

  • Like 1

Share this post


Link to post
Share on other sites
6 minutes ago, DR. Intellect said:

Armchair dev calling people armchair devs. That's rich.

 

Well I develop for a living, and yes I do a fair bit of working from home so you could call me an armchair dev if you want, I do sometimes sit on my sofa with my laptop.

 

What's funny is that you are telling me that I think I'm a genius when that's clearly not the case, anyone with a basic grasp of reading could easily understand the dev blog, but you made up some nonsense about loading to make yourself sound more intelligent.

 

Everything I've said is in 100% parity with the information in the blog if you'd just take a few seconds to read it.

 

Not sure if a basic grasp of written prose makes me a genius.

Edited by Baal0r

Share this post


Link to post
Share on other sites
Just now, Baal0r said:

 

Well I develop for a living, and yes I do a fair bit of working from home so you could call me an armchair dev if you want, I do sometimes sit on my sofa with my laptop.

 

What's funny is that you are telling me that I think I'm a genius when that's clearly not the case, anyone with a basic grasp of reading could easily understand the dev blog, but you made up some nonsense about loading to make yourself sound more intelligent.

 

Everything I've said is in 100% parity with the information in the blog if you'd just take a few seconds to read it.

I've been reading a LOT of people on here lying about being devs. Here's another one. 

Share this post


Link to post
Share on other sites
Just now, DR. Intellect said:

I've been reading a LOT of people on here lying about being devs. Here's another one. 

 

Again with the accusations of lying.

 

I'm not lying about being a dev, but even if I wasn't one, I didn't say anything that PUBG corp didn't already say, you mate some stuff up.

 

Sounds like a bullshitter trying to get away with bullshittery but getting called out by someone who knows better.

 

If there's one thing I've come across a lot in my career it's people that talk the talk but can't program their way out of a paper bag.

 

These people still manage to keep a job because they are so good at pulling the wool over the eyes of their clients, the same stuff you are trying to do to forum members.

 

I don't know who is worse though, the one that does it to make money for his/her family or the one that does it for fun on a forum just to feel special.

Share this post


Link to post
Share on other sites
Just now, Baal0r said:

 

Again with the accusations of lying.

 

I'm not lying about being a dev, but even if I wasn't one, I didn't say anything that PUBG corp didn't already say, you mate some stuff up.

 

Sounds like a bullshitter trying to get away with bullshittery but getting called out by someone who knows better.

 

If there's one thing I've come across a lot in my career it's people that talk the talk but can't program their way out of a paper bag.

 

These people still manage to keep a job because they are so good at pulling the wool over the eyes of their clients, the same stuff you are trying to do to forum members.

 

I don't know who is worse though, the one that does it to make money for his/her family or the one that does it for fun on a forum just to feel special.

Oh boy! here we go. You did say something inconsistent and I called you on it. You said you don't understand why they just don't stop rendering anything outside of the fov. They said they aren't interested in that and instead are reducing the lod of those items. I offered a suggestion on why they might not do that because filling that lod might take more time than it does to change the fov to include those unrendered objects. Then you went all crazy. You were clearly intent on trolling before. Now you're going overboard with it. I'm not sure what kind of mental illness you are plagued with... but focus it on someone else nutjob. 

Share this post


Link to post
Share on other sites
11 hours ago, DR. Intellect said:

1440p is often referred to as 2k. There are numerous resolutions that people call 2k, and this is one. It sounds like they have made improvements of about 20-40%... which will be anywhere from 6 - 12 fps. 
They are unwilling to allow a setting on the Xbox One X that isn't higher def than the OG or S can do. That much is obvious... because with the fps gained by 1440p, it should be a bit better with 1080p. My guess is they are between a rock and a hard place on this because they feel they HAVE to make it run at a resolution higher than 1080p yet us Xbox One X gamers are demanding better FPS. 

The solution is a simple one. Games have done this for years for various reasons. Add a hidden dev menu that allows manual selection of various resolutions and graphical options as well as a frame counter and ability to disable or set vsync to what we want. Leak the button combination to get to this menu. Everyone will be happy this way. We can adjust our settings to our liking and you can claim the game runs higher than 1080p at over 30fps and you're being very honest. 

Some other things to consider.... give us a "forced model" mode. People only really wear custom clothes for the lobby when people will see them. The rest of the time they couldn't care less. So once the players get in the plane, have it wipe the custom clothing and player models from memory and use a single one for all other players. 

Give us an alternate fire/explosion/smoke animation. Something generic that achieves the same goal but isn't so costly to the performance. 

1440p is not 2k, if anything it should be called 2.5k as the "classification" is based on horizontal pixel count, but that's beside the point.

 

Granted, dropping the display resolution for the OneX will improve performance, it won't net any gains beyond 30fps as it is capped.  You'll just get a more stable 30fps as opposed to a slightly less stable 4k 30fps.  If they would grant the OneX 1080p, then sustained 60fps should not be an issue.  I think you're correct in assuming Microsoft won't allow them to drop the resolution to something comparable to the OG or S, pretty safe assumption.

 

Adding a "hidden dev menu" that the masses could potentially access would never, ever, get past Xbox certification.  That option is out.

 

Forced models is an interesting idea, but considering the game is a direct port of the PC version, with the exception of some UI tweaks and content differences, it's never going to happen.  

 

The ability to change more graphics setting, eg: lower texture resolution, lower post processing, lower shadow render resolution, now that is something that could easily be enabled and would be considerably effective in stabilizing or increasing frame count beyond 30fps, but getting back to the reasoning 1080p will likely never be an option on the OneX, again I think we're stuck.

Share this post


Link to post
Share on other sites
33 minutes ago, DR. Intellect said:

Oh boy! here we go. You did say something inconsistent and I called you on it. You said you don't understand why they just don't stop rendering anything outside of the fov. They said they aren't interested in that and instead are reducing the lod of those items. I offered a suggestion on why they might not do that because filling that lod might take more time than it does to change the fov to include those unrendered objects. Then you went all crazy. You were clearly intent on trolling before. Now you're going overboard with it. I'm not sure what kind of mental illness you are plagued with... but focus it on someone else nutjob. 

 

Clearly you can't read, it literally says instance culling.

 

I quote

 

"our goal is to increase performance both through not rendering high level of detail objects which aren’t shown on screen"

 

I'm not sure what you are missing there.

 

Let me break it down "not rendering" (culling), "high level of detail objects" (trees that you are zoomed in on) "that aren't shown on screen" (they aren't on the screen but are still being drawn).

 

If you knew anything about game dev you'd know that changing lods is relatively inexpensive, it happens all the time when you are driving moving/around to most meshes in game including the terrain mesh, the buildings, the trees, the rocks etc.

 

Less triangles are less expensive for the GPU to draw.

 

Changing lods just means swapping out the mesh of the instance you are drawing, it's built into the U4 engine as a standard feature with the ability to set the lod distances per mesh or per instance if required.

 

The blog explains that they are batching the instances so that all similar lods can be drawn with one call but due to this, even trees which are outside of the view frustum are being drawn. When scoping the far trees become closer thus rendering at a low lod would look silly, so they render them all with a higher lod (well, it's called lod 0 because it's probably an array internally which is zero indexed)

 

There's no reason swapping out a few lod models would cause slowdown unless of course you were suddenly rendering a crapload of them at a higher lod (because of the zoom... Like it says in the dev blog... Literally says it...).

 

The problem is that batching to reduce draw calls is including and rendering things outside the view frustum (again what they said). The circles represent instances of the same tree at different lods.

 

Not sure what you are on about with your suggestion, their suggestion of improving it so that those instances are culled makes way more sense.

 

Your suggestion would result in a load of trees in the scope that looked like shit and a load outside the view bounds that still looked like shit and still got rendered for no reason.

 

Good one Einstein.

 

(P.s. my suggestion is exactly what they are doing, they have to work around the batching first though which requires code to work out which trees in a batch not to draw any more)

Edited by Baal0r

Share this post


Link to post
Share on other sites
17 minutes ago, Baal0r said:

 

Clearly you can't read, it literally says instance culling.

 

I quote

 

"our goal is to increase performance both through not rendering high level of detail objects which aren’t shown on screen"

 

I'm not sure what you are missing there.

 

Let me break it down "not rendering" (culling), "high level of detail objects" (trees that you are zoomed in on) "that aren't shown on screen" (they aren't on the screen but are still being drawn).

 

If you knew anything about game dev you'd know that changing lods is relatively inexpensive, it happens all the time when you are driving moving/around to most meshes in game including the terrain mesh, the buildings, the trees, the rocks etc.

 

Less triangles are less expensive for the GPU to draw.

 

Changing lods just means swapping out the mesh of the instance you are drawing, it's built into the U4 engine as a standard feature with the ability to set the lod distances per mesh or per instance if required.

 

The blog explains that they are batching the instances so that all similar lods can be drawn with one call but due to this, even trees which are outside of the view frustum are being drawn. When scoping the far trees become closer thus rendering at a low lod would look silly, so they render them all with a higher lod (well, it's called lod 0 because it's probably an array internally which is zero indexed)

 

There's no reason swapping out a few lod models would cause slowdown unless of course you were suddenly rendering a crapload of them at a higher lod (because of the zoom... Like it says in the dev blog... Literally says it...).

 

The problem is that batching to reduce draw calls is including and rendering things outside the view frustum (again what they said). The circles represent instances of the same tree at different lods.

 

Not sure what you are on about with your suggestion, their suggestion of improving it so that those instances are culled makes way more sense.

 

Your suggestion would result in a load of trees in the scope that looked like shit and a load outside the view bounds that still looked like shit and still got rendered for no reason.

 

Good one Einstein.

 

(P.s. my suggestion is exactly what they are doing, they have to work around the batching first though which requires code to work out which trees in a batch not to draw any more)

 

I should probably correct, it's not my suggestion, it's their suggestion which I said I didn't understand why wasn't already happening in my original post.

 

It makes no sense to draw stuff you can't see, that's the whole point of culling (it's the reason why going inside something you can see through it, the camera is never supposed to be inside another mesh so game engines don't render back faces of polygons, it's called backface culling and it's something you'd know about if you'd had a basic grasp of game programming).

  • Like 1

Share this post


Link to post
Share on other sites
55 minutes ago, Baal0r said:

 

Clearly you can't read, it literally says instance culling.

 

I quote

 

"our goal is to increase performance both through not rendering high level of detail objects which aren’t shown on screen"

 

I'm not sure what you are missing there.

 

Let me break it down "not rendering" (culling), "high level of detail objects" (trees that you are zoomed in on) "that aren't shown on screen" (they aren't on the screen but are still being drawn).

 

If you knew anything about game dev you'd know that changing lods is relatively inexpensive, it happens all the time when you are driving moving/around to most meshes in game including the terrain mesh, the buildings, the trees, the rocks etc.

 

Less triangles are less expensive for the GPU to draw.

 

Changing lods just means swapping out the mesh of the instance you are drawing, it's built into the U4 engine as a standard feature with the ability to set the lod distances per mesh or per instance if required.

 

The blog explains that they are batching the instances so that all similar lods can be drawn with one call but due to this, even trees which are outside of the view frustum are being drawn. When scoping the far trees become closer thus rendering at a low lod would look silly, so they render them all with a higher lod (well, it's called lod 0 because it's probably an array internally which is zero indexed)

 

There's no reason swapping out a few lod models would cause slowdown unless of course you were suddenly rendering a crapload of them at a higher lod (because of the zoom... Like it says in the dev blog... Literally says it...).

 

The problem is that batching to reduce draw calls is including and rendering things outside the view frustum (again what they said). The circles represent instances of the same tree at different lods.

 

Not sure what you are on about with your suggestion, their suggestion of improving it so that those instances are culled makes way more sense.

 

Your suggestion would result in a load of trees in the scope that looked like shit and a load outside the view bounds that still looked like shit and still got rendered for no reason.

 

Good one Einstein.

 

(P.s. my suggestion is exactly what they are doing, they have to work around the batching first though which requires code to work out which trees in a batch not to draw any more)

LMAO! You just made a bunch of crap up. You clearly didn't understand my suggestion. it's clear at this point that you're 100% trolling. Nice try.

Share this post


Link to post
Share on other sites
17 minutes ago, DR. Intellect said:

LMAO! You just made a bunch of crap up. You clearly didn't understand my suggestion. it's clear at this point that you're 100% trolling. Nice try.

Ok mate, I can pull a million articles with evidence.

 

Here:

 

https://en.m.wikipedia.org/wiki/Back-face_culling

 

https://docs.unrealengine.com/en-us/Engine/Content/Types/StaticMeshes/HowTo/LODs

 

Here's an article on draw call batching which is what PUBG is doing to reduce draw calls (draw calls require that data is sent to the GPU, batching sends an instruction to draw many of something at once - changing render contexts is expensive)

 

https://docs.unity3d.com/Manual/DrawCallBatching.html

 

Here's an article on culling objects outside the view frustum (for opengl though)

 

http://www.lighthouse3d.com/tutorials/view-frustum-culling/

 

Just waiting for your evidence though... You don't have any.

 

I understand all those articles because I've actually worked on an engine using opengl/c++ before amongst other languages.

 

Ah just noticed that the unity manual backs me up on my claim that switching render contexts is expensive (in different words but same thing).

 

"This is mostly caused by the state changes done between the draw calls (such as switching to a different Material), which causes resource-intensive validation and translation steps in the graphics driver."

Edited by Baal0r

Share this post


Link to post
Share on other sites
1 minute ago, DR. Intellect said:

Evidence of what? I don't think you know what I'm talking about. You certainly don't know what you're talking about. 

 

Doesn't take a scientist (or developer) to work out that you've given up on this argument because you've no grounds to argue.

Share this post


Link to post
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
Sign in to follow this  

×