Did patch 1.1 mess with the LOD Distance?

[buzzfunk]

@osmoopa and @buzzfunk: Could you maybe kindly share comparison screenshot so we can verify that this issue exists? If we had those we could make a much more compelling argument. Thanks

I really dont have time to post screens. Look it up on redid. Plenty of people posting comparism shots there. Its not a complete game breaker and some judgement may lay in the eye of the beholder but personally i can tell the difference. I revert back to an earlier build and its much better.

 

[Azulath]

I always played with "slow hdd=on", because the performance improves a lot, but after update 1.3, some buildings don't load with this option enabled, then I noticed that the folder "cache" is not being created in appdata

In my opinion, they pictures you have posted warrant a bug report.

No, I'm arguing that whether or not it bothers you, or "ruins the game", or "destroys the immersion" is subjective.

Ok this has been a misunderstanding then, naturally what "ruins the game" is subjective and while it does annoy me and also negatively influence my immersion it does not ruin it.

Bit more steady overall. Still getting 45-56 FPS everywhere, frame cap locked at 56, Vsync on. There's now a little more near-field draw in.

I think that's difficult to say, because when Cyberpunk 2077 was released the framerarte was all over the place and not consistent on the very same system. That's why people thought editing certain unused files yielded in a performance increase while it actually did not do anything. I believe this to have changed now, but I'm not sure...

Sure, but those are the types of things that can now be optimized further as time goes on. I can't really solve problems like that before a.) I see there's a problem, and b.) I discover a balanced solution. Now, the numbers are known. The engine has been re-budgeted to solve issues, and it's known how far the values can be pushed without causing issues that were discovered after release. Now, for example, someone can go in and remodel those garbage heaps to cut the polygons used by a third, and/or rebuild the textures and maps to make them less intensive. Then, that aspect of the LoD can be tweaked back out a ways.

Yeah, we agree that it will get better over time. That's why I try to report each and every bug I encounter.

How? Reality knocking again. Obviously, one of the main reasons the game was suffering from such terrible performance issues was because the rendering engine was demanding far too much of the hardware. It couldn't handle it.

I don't understand the "how" question in relation to my statement. Anyway, I don't think that the rendering engine was demanding too much, if this is a problem for one's experience the settings can always be turned down.

General rule of thumb with consoles is to compare graphics to PC at the same specs. Very often, consoles will look about that good and offer slightly better performance.

That's only true at the start of a console generation, a few years in and this comparison starts to fail because consoles outperform hardware-equivalent PCs then.

A "downgrade" would be:

• "We've removed support for ray-tracing for the game. It's no longer supported."
• "The game no longer supports 64-bit processing."
• "The game will no longer support DirectX 12, it will only render at DirectX 11 quality."

I would just have the point:

• reducing the visual fidelity too much

Which is the case if Draw Distance and LOD were fine before.

There is no such time that I can recall.

• WItcher 2's insane Bokeh filter
• Witcher 3
• WIng Commander
• Ultrima (don't know which one)
• Crysis (but does it run Crysis?)
• another id game (Doom? Quake? - don't know anymore)

and that's just a few at the top of my head.

Seriously, I think there are microwaves now with more computing power than the gaming rigs I built in the '90s.

That's why people try to get Doom running on basically everything and anything.

But non-standard resolutions are non-standard for a reason. Many don't have any idea how much work is involved in supporting different aspect ratios. Namely, all 2D assets need to be completely rebuilt -- every, single thing -- for each aspect ratio the game will use. Once the resolution for an aspect ratio gets past a certain threshold, the assets need to be completely rebuilt for that as well. Again.

Ok this is something I doubt. Why would Witcher 2 run without any problems in this resolution? It was obviously not built for it, because I adjusted the executable with a hex editor accordingly but there weren't any issue. I have done this with many different games and I did not have a single issue in any game. If every 2D asset had to completely rebuilt by the artist, then this would not be possible.

Well, as I've told many people in the past, the first time they deal with a complete hard-drive crash at precisely the wrong moment, then have no way of recovering critical data for work or something, and even after a reformat and reinstallation of the OS, there's so many bad sectors that they still have to deal with ongoing file system errors, until they finally replace the drive, requiring that they go through everything again...

...they'll start ensuring that there's plenty of free space on every drive. 10% is actually cutting it a bit close -- especially with individual files able to reach an excess of 4 GB (movies, music, etc.) nowadays.

Well, if you are worried about your data on your main drive you are doing something wrong anyway. Either you can live with a complete failure and can accept it as lost, or you invest a significant amount of time and resources to protect it. Failing drives is only one side of the coin, bit rot can come along and mess up your data as well. For a gaming PC, I would say go crazy, use Raid 0 if you want to live dangerously because the game assets can be redownloaded anyway.

The example I've made is not meant to be taken literally -- it was an intentionally simplified example of how various aspects of an engine can connect in ways that a player has no ability to see or understand.

Yes I agree there might be weird and peculiar issues. However, you statement seems to be that it is only "logical" for a game engine to break fundamentally if I had the idea to increase the anisotropic filtering from x8 to x16. Now, all of a sudden quest items can be unlootable and this is completely expected unexpected behaviour. I don't argue that weird bugs and issues occur and can occur and due to the complex nature of engines adjusting them is difficult and cumbersome, but I still wouldn't expect everything to break all the time because of one switch being used.

No stretch at all.

It's a far stretch from my perspective because when it comes to open worlds and RPGs CDPR and Bethesda are complete opposites, with CDPR being the better choice from my opinion. I digress, Bethesda needs to take care of all the items that can be manipulated and also static NPCs, both of which CDPR games are free from. Furthermore, Bethesda exhaustively supports modding, while CDPR ony supports it a fair amount. Thus, the engine requirements are different and it also shows because Bethesda does have problems with creating a new engine.

Dragon Age: Origins through Inquisition, Mass Effect 1-3: Issues with both frame timing for in-engine cinematics and music. Potentially severe stuttering and crashing if FPS exceeded 60. Inquisition's scenes are a nightmare to get working correctly to this day, requiring a manual frame limit of something like 59.92 to avoid the most severe freezing and stuttering during cutscenes, though some stuttering still occurs, regardless, on virtually all PC systems.

OK, I assumed with severe problems you meant some of your example like quest being not completeable or certain actors not reacting at all. I think you mentioned timing issues, but here I also assumed that the game time would run faster and also everything else would be faster then.

Ah, I think your confusing a "rendering engine" with a "game engine". It is possible to use some rendering engines alone (Unreal, Quake, Unity, etc.) and build it into your game engine. This is actually what they were designed for -- to be licensed to outside studios.

That's true, I was most of the time referring to the rendering engine.

Okay. What do you think it was for then?

To increase performance on old-gen within the constraints they had.

This is why there were exactly the same type of rendering concerns for TW3, and it took as long as it did to finally sort out.

Imho, Witcher 3 hasn't fixed the Drawing Distance and LOD issues.

 

[SigilFey]

Bad design there. Nothing to do with graphics details of course and trivial to limit framerate to 60fps. That's also something that should be relatively easy to fix, you are saying you saw this with Morrowind but e.g. Skyrim had engine upgrade.

It did have the 60 FPS ticker for Morrowind. (Just like it's a part of every Bethesda game since. Here's the issue in Fallout 76. The YouTuber understands how to affect it, but doesn't really understand its purpose.) But, for Morrowind, if you could get any game to run at a steady 60 FPS at that point, you had a monster PC rig. Plus, there were no PhysX sorts of things in Morrowind to mess up. Just animation packages and the Papyrus scripts. I'd disagree that it was in any way a bad design -- it made perfect sense to do it that way at the time. That's how all computer games had operated at that point, ever since the beginning of computers themselves.

Earlier on, it had been processor cycles that dictated games...meaning that when processors began to become much, much more powerful and faster, it was impossible to run older games as they would play out at hundreds of "ticks" per second. Hardware functions like Turbo Mode and utility programs like DOSbox were specifically created to handle this, manually slowing down the processor cycles so the older programs could run. Who ever expected that computers would get so crazily fast so quickly?

Following that, Bethesda's solution was pretty slick, ensuring that their engine would run off of something that any computer at the time (and every computer now) had total control over -- the refresh rate of their display and the draw rate of their GPU. No worries at all in the future if hardware advanced -- the games could still be made to function perfectly. Who ever expected that 1080p resolutions and 100+ FPS gameing with 1 ms latency would ever become an expected thing?

And here we have the core distinction of this discussion about managing a game engine.

When it is made to function a certain way, then that's the way it functions. If I try to make it do something beyond its capabilities, I'm almost guaranteed to see errors. (This happens to the devs, sometimes, too!) The only solution is to put things into a place that is cooperative with the engine. And the types of errors I see might be caused by things don't seem logically connected. (Who would ever have thought that the reason the stuff on that table went flying like a grenade went off as I sat down...is because the refresh rate of my monitor was set to 144Hz.)

Also, it's not simple to fix these things. Impossible, often, unless the entire engine is totally rebuilt. I think Beth managed to tweak it to avoid most issues from Skyrim onward so that 144Hz default vsync automatically triggers half-refresh rate (72 FPS) and it avoids the most glaring issues.

Yes, too choppy performance due to too high graphics settings can cause glitches and crashes, I mentioned this as well. This is somewhat self-correcting because most people will dial things down if it gets too slow.

Choppy performance is not what I'm discussing. (I may have gotten carried away with the hypotheticals in my example. ) I'm talking about elements of any engine that require a sync with some other part of the engine. Has nothing to do with whether my FPS are "good" or "bad". (That's why games have minimum specs.)

All engines are built to process things in specific orders. (No, these can not be changed around willy-nilly -- they are what make the engine function. This is why there are different engines that are better or worse at different things.) One engine might be really good at processing visuals really, really quickly. (There's your Unreal and Quake engines.) Others may be excellent at handling outrageous amounts of AI scheduling. (There's the Lua engine or the in-house Total War engine.) Others may simply be very robust jacks-of-all-trades/masters-of-none. (Like Unity.) There's no defined categories. You either pick an engine that does what you need...or you build an engine from scratch to do what you need.

Once that's done, I don't get to simply say (as a fictional example), "Oh, my StratMaster engine doesn't create the graphics I want. Uhm, tell it to prioritize graphics, not pathfinding." Well...that's...not possible. That's not how this engine functions. It always does pathfinding first, because that's what the engine was built to do. If I want to free up more resources for graphics, I need to remove elements that are creating pathfinding. And it does some really intense pathfinding, man. If I want my desired level of graphical result, I may need to remove 70% of all of these military units, and I need to pull helicopters completely out of the game. It's not possible to deliver that level of graphics with the game I've built -- the engine won't allow for that.

So, a balancing act begins. Give and take. If I'm seeing an issue in one area, I can tweak and nudge things around and make it better -- but I can't just take my StratMaster engine, built for really complicated pathfinding and AI strategy routines, and simply make it into the Unreal Engine because I want to.

That's like saying I'm going to take that semi-truck and give it a higher top speed and better handling than a Ferrari. That's not what the machine is designed to do. The only thing I can do is make a bit faster and handle better. But that also means I'll need to use a smaller trailer, and I won't be able to haul as many goods at once. Need to drop weight to increase accelleration and handling.

That's a pretty direct analogy to how a computer engine works. It's built for a particular task, and it handles it a certain way. I can tweak, but I must work within the limitations of the machine's core design. A semi, a motorboat, and a sportscar are not capable of the same things, no matter how much I think they should be.

Now we're getting somewhere. It's interesting you say "script" related to LOD, perhaps scripting is running in a single thread a-la Paradox games? You hardly "have to" render the scene before you can run any scripts, not with multithreading going on. Yes, running scripts asynchronously causes additional issues but it entirely decouples graphics engine from scripts, although things can get interesting if FPS gets very low but that's again usually self correcting problem. You obviously have to synchronise at some point which can be time based entirely asynchronous or do it while the next frame is rendering.

No...that's nowhere close to what I was saying. It has nothing to do with single versus multi-threading -- that's not even something that's engine bound. Pretty much any engine can be coded to take advantage of it, and most games, believe it or not, use no more than 2 cores at once, regardless of how many are available. Many games today continue to use only one core.

Graphics are not handled through "scripts". Scripts are a gameplay function. Graphics are controlled by drivers. But a game engine will always require that certain other functions, like graphics, or sound, or AI scheduling, or whatever be processed in certain order. Computers don't "think". They don't "figure things out". They must be specifically instructed to do every single thing they do. And don't think about this like telling a computer to, "Pick up that cup, then sweep the floor." Coding requires more like, "Identify "Cup". Rotate 37° to face "Cup". Advance 0.47 m. Rotate right wrist 90°. Extend right digit fingers 1-4 by 45°. Extend right thumb by -45°..." and so on.

I don't take 1,000,000+ lines of code and "just do this part totally differently". Any game, once built, needs to work within the confines of the engine and existing code, and that will mean that only certain things are possible. It requires the devs to be clever. To think outside the box. To find ways of making certain processes much more simple...but not letting it appear to be any different. Like this:

If I have an issue -- I need to take something from one area, and give to the other. I don't get to create "chocolate" out of thin air. It needs to come from somewhere.

Hence, the amount of "chocolate" taken from the graphical rendering for whatever was needed is pretty noticeable at the moment. Over time, the "chocolate" that is left can be better arranged to make it seem like the whole "bar" didn't get any smaller. In other words, using the graphical budget that remains, the individual graphical elements can be tweaked and fiddled with until they feel more smooth.

Thus, for random, hypothetical example:
If I have an issue where a quest script will not trigger, because a required graphical asset cannot load in time (which, yes, can happen -- not saying it did happen that way -- just saying it's an example scenario) I must take processing time away from the graphics in order to free up that processing time for the quest script. If the engine needs the graphical element to be finished first, then that's what's needed. I need to work within that confine to solve my script issue. Graphics have to lose. But that doesn't mean I can't polish them up with what wiggle room is left.

Hopefully, that's more clear.

 

[Notserious80]

Yes some engines work weirdly too unexpected stuff. But theres generaly ways too fix this issue. Just like modders fixed the skyrim issues with fps, they might be able too fix the issues with RED if they get the tools for it. Will it be as good as if CDPR themselfs does it? Might even be better since they generaly do it for fun instead of having to fix it now for all 8 plattforms and so on.

Yes coding is complicated. especially when you have alot of systems having too work together and still not mess stuff up and im fairly sure why they made these changes, just as they made them in games before. Sadly it seems the engine isent as scaleble or as good at some things as ive heard elsewere but i dont have any experiance with it so i cant really say. Did sound like they ran into issues implementing some fixes for some hardware from the stream tho and cant say i was suprised. Its kinda naive too thing that a old console can keep up with a new pc or a new console tbh.

 

[Azulath]

So, a balancing act begins. Give and take. If I'm seeing an issue in one area, I can tweak and nudge things around and make it better -- but I can't just take my StratMaster engine, built for really complicated pathfinding and AI strategy routines, and simply make it into the Unreal Engine because I want to.

I think this oversimplifies because it is not a simple give and take. For example, if a good programmer creates a certain rendering function it takes n clock cycles, whereas an excellent programmer might be able to achieve the same thing in n/4 cycles. This would result in no visual difference, neither perceivable nor measurable, but in an increased performance.

For example, I have read a guide for an engine (forgot which one) a while ago where it was recommended that instead of creating a bunch of objects in a loop, a new dummy object should be created before the loop and then the data for the number of objects created should just be copied. Following this advice also results in better performance without any visual impact.

Additionally, in C and C++ - and I assume the RED Engine is written in C++ - developers have the choice to write code in Assembler. This can be done for performance critical functions which also does not impact visual fidelity.

Furthermore, there are probably some elements in the code that are not performance optimised and this could also be done given enough time. Because without insulting anyone at CDPR they probably have around 5-10% excellent C++ programmers. I say this because there are very few excellent programmers and I do not doubt that many have the precondition to become an excellent programmer, but it does take time. Now, CDPR has grown after the release of Witcher 3 which might have lead to people being promoted from development to management positions. Investing time here will certainly lead in a better performance, without taking anything from anywhere.

There is also the ability to do something differently but comparable manner. The Fourier Transformation comes to mind as an example here.

Finally, a balancing act between readability/maintainability and performance of the engine's code has to be accomplished and currently it might lean a bit more in the direction of the former.

pretty much any engine can be coded to take advantage of it, and most games, believe it or not, use no more than 2 cores at once, regardless of how many are available. Many games today continue to use only one core.

This statement is a bit odd without a timeframe, because for many years there were only single core CPUs around. I remember a presentation where Intel claimed the same and they included games that where developed back in 1995 or even earlier. Currently, most games use four cores and are able to utilise even more which has been proven by various reviewers.

And don't think about this like telling a computer to, "Pick up that cup, then sweep the floor." Coding requires more like, "Identify "Cup". Rotate 37° to face "Cup". Advance 0.47 m. Rotate right wrist 90°. Extend right digit fingers 1-4 by 45°. Extend right thumb by -45°..." and so on.

Maybe I'm now arguing about small details but this seems like a bit to complicated. While I do agree that computers have to be told how to handle things very explicitly there are also abstractions everywhere and between a game and the graphical output are operating system and driver(s). The last statement "Extend right digit fingers 1-4 by 45°. Extend right thumb by -45°.." does seem like something the driver should handle.
(But then again, this might just be the example.)

 

[SigilFey]

Yes some engines work weirdly too unexpected stuff. But theres generaly ways too fix this issue. Just like modders fixed the skyrim issues with fps, they might be able too fix the issues with RED if they get the tools for it. Will it be as good as if CDPR themselfs does it? Might even be better since they generaly do it for fun instead of having to fix it now for all 8 plattforms and so on.

Yes coding is complicated. especially when you have alot of systems having too work together and still not mess stuff up and im fairly sure why they made these changes, just as they made them in games before. Sadly it seems the engine isent as scaleble or as good at some things as ive heard elsewere but i dont have any experiance with it so i cant really say. Did sound like they ran into issues implementing some fixes for some hardware from the stream tho and cant say i was suprised. Its kinda naive too thing that a old console can keep up with a new pc or a new console tbh.

Totally agree!

Modding is always a lovely thing to have around. And I fully agree, many players have huge misunderstandings about the industry. It's very often not that the developers can't handle things "...like that mod does! For crying out loud, modders already did it, but the devs can't!?" Especially for graphical things, It's not that it can't be done that way, it's that it can't be done that way officially: Minimum / Recommended Specs.

And, as is very often the case, the methodology a mod uses may create a know issue. Even if it seems to work perfectly for a lot of people, if an issue can be identified, then it's not possible to introduce that sort of solution officially. (There're enough catch-22 situations in game design as is without devs knowingly introducing additional issues on top of it.)

Lastly, modders have whatever time they want, at their leisure, to freely work on one thing at a time. Even "big" mods are tiny, tiny amounts of work compared to what a professional developer will be responsible for on a much tighter time frame. Of course, several thousand modders all focusing on only a few things each are going to be able to hit more things than a team of 20 devs working full days on every, single issue that's been identified for their area of the game.

I think this oversimplifies because it is not a simple give and take. For example, if a good programmer creates a certain rendering function it takes n clock cycles, whereas an excellent programmer might be able to achieve the same thing in n/4 cycles. This would result in no visual difference, neither perceivable nor measurable, but in an increased performance.

For example, I have read a guide for an engine (forgot which one) a while ago where it was recommended that instead of creating a bunch of objects in a loop, a new dummy object should be created before the loop and then the data for the number of objects created should just be copied. Following this advice also results in better performance without any visual impact.

Additionally, in C and C++ - and I assume the RED Engine is written in C++ - developers have the choice to write code in Assembler. This can be done for performance critical functions which also does not impact visual fidelity.

Furthermore, there are probably some elements in the code that are not performance optimised and this could also be done given enough time. Because without insulting anyone at CDPR they probably have around 5-10% excellent C++ programmers. I say this because there are very few excellent programmers and I do not doubt that many have the precondition to become an excellent programmer, but it does take time. Now, CDPR has grown after the release of Witcher 3 which might have lead to people being promoted from development to management positions. Investing time here will certainly lead in a better performance, without taking anything from anywhere.

There is also the ability to do something differently but comparable manner. The Fourier Transformation comes to mind as an example here.

Finally, a balancing act between readability/maintainability and performance of the engine's code has to be accomplished and currently it might lean a bit more in the direction of the former.

Oh -- it's ridiculously over-simplified. And look at how long it takes to move through it in simple, layman's terms. The whole point of what I'm saying is that this process is orders of magnitude more complex, difficult, and time consuming than people may have any idea of. (And not for CDPR in particular: for all game studios.) There is absolutely no such thing as saying, "Just change the engine to work this way instead." It's not possible.

Or, more to the point, based on what you're saying, it's not possible to do it as a business. The types of changes you're talking about are not tasks that will take a team a few weeks to implement. That level of change would take years to complete. You'd be rebuilding not only the functionality of that part of the engine, but you would then need to rebuild every part of the game itself that relied on the old functionality. The game's code is not just going to magically understand the new instructions. Once I begin that process, the whole aspect of game development comes in. Because I've changed the root functionality in the engine, the changes that are then needed in the various parts of the game's code will wind up creating other issues in other parts of the game that they connect to. Changing those areas will create still more issues in other parts...and on, and on, and on.

So, yes, while it technically can be done, it's not "tweaking the engine". It's rebuilding it. This is not months worth of work. It's inherently redesigning core functionality of the game. This would be something that would be tackled in projects like reboots and remasters. They take years. That's not patching.

This statement is a bit odd without a timeframe, because for many years there were only single core CPUs around. I remember a presentation where Intel claimed the same and they included games that where developed back in 1995 or even earlier. Currently, most games use four cores and are able to utilise even more which has been proven by various reviewers.

Not most. Just many of the more robust and popular games. Take your pick of the millions of games available on Steam, GOG, Desura, Epic, etc. and they're largely going to use one or two cores. (And I'm talking about games releasing now, not games that released years ago.)

Now that 64-bit is very standardized, I'm sure things are going to start taking more complete advantage of multi-core and hyperthreading. But Windows 10 was the first version of Windows that was primarily 64-bit. It still offers a 32-bit option. The days of huge, 64-bit numbers and the multi-threading that will really make it shine is still only getting started. Just like the idea of ray tracing goes back for decades, but it's never been possible to do lighting like that in real-time until just a few years ago. It will be several more years before the technique and hardware are both advanced and affordable enough to become standard.

Same with hyper-threading. It's been around since the first dual-core processor. But it doesn't make all that much difference for 32-bit processing compared to 64-bit, and many games are still built to cooperate with 32-bit for the sake of older consoles, PCs, phones, etc. No reason to build in the functionality just so that it's there. That just introduces the potential for additional problems without any tangible gain.

But yes, the games that do use it see a big advantage! Especially online multiplayer games.

Maybe I'm now arguing about small details but this seems like a bit to complicated. While I do agree that computers have to be told how to handle things very explicitly there are also abstractions everywhere and between a game and the graphical output are operating system and driver(s). The last statement "Extend right digit fingers 1-4 by 45°. Extend right thumb by -45°.." does seem like something the driver should handle.
(But then again, this might just be the example.)

Heh...it's actually a lot more complex! Just to get the computer to ID the cup, I'd need to introduce whole libraries of code. I'd need to create entire animation packages and then import them into the game to have any arm or hand to move around. I'd need entire batches of code to define which 3D elements in the game are actors that can be interacted with, and which elements are static. Only then, can I start interacting with the actual cup and seeing what breaks.

 

[GogRelvas]

This isn't how it works. Building a game on Xbox is not the same as building it on Playstation. Those two are not the same as building for the Switch. And none of those are the same as building for PC. This is why many, many studios develop for only one platform, or will receive aid from a producer or separate studio to port the game to other platforms. Multi-platform is a ton of extra work.

Yes, there are certain elements like art assets and sound files that can sometimes be shared, 1:1, but one of the most diverse and particular things between different platforms will be its rendering. Therefore, changes made to graphical settings on a console often have absolutely nothing whatsoever to do with any changes that are made for the PC version. They often won't even use the same commands or configuration files. Totally separate.

The reason that graphics are being affected on PC is because that's what is necessary to try to fix the graphical issues (or other engine issues) that are affecting the PC. Just like for TW3...or Skyrim...or...any other of the thousands of video games released on PC...it is always possible to customize things for your, unique system, or tweak things for high-end machines -- but these things are not universally applicable. If you want proof, go to any modder's page that fiddles with LOD for whatever game and look at the number of players that can't use it, are encountering bugs, or have issues running it. The official releases from any studio will always try to get the game running as stably as possible across the board for that platform according to the system specs at the time of release.

?? So CDPR isn't working on one version of the game (currently focused on old-gen) and in the end porting it to "be read" on all platforms? Which by itself is a lot of work. You are saying in your opinion it's like creating 8 games? What did they mean when they said they focused on the PC version when making the game and left the console versions for later.
Because to me it really seems the original version was much more optimized for PC and now they are bringing that one version down to old gen. So with differences in the writing of the code to be read by the respective console (different translations) but the original book being the same.
Optimization can be, for example, writing the code to prioritize one feature over another on the streaming order right? Or even cancel a feature all together so the streaming goes along more fluidly. So even though great PCs wouldn't need, for example, that fog in Watson in NID close to the boats to disappear I think it disappeared everywhere right? I don't see them doing completely separate work on the different patch versions for now. I hope (as an old-gen console user but I hope for good PC owners) that eventually they can work separately on the versions if it is as I say about one universal version being worked on to fit all; later ported/translated

Edit: so sorry I was a few pages back, now read where the conversation is at and it's really interesting. Sorry this message came from the past and doesn't belong here XD

 

[buzzfunk]

So much talk about optimization. I don't know anything about programming or stuff but....

When the game 8 months later looks (ok maybe im being too picky - still) and runs worse on the same hardware then were is this "optimization". For what? Old Gen consoles?

I really wish CP2077 is a next Gen title only. I get that the installer base of the old consoles is still a huge chunk of the market but CP could have been that kind of game that makes people buy a PS5 *just* to play the game. And i really did not like how they "hyped" bug fixes and tiny enhancements like the mini map after 8 months. Just seems all so detached from the fan base but ok. Willing to wait and see what will happen...

 

[SigilFey]

?? So CDPR isn't working on one version of the game (currently focused on old-gen) and in the end porting it to "be read" on all platforms? Which by itself is a lot of work. You are saying in your opinion it's like creating 8 games? What did they mean when they said they focused on the PC version when making the game and left the console versions for later.
Because to me it really seems the original version was much more optimized for PC and now they are bringing that one version down to old gen. So with differences in the writing of the code to be read by the respective console (different translations) but the original book being the same.
Optimization can be, for example, writing the code to prioritize one feature over another on the streaming order right? Or even cancel a feature all together so the streaming goes along more fluidly. So even though great PCs wouldn't need, for example, that fog in Watson in NID close to the boats to disappear I think it disappeared everywhere right? I don't see them doing completely separate work on the different patch versions for now. I hope (as an old-gen console user but I hope for good PC owners) that eventually they can work separately on the versions if it is as I say about one universal version being worked on to fit all; later ported/translated

Kind of, but I wouldn't say it's writing 8 different versions. Right now, I think there are 3 major builds. Windows, Playstation, and Xbox. They did say that they started with the graphcial end on PC, because they wanted to try to get that build looking as good as possible, first. But building for different platforms isn't like taking the PC build and changing a few settings. The calls made by the engine to Windows would not be interperatable by whatever OS the given console is using. (A few may, many won't.) I'm out of my element here, as I've not ever directly dealt with porting anything, but my understanding is that it more or less involves re-writing key functions of the engine so that they communicate correctly with the console OS.

So, it's kind of like I was discussing above -- it's not "tweaking" anything -- it's rebuilding the engine for that platform. Years of work.

Some ports (whether going from PC to console or vice versa) seem to take shortcuts, writing what are sort of like batch files to "hook" calls being made by the game and try to interpret them the way the other OS can read. This is what usually results in completely dysfunctional, wildly janky ports. But that's clearly not what was done here. As I've said, I've watched and played the release build on my buddy's Xbox One. He didn't have any major issues. Just some stuttering and slowdowns here and there. And things like assets (NPCs, cars, etc.) being culled and re-created if you turned away and looked back. So the builds here were 100% native to the console...it's just that the release builds was simply not tested broadly enough on the consoles, and it was believed that the Day 0 patch was going to hammer out the biggest kinks.

So, now -- yup! -- they are completely different iterations of the engine. Changes made to graphical settings on PC have nothing to do with any changes that are seen on consoles. They're all working within their own parameters. They won't even share the same commands or configuration options in many instances. (Again, this is true of all games, not only CP2077. That's why it takes so long, sometimes, for games to release on different platforms. It's a bleep-ton of work.)

Don't confuse the work that needs to be done on each platform being in any way connected with the release of patches. That's a totally different bag of worms, and one that can be prohibitively expensive. It can cost a lot of money (tens of thousands of dollars) every time I release a patch on a marketplace. And I'll have to pay that for every marketplace, every patch. Plus, the team that works on the game's rendering for PC is not the same as the team that is working on the rendering for Xbox. And the team working on rendering for PS is also different. All of those people are different that the team fixing quest bugs, and it's a different team that's handling any HUD or interface issues. Much of that stuff (primarily quest issues) will be 1:1, and can be shared between all platforms. It's not "the PC group", and there's "the Xbox team", and those guys handle "Sony stuff" -- it's multiple teams around the world each working on their own aspects of the game, then they all come together in the end and pool their work. At that point, lots of issues will be discovered, as it's not like everyone knows everything everyone else is doing. Bugs and issues will crop up, and teams will have to coordinate with other teams to figure out the best way to solve each one. Test again, and then new or continuing issues arise. After months and months of that -- it's eventually decided that key milestones have been met, enough things have been fixed across the board on all platforms, and now would be a good time to release an update. "Hey, everyone! Patch 1.3 is ready! Here's a list of changes!" Then the process repeats.

When the game 8 months later looks (ok maybe im being too picky - still) and runs worse on the same hardware then were is this "optimization". For what? Old Gen consoles?

Nope for every platform on its own. Gameplay changes can often be universal, but technical changes are platform dependent. The above sort of gives the gist.

 

[osmoopa]

I apologize for my earlier claim that the graphics have downgraded. The more I have now played a new version of the game, the more I find that my claim is not entirely true.
Graphics are still very impressive, but sometimes the LOD is quite agressive, but you get used to it.

 

[SigilFey]

I apologize for my earlier claim that the graphics have downgraded. The more I have now played a new version of the game, the more I find that my claim is not entirely true.
Graphics are still very impressive, but sometimes the LOD is quite agressive, but you get used to it.

Well, that's good if you're getting used to it! I fully expect things like really noticeable pop-in will be smoothed out more over time. (And by doing that, reflections and dynamic lighting from streetlamps may get messed up. And fixing the streetlamps will bork the way shadows look during rainstorms... Working with games is a blast. )

 

[vegetaalex66]

I apologize for my earlier claim that the graphics have downgraded. The more I have now played a new version of the game, the more I find that my claim is not entirely true.
Graphics are still very impressive, but sometimes the LOD is quite agressive, but you get used to it.

When the focus of my thread shifted to the topic of downgrade a few pages ago, I decided to load up a few savefiles of my playthrough and tried to recreate some of the screenshots I had taken back in December. While I didn't manage to mimic them perfectly, it is sufficient enough for me to say that the game doesn't look different to me. At least, not that I notice. Which actually surprised me, because the only reason why I started to notice the LOD issues and why this thread even exists is that the game looked a bit "off" to me back in January when I wanted to check if patch 1.1 improved the performance for me. So I started to look more closely at the graphics, and the first thing I noticed was the changing container texture. Shortly after that, I noticed all the light sources in the Afterlife, and then everything else that just pops in and out about everywhere else in Cyberpunk. And as usually with such things, you just can't unsee them. :/
In another reality where I could pick between two evils, I'd gladly take a downgrade and have a generally less good looking game over the immersion breaking mess which the current LOD situation is to me.

 

[backtron]

less good looking

IMHO that's not needed. LOD resolution is fine. >50% problems are because of plain wrong LODs. I'm not sure if it has to do with engine bugs messing up texture mapping or just inconsistent models.

Take your container example - low resolution doors are upside down. You probably wouldn't even notice the transition if they were in the correct direction. Similarly I've seen devices with bright green lights turn pale red when approaching, brown doors with window and light inside turn to solid steel gray or huge dark truck fade into a small light blue 2D car. They look fine. The bothering part is that they change appearance.

 

[vegetaalex66]

IMHO that's not needed. LOD resolution is fine. >50% problems are because of plain wrong LODs. I'm not sure if it has to do with engine bugs messing up texture mapping or just inconsistent models.

Take your container example - low resolution doors are upside down. You probably wouldn't even notice the transition if they were in the correct direction. Similarly I've seen devices with bright green lights turn pale red when approaching, brown doors with window and light inside turn to solid steel gray or huge dark truck fade into a small light blue 2D car. They look fine. The bothering part is that they change appearance.

Regarding the choice of two evils, that was hypothetical, I do not think of them being actually connected. About the container, to be honest, I didn't even notice it was upside down, so I definitely would still notice the transition if they were in the correct direction. ^^ They change from a high quality 3D model to a flat, really low res texture, and that at a super close distance.

 

[Batak]

That's correct: subjective. And I agree that there have been noticeable changes. I agree that most people can argue certain things looked better before. But I'll also point out that I'm seeing fewer instances late draw-in, sudden frame-drops when entering certain areas, and a more cohesive visual balance across the board. (YES -- many elements of the game draw in closer, but I'm not really noticing this drastically overwhelming, immersion-shattering, visual mess with game assets popping in 5 feet from me. Actually, if I had to make a comparison, I'd say things are now drawing in at about the same distance as equivalent assets would have appeared in TW3. Occasionally, especially if driving quickly, I'll see a billboard or details for a building materialize in way that's, like, "Erm...dorf!" But it's hardly a game-breaking issue. It simply needs a little more tweaking here and there.)

Graphics are not subjective, from a performance and technical fidelity point of view. Story can be, or characters, soundtrack, all this are marginally subjective elements within a game.
I appreciate that you try to explain and reassure us that is not an issue, but your extremely long posts are not really an insight from CDPR devs, just assumptions, with a inclination to defend the game.

At the end of the day, the fact of the matter is that in this game LOD and draw distance are really bad, it's nowhere near close of a 2021 AAA standard. Just take a look at other games, like RDR 2, AC Valhalla, etc., it's hilarious when compared side by side
You compare LOD from CP 2077 to Witcher 3, a 2015 game which suffered from exactly the same issues, because it uses the same mess of a game engine. In 5 years they did not manage to improve this aspect of the game engine.

Now , for end users, who paid 60 bucks 8 months ago for this game to enjoy on PC, we can't really enjoy it, cuz' the freaking light poles, NPCs and trash cans pop in my face when driving. Just great, amazing work. But it's subjective, so don't matter, eh ?

 

[SigilFey]

Graphics are not subjective, from a performance and technical fidelity point of view. Story can be, or characters, soundtrack, all this are marginally subjective elements within a game.
I appreciate that you try to explain and reassure us that is not an issue, but your extremely long posts are not really an insight from CDPR devs, just assumptions, with a inclination to defend the game.

At the end of the day, the fact of the matter is that in this game LOD and draw distance are really bad, it's nowhere near close of a 2021 AAA standard. Just take a look at other games, like RDR 2, AC Valhalla, etc., it's hilarious when compared side by side
You compare LOD from CP 2077 to Witcher 3, a 2015 game which suffered from exactly the same issues, because it uses the same mess of a game engine. In 5 years they did not manage to improve this aspect of the game engine.

Now , for end users, who paid 60 bucks 8 months ago for this game to enjoy on PC, we can't really enjoy it, cuz' the freaking light poles, NPCs and trash cans pop in my face when driving. Just great, amazing work. But it's subjective, so don't matter, eh ?

Yup. All members are free to share their thoughts. That includes members of the moderation team. When an official announcement is made, it will come directly from one of the REDs. When the moderation team handles official business, it will be handled in blue text, such as this. Anything else are the private throughts of the team, expressed in open discussion, like any other member.


________________



At the end of the day, all graphics are subjective. Whether someone happens to like them or dislike them, whether someone thinks the issues are glaring or hardly noticeable, whether someone thinks the optimization, for graphics or whatever else, is good or bad...that's up to each individual. We're discussing opinions. There's no governmental document or objective scientific study outlining the threshold between "good" graphics and "bad" graphics. There's also no legislation or mathematical formula that identifies how long it is acceptable to take to finish optimizing a video game.

Conversely, there is definitive law (internationally recognized law!) that determines whether something is falsely advertised or intentionally misleading toward consumers. And that is why CDPR's advertisements are still publicly available, and the game is still freely up for sale on markets across the globe. There was no false advertising at any point. Just a large number of people that misunderstood what was being shown, what it meant, and those that superimposed their own assumptions and interpretations on a work-in-progress. (Not to mention a WiP that was demoed years before the actual release.)

If you're not aware of how much a game can transform from a work-in-progress, to a final, released state years later, keep watching. This is not the first game to change or remove or add content, and it won't be the last. The bigger the project, the more it will change.

Now, it's out, and the graphics and performance and game mechanics are officially known. If you don't care for it, you don't have to play it. If you'd rather play RDR2 or AC: Valhalla, or Forza because they offer LoD more to your liking -- have at it! It's your choice! But no one else is responsible for catering to people's individual likes, dislikes, interpretations, or time-frames. If enough people don't like it...the game won't sell. It's that simple. If the game does sell and generates a supportive following -- even though a whole army of other people dislike it -- well, that's life.

 

[SigilFey]

IMHO that's not needed. LOD resolution is fine. >50% problems are because of plain wrong LODs. I'm not sure if it has to do with engine bugs messing up texture mapping or just inconsistent models.

Take your container example - low resolution doors are upside down. You probably wouldn't even notice the transition if they were in the correct direction. Similarly I've seen devices with bright green lights turn pale red when approaching, brown doors with window and light inside turn to solid steel gray or huge dark truck fade into a small light blue 2D car. They look fine. The bothering part is that they change appearance.

Regarding the choice of two evils, that was hypothetical, I do not think of them being actually connected. About the container, to be honest, I didn't even notice it was upside down, so I definitely would still notice the transition if they were in the correct direction. ^^ They change from a high quality 3D model to a flat, really low res texture, and that at a super close distance.

Some of those things may be completely unrelated (like the upside-down container, which is probably just a misplaced asset, not any fault of the rendering engine).

But I am seeing stuff in some videos that seems to be driver- or GPU-related. As in, exactly what @backtron is saying -- the incorrect LoD assets are drawing in at the incorrect times. I do notice some odd details here and there appearing in the far-field, vanishing in the mid field, then reappearing in the near-field. That is likely more optimization that needs to be done between the game and all the different cards, drivers, and versions out there...not to mention API versions that could be conflicting.

I do know, for example, on my own game, I don't see any of this "stippling" effect that many people are showing clips of, where shadows and textures start to dither in the foreground, or on adverts, billboards, etc. Nothing like that happens in my game at all. Everything displays correctly, in that regard. I am seeing the occasional section of stuff like lamposts that don't seem to draw correctly, or draw in really late. But it's not everywhere.

I'll be uninstalling and reinstalling soon to start a new game. We'll see if that changes anything.

 

[backtron]

in some videos that seems to be driver- or GPU-related

Some sure. But i'm fairly certain most are not, because I experience them consistently every time between saves, updates, reinstalls, driver and windows updates. In addition they show up on completely different hardware (GeForce vs Radeon, Intel vs AMD, PS5 vs PC) if you start looking for fix on youtube or elsewhere.

Just be more specific - I suspect anyone on any machine could visit rancho coronado ferris wheel and see it dissapear when you try to climb it, see the brown door under the highway near chapel fast-travel point in pacifica or see enormous Arasaka pop-in when walking up from californie&cartweight to Konpeki plaza.

I wonder if one could build a model parser based on MOD tools that can identify and fix such objects?

 

[LeKill3rFou]

Just be more specific - I suspect anyone on any machine could visit rancho coronado ferris wheel and see it dissapear when you try to climb it

Maybe I'm wrong, but the "wheel" have nothing to do with any patch or any "optimisation" or whatever, it's exactly like that since day one

 

[Audi82]

an italian article about an alleged downgrade of puddles reflections (video inside)

Cyberpunk 2077: patch 1.3 riaccende la polemica, ora sulle pozzanghere

Un vietnam flashback sulle pozzanghere.

www.spaziogames.it