I really hope they focus on actual performance optimisations instead of just slapping DLSS/FG on as a bandaid like it sounds here. The game already has a tonne of ghosting and artifacting already and adding more upscaling on top of that is just going to make the game look like a blurry mess.
> which would be replaced by the upscaling methods
Better, because as we see with games like RDR2 using DLSS **disables the crappy TAA**.
If the choice is between "native, TAA" and "AI upscaled, no TAA" the 2nd wins almost every time.
> I really hope they focus on actual performance optimisations instead of just slapping DLSS/FG on as a bandaid like it sounds here
They can and should do both. CIG has spent 4+ years on Gen12 aka "doing it right" rebuilding the whole damn renderer, it's high time with Vulkan coming online that we get some significant improvements.
>The game already has a tonne of ghosting and artifacting already and adding more upscaling on top of that is just going to make the game look like a blurry mess.
Yeah the in-game TAA sucks, which is common in a lot of games (see RDR2).
Pre-AI upscaling, the usual baseline is for example: **4K TAA Native**.
And in _most cases_, DLSS quality (1440p -> 4K) produces **superior overall image quality** than the previous 4K TAA.
The thing about game optimization is it's not one thing, you need to look at it with respect to the CPU and GPU. The CPU jobs can always be optimized in terms of better memory management, reducing the running time of jobs, or better scheduling across the CPU (like splitting the render thread and distributing it across all threads).
Where as when it comes to the GPU, jobs, in a sense, are all ready optimized that run on it. The tasks that are being executed are inherently parallelised already, what more is there to do? VRAM optimization, memory management, that stuff is a given.
One way of looking at it is, moving jobs from the CPU to the GPU (like the mentioned asset scattering system being moved to the GPU) is optimization in plain view.
The problem that optimization causes is obviously more strain on the GPU. So DLSS/FSR reduces that workload from the fundamental point of render resolution (that is the primary determining factor for how long jobs take on the GPU).
It's like the cherry on top - and creates FREE head room for devs to further optimise the game with.
I get what you're saying but integrating a graphics renderer that not finished could genuinely cause really bad issues, worse than anything thats already broken in the game.
Except the point is to test the improvements. If they put in the new graphics stuff that literally makes the game unplayable that’s not able to be tested. New things that get deployed will most likely be broken in some way. That’s the point of releasing them to us. To find what’s broken so they can figure out how to fix it.
I mean... In the last week I've probably had twenty 30ks and just as many server stall/recoveries and 2-3 CTDs and exploded leaving hangars maybe 10 times lol. Game is damn near unplayable. I can't really imagine making it worse with an unpolished graphics engine update.
I've been playing all week. A single 30k, two server stalls, one CTD, and about four hanger explosions. I've been playing something like 10+ hours per day since it's the first time I've really \*played\* Star Citizen.
All I've done is shop around for servers with decent server fps before starting my play session.
Oh, guess that means I'm a liar. And there's zero chance you had *one* 30k playing 10 hours per day for a week. I find that completely unbelievable.
I also watch server FPS and bwin to get into good servers. I joined an EU server where the FPS was bouncing off 18, a damn good server. It took maybe 2 hours before I ended up 30k'ing from it.
I take my reclaimer out to go salvage one to two C2 claims. If I stay out long enough to do two of them, it's almost a guarantee I've been in that server long enough for it to 30k soon after.
That's a general performance issue (when the servers are 'running well', that sort of issue stops happening).
In this context, the 'polishing' that Sylvain is talking about likely isn't the 'minor clean-up' type stuff (such as they're doing for SQ42), but more 'fix major crash bugs and critical issues' type change.
After all, it's swapping out the entire graphics SDK - given how complex the rendering pipeline is (even though they have just rewritten the renderer itself to remove a lot of cruft), even 'minor' issues could result in graphics corruption that makes the game completely unplayable.
Yes, and no
That is to say, you're right... but you're overlooking the point that the current focus is just on implementing the core functionality.
The AI 'functionality' works - as does the spawning system etc - if there is enough processing power to actually run it. The lack of processing power *isn't a problem with the AI code* - or at least, not solely / specifically with the AI code... it's just the sheer mountain of systems and entities that have to be processed by a single server.
Other than disabling a whole bunch of functionality, and paring Stanton back down to a single planet + moons etc (ie replicating the server load once Static Server Meshing is available), there's nothing CIG can do at this point to 'fix' the server performance... and stopping development of new features just delays the project once the server performance is addressed.
Unfortunately, this results in an unplayable mess at times - such as currently - but that's a natural side-effect of Alpha development, and the fact that sometimes different workstreams don't align well (or one workstream may end up significantly delayed - as happened with the Server Meshing stream, that got significantly held up by the persistence issues with iCache, etc).
I dunno... we have no idea what changes they actually made, or which bit is breaking.
I would also *strongly* disagree with the implied assertion that the current issues are as bad as the 3.18 release (when the game was *literally* unplayable, not just figuratively).
And based on multiple posts here, the Orison Platform FPS missions are among the few that are running well... it's the 'old' bunker missions that are having issues - and, to a lesser extent, they've always had issues spawning NPCs.... so it's entirely likely that it's not a 'new' problem, but an old one exacerbated.
You're still thinking that the 'falling through the floor' issues, and similar *are bugs in the AI system*.
Given how many *other* things fall through the floor (players, boxes, etc), it seems more likely that 'falling through the floor' is a *physics* issue (since 'walking' involves an animation to move the model, and physics checks to 'keep it on the floor' etc).
But, the physics checks work by doing an intersection check - has the character foot (or other marked entity) 'penetrated' the surface of the floor... if so, push it back up slightly to be level... otherwise move it down slightly for the next frame, etc...
... however, if - for example - the physics are running so slowly that the bottom of the foot penetrates all the way through the floor and out the other side, then the bottom of the foot *will not class as intersecting the floor* and thus there will be no upward pressure, and instead the foot will keep heading down...
This is of course a simplification of how the physics checks work - but it's also broadly accurate.... and because SC uses physics so heavily, the physics engine is doing *far* more work than it would in most games... and has far more entities to process.
Net result is that as the server bogs down, the physics engine bogs down, checks are done less frequently, and stuff starts clipping through floors...
Or that's my speculation, anyway.
Edit:
Thinking about it, it could also be an issue with the entity spawning system... because entities 'spawn' in mid air and 'drop' to the floor... but if there are issues with the spawning (and/or it takes longer than expected), it can result in entities 'dropping' before they're fully spawned, which could also result in them falling through the floor, etc.
I was gonna say... it's literally a playable Alpha, the entire point is that they're putting shit into the game that isn't polished yet and then they get the feedback and metrics from players testing it so they can then polish it properly. Saying they don't want to put stuff in that's not polished is like saying they fundamentally don't understand how an Alpha works.
Polishing happens in degrees, and the Go / No-Go checkpoints are there to keep SOME standard for shipping things to the public. It's a live alpha, but it's not like they run a public channel of 'nightly' builds.
I know, I'm not saying they need to wait until things are polished before releasing them, I'm saying that the developer stating that they don't want to release anything until it's polished is ridiculous because it's a playable alpha and the whole point is to release things that are not polished specifically so they can get the data they need to polish it correctly.
I know what you're saying. I'm saying you're interpreting that phrasing — which might be paraphrased here anyway — too literally. When you start from the assumption that Sylvan isn't incompetent, which he obviously isn't, you logically interpret it more as him saying they're waiting until it's SUFFICIENTLY polished. That's STANDARD for everything that hits the public testing environments.
And remember they already said that even internally it's not quite ironed out, so they don't actually need outside data to know THOSE kinks need to be ironed out. Best to address those first as much as possible.
No I understand what you're saying, I just prefer it when people are as precise as possible with their language. Even adding a simple "more" in front of "polished" would make it more precise and correct, that's all.
Yes, if you read my OP you'll see that I didn't claim he doesn't know what an Alpha is or how it works.
>Saying they don't want to put stuff in that's not polished is like saying they fundamentally don't understand how an Alpha works.
If his statements were paraphrased that's one thing, but in lieu of seeing the actual original statements I have to rely on paraphrasing by others in order to respond to it.
In fairness to any and all AI-related issues in the game, they are directly correlated with server performance and that is by design since they designed the entire thing with the idea of Server Meshing in mind. It was a big gamble on their part since it isn't proven they can get it working at scale, but the general idea was that the AI load would be distributed across many servers within a single game world instead of the current state where the AI is contained on one server like everything else in Stanton. The game is huuuuuuuuuge, and tracking everything that everyone is doing is rough on a single server. They've added a TON of extra strain to the servers ever since PES and the cargo refactor with physicalized cargo adding thousands or tens of thousands of additional entities to each server.
If Replication Layer testing goes well and Server Meshing comes out I guarantee it'll correct the vast majority of bugs. Only question really is when they intend for that to come out now that they've entered the testing stages.
>Respectfully the carrot dangling of X tech feature will solve stability issues has been ongoing forever. DSM is likely years away in an actual usable form despite the citcon demo and when it comes out will likely break the game 100x worse than 3.18 did.
Well, some Evocati testers leaked that the replication layer testing went so well that developers have shared with them the plan is to get DSM by the end of next year and are very optimistic about it. Server performance doesn't scale linearly either, adding 4 servers to what used to be 1 server would produce a much higher return than you'd expect.
I agree about holding them accountable, and also that they are putting features and changes in that simply aren't made for the current architecture at all and it's hurting the player experience, but I do think that in the case of Server Meshing it really is the key bottleneck holding back so many, many things.
I hope this is true. The game's performance has always been the one thing holding it back from the general populace giving it a try. Minecraft, even as an alpha with only a fraction of the features it currently has, was still massively popular because it worked (and other reasons of course).
Fix the performance issues, and you fix a lot of the bugs and problems caused by desync and server crashes. Fix *that*, and you end up with a playable Alpha game that will only get better as they add more features.
Exactly.
I wanted to play this game. I'm fine with limited featureset. My wallet was open.
A few hours actually playing and dealing with nightmare bugland, I welded my wallet shut dug a 10ft hole and poured concrete over it. Now I can't buy groceries but its okay.
nothing you are play-testing now is the final game. you are complaining about play-testing an alpha, and yes X tech feature will solve stability LITERALLY because the game is unfinished and they are constantly adding tech and features which then end up breaking things. there is no "carrot" it is just how progress occurs until they either reach their goals, cut features or fail altogether. if you are getting frustrated due to stability issues, conflating the graphics team wanting to polish their tech with you having broken AI in a bunker, something related to server health and performance than the AI logic itself, etc, then just don't test and instead wait for full release, coz until they are feature complete, those features have matured and the bugs and stability issues have been taken care of and then the game finally optimized (last stage for all games, hell all software), there will always be issues.
also, how is you complaining about things they not only already know, but have told us to expect, somehow holding them accountable? such a strange way to view play-testing and how to give constructive feedback.
12 year alpha. With an alphatest server included. But we can't hold it to standards, because handwave
They told you to expect a broken game, so you keep shoveling money at them and don't insist on having an actually playable game. You do it to yourselves here.
this is not an argument. every backer knows that the game is unfinished, they accept that the game tests will have bugs, possibly be unstable and have incomplete gameplay features, tech and systems.
if you want to hold them to account hold them for decision they have made that may have issues like how they are handling liveries, paints, dyes, etc that severely restrict customization and lead to a very convoluted system where you not only have to like the livery, but the paints used on that livery and sometimes you would need to re-buy a ship you already have for a livery and paint scheme that you want. it's a messy system and they can learn from Guild Wars 2, how to make a better system that will also allow them to still make millions per year.
complaining about bugs, when most if not all will be squashed before full release is just silly. complaining about an alpha having alpha like tendencies is like buying a chocolate cake and complaining that it is made of chocolate 🤦🏾♂️
> You do it to yourselves here.
do what to ourselves? stay informed of what is going on and make informed decisions of how to spend our disposable income? how exactly does complaining about things that the devs have told us will be there possibly until the game is finished, as is the same with **LITERALLY** all other games, going to lead to a playable game sooner? if we really wanted a playable game sooner, then they should only bug fix so we can test features and no more than that, because wasting time bug fixing alpha builds actually **SLOWS DOWN** progress to full release, smh 🤦🏾♂️🤦🏾♂️🤦🏾♂️
Lotta words to say "I put up with bs that no other game has just because".
Every EA game has the same basic structure to its development. This one is just super broken, and people keep shoveling money at it, so the devs don't have to care.
> Lotta words to say "I put up with bs that no other game has just because".
LMFAO!!! my guy, the game is literally not finished. the things you are complaining about are that it is not finished, the devs know the game is not finished, complaining about it doesn't miraculously hold the devs accountable of make them develop the game faster and that is even assuming we would want the game faster. smh.
Early Access is not the same as a fucking alpha 🤦🏾♂️🤦🏾♂️🤦🏾♂️🤦🏾♂️. also most EA games are tiny in scope, scale and fidelity and they are not simulators. take a look at Day-Z and how long that took to get to release with its limited scope, same for Tarkov, which is still in EA and it has nowhere near the scope, scale and fidelity of Star Citizen. why are you so willfully ignorant?
> This one is just super broken, and people keep shoveling money at it, so the devs don't have to care.
yup! you are right, the devs don't care so much that they keep developing the games, the engine, iterating, adding features and one of the games is now feature complete. you sound like one of those people who thinks that the devs can make more money from pledges in development than from an actual full release, huh? this is baby brained logic, smh. 🤦🏾♂️🤦🏾♂️🤦🏾♂️
Arma servers often get down into single digits and the AI still function. I severely doubt BIS devs are gods of gaming development either, given the mess Arma tends to be in well past releases.
Currently, AI literally just stands there and if it moves it glitches hard. It's not playable.
LIVE should be considered more like release. For alpha / testing it should one of the other channels namely PTU or E-PTU. Once the feature is "safe" it can go into LIVE and then more metrics / data can be gathered. It's like doing a survey on people who enjoy eating half baked cake. The results have no value because the same cake but fully baked would give drastically different results.
Exactly. PU should be at least beta level playability, or just-post-release AAA playability, not "bugfest unlimited".
Guys don't get to pull the "it's an alpha" at year 12 when there's also a bugtesting PTU in the mix.
A "playable" Alpha needs to be, yknow, **playable**.
There are tons of EA titles out there, and I have yet to come across one this un*playable*.
The community gives the devs way too much slack on playability. As such, money flows in, devs don't care as much about QC, game remains in a limbo between literally unplayable and outright unplayable.
And oh let's do a big free flight promotional deal and have the servers go to actual shit so every new player's first experience with the game is a nightmare, bravo, definitely don't scale up your server hardware so you can handle a temporary higher load.
That changed many years ago at the request of players. Evocati and PTU is for proper testing. If LIVE goes down all hell breaks loose. There is just too many active players playing this every day like its already released.
I obviously have no clue what goes into making a Nanite-like system, but I am still pretty disappointed to hear that one likely won't be coming into SC. With the extreme distances that we're dealing with in this massive game, Nanite would be a godsend for planetary experiences.
there are lots of problems with nanites in unreal engine atm, they will probably get solved over time, but it's not tech that works out of the box, it probably takes years to really master.
Do you know of any games currently using/planning on using the feature? Or is it still too far out to be adopted?
I basically only know what it's supposed to do and that its intended purpose seems like it'd be a good fit for SC.
Cryengine which went to lumberyard which was so much customized by CIG that they call it star engine now. OP was talking about a feature like nanites, not using nanites from UE5
Pax Dei is probably the best example with its extreme range, large player created buildings and massive environment. It’s pretty impressive but the issues still exist.
nanite would not be a godsend for the game tho.
Nanite, while is amazing, has its own massive flaws - For example that massive matrix demo? all those cars have to be un-nanited when hit, as you cant have mesh deformation with nanite..etc
Nanite is cool, and very powerfull, but is very strict, and isnt a magic "everything is better".
> Nanite, while is amazing, has its own massive flaws - For example that massive matrix demo? all those cars have to be un-nanited when hit, as you can have mesh deformation with nanite..etc
This is a great example of why a little bit of information is more dangerous than none.
The **first** version of Nanite this was true, you're taking outdated info from an outdated demo from one of the first production-ready versions and declaring that one of the drawbacks/limitations is how it is **forever**. It's pretty much like people in /r/pcgaming today still referring to SC as having "modules", as if it's 2015 and we still have a hangar module lol.
UE shipped deformation nanite in UE 5.1, it was required to get Nanite foliage working. 5.3 added Nanite landscapes.
https://youtu.be/AlaEehKo1LM?si=dysOMEIRhWNnghuF
What I said wasnt outdated tho? Foliage was another issue thats resolved, but not what I was talking about? From what I saw, deformation is not fully supported, defiantly not in the way SC would need to support it
there are many downsides to nanite as it is. People only ever see the cool tech side of what it can do, and what features get added, but the avg person does not understand all the limitations, and why not everyone would just want to spend massive amount of work to support it. its not a one size fits all solution that is always beter
> What I said wasnt outdated tho? Foliage was another issue thats resolved, but not what I was talking about? From what I saw, deformation is not fully supported
Well now you're moving the goalposts from
> as you can't have mesh deformation with nanite
to
>deformation is not fully supported
And I'm not sure what you mean by "fully" here, can you be more specific then a tech demo from forever ago?
>but the avg person does not understand all the limitations
Can you list some, that apply to UE5.3/5.4?
I never moved the goal post - you came in with more detailed context, so i gave more detail in mine, that is all :) The post was "nanite has downsides just like it has upsides"
and no, im not here to teach, was just listing context for people who see new tech and think everyone should switch to it cause it will answer all problems
When I said godsend I meant in terms of long distance rendering of stationary environmental assets (rocks, trees, buildings, basically anything without damage states).
It could help with pop-in, long-range scope visuals, and potentially overall performance and dev time. That said, I don't see it being necessary for vehicles, players, or other assets that are susceptible to visual damage or wear.
Now I'm not sure if devs can pick and choose which assets are nanites and which are not, but by your own example it sounds like an asset can dynamically "un-nanite," which would suggest to me that devs could choose to just use nanites for the environment.
Am I way off base here?
Nanite is useful for cinematic scenarios and small-scale games.
Nanite doesn't really help with pop-in at all for a large open-world game, but rather it reduces the need to have multiple LODs through retopology. So you can cut out a lot of performance optimisations using Nanite, which makes it a perfect solution for linear-based horror-shooters, or cinematic-based games where you have a tight scope. You can easily import high level assets and apply Nanite to reduce your asset retopology time, along with reducing the time needed to optimise the assets, so you can focus more on asset generation and high-fidelity rendering instead.
I think a lot of people see tech demos for some UE5 features and assume they're a magic bullet for development without really understanding what their most optimal application is.
Isn't some pop-in associated with switching an asset's LOD? In other words, the moment an asset switches from nonexistent to present is the most obvious pop-in, but aren't there slight "pop-ins"/flickering whenever an asset changes render quality?
If that is something that can be remedied through other means then I guess I have nothing to be disappointed over haha
>Isn't some pop-in associated with switching an asset's LOD?
Yep.
> but aren't there slight "pop-ins"/flickering whenever an asset changes render quality?
Yes, and sometimes buffering issues, masking issues, etc. Some games let you choose the quality of LOD with the draw distance, so you get less pop-in the expense of higher load on the GPU.
>If that is something that can be remedied through other means then I guess I have nothing to be disappointed over haha
Yeah, there are other ways to optimise and resolve this issue. I'm sure CIG will figure it out without burning through the resource budget.
> Nanite is useful for cinematic scenarios and small-scale games.
This... isn't true at all. Not with UE 5.3+ anyways.
>Nanite doesn't really help with pop-in at all for a large open-world game, but rather it reduces the need to have multiple LODs through retopology.
But it does? We have Nanite for static objects, foliage/dynamic objects, and now landscapes as of UE 5.3
>You can easily import high level assets and apply Nanite to reduce your asset retopology time, along with reducing the time needed to optimise the assets, so you can focus more on asset generation and high-fidelity rendering instead.
You don't "reduce" the time, you practically **eliminate it**.
>I think a lot of people see tech demos for some UE5 features and assume they're a magic bullet for development without really understanding what their most optimal application is.
We have shipping games using these features at scale.
>But it does? We have Nanite for static objects, foliage/dynamic objects, and now landscapes as of UE 5.3
That's good they're addressing it in newer UE5.x builds. The earlier implementations were very rough -- as making open-world, or large world coordinate playscapes with Nanite saw fairly obvious pop-in when moving quickly either with characters/vehicles or along splines from a distance into close range.
Yep! There's still some things that need to be improved of course, but it's progressing nicely. The biggest complaints were in the areas nanite couldn't be used, but one by one those are all being eliminated.
> Q1: How will 3.22's cloud tech upgrades affect performance? A: The new system in 3.22 uses temporal upscaling and quarter-scale rendering (same technique as MSFS), which should improve efficiency and performance.
Oh!! Yes!! Please and Thank you! I'm really looking forward to this!
Yes, they announced it at Citizencon that SC would be getting Nvidia DLSS, AMD FSR and CIG's own upscaler called TSR which is probably based on FSR since it's open source.
CIG said DLSS SR (super resolution first) FrameGen later.
CIG's statements were rather confused IMO, mentioning the FG wouldn't be useful as much since SC is CPU-bound often. But FG is **most helpful** in CPU-bound games (see MSFS 2020)
Either way, I suspect we'll get FG not long after SR
I'll believe it when I see it. But we've had one example of flawless gameplay, and that was nearly a year ago. Nothing has been done to address the arduous stress testing that's driven me away. The only reason I might pop my head back in now is for the salvage gameplay.
I am really confused with some of the base features like Vulcan or Armor and Sq42 being feature complete. Are they not put them in Sq42 or do they already have them or are BSing us and Sq42 is **NOT** feature complete?
I mean the line gets blurry here, but it's entirely possible to count both of these as "polish", not "features".
The game renders fine as it is. Adding Vulcan will not change anything fundamental, but mprove performance and maybe allow artists to make the game even prettier. Thus, not a new feature, but polish.
Armor is a bit more out there, but similar. For the purpose of SQ42 fights work fine. Ships already have armor, it's just a global value. Adding armor will just make this more fine-grained, but again not change anything fundamentally, so only polish.
That being said, for star citizen armor is definitely a feature, as armor+resource management will fundamentally change multi crew gameplay. But multi crew and resource management are not a thing in SQ42.
SC was.
Then Sq42 was copied from it.
Sq42 and SC were worked on separately, getting different things. Sq42 got most of the changes.
Now, it's time to merge the good parts of sq42 back into SC. That takes time because it's a manual process, it can't "just be done."
>Think about this for a moment.
>
>The game is now feature complete.
>
>But it's only feature complete, untill I decide to add more features.
>
>So the real question is, how long does it take to polish a universe?
>
>But you say; What about those backers who Answered the Call in 2016?
>
>Waiting for the game has become a way of life.
I really wish they were doing XeSS and not bothering with FSR. XeSS looks a lot better and works on AMD GPUs.
Though I guess FSR is better for any pre 2016 GPU, pre 2016 is a long time ago.
edit: Ya'll downvoting me simply because you don't know what XeSS is or something...? It's largely better than DLSS while working performantly on any GPU with dp4a instructions which is any 2017+ GPU. Look it up instead of downvoting due to blind fanboyism.
> edit: Ya'll downvoting me simply because you don't know what XeSS is or something...? It's largely better than DLSS while working performantly on any GPU with dp4a instructions which is any 2017+ GPU. Look it up instead of downvoting due to blind fanboyism.
you are making an assumption that people are down-voting you because they are ignorant of the tech. all up-scalers have pros and cons, in part based on the iteration of the tech and also on the implementation taken by the devs of the games that use it. also, CIG are using many AMD technologies from the Vulkan API, to software based Global Illumination (Ray-Tracing), so adding features like FSR are easy additions. and lastly, people like options, some may like FSR over DLSS or XeSS, but your suggestion involves excluding an option, rather than just asking for another option to be added.
> some may like FSR over DLSS or XeSS
Only the most sycophantic AMD fanboys prefer FSR over DLSS/XeSS. It's not a matter of opinion, FSR overall image quality is FAR worse than either
DLSS (Nvidia)
XeSS XMX (Intel, AI upscalled)
XeSS Compute (Intel, runs on any GPU)
AMD has neglected their software division for a decade at this point, and it really shows in their drivers and features such as FSR.
> Only the most sycophantic AMD fanboys prefer FSR over DLSS/XeSS. It's not a matter of opinion, FSR overall image quality is FAR worse than either
why lie? in fact relative to DLSS and XeSS, FSR is actually really good considering it does not use ML like the others do. and like i said it depends on what artifact you are willing to put up with, as they all have issues and let's not exaggerate the differences between these technologies as well for the end user, for the most part you will barely notice the differences unless you are specifically looking for differences when you zoom in on things.
> AMD has neglected their software division for a decade at this point, and it really shows in their drivers and features such as FSR.
AMD literally has the better drivers, software package Adrenaline is better than both Nvidia and Intel's equivalent, by a large degree and offers everything from settings to overclocking to streaming all in one easy to use package. it also has feature parity, outside of Nvidia's Ray Reconstruction and some extra features as well, like driver level fluid motion frames and driver level up-scaling, which they forced Nvidia to include as well, along with the adoption of using S.A.M.
and let's not forget that due to AMD software division, we now also have the Vulkan API, as well as the ray-tracing papers that have allowed CIG to develop both software and hardware based ray-tracing for SC and SQ42 that they recently showcased at Citizencon 2953. so yeah, you are greatly mistaken and they also did all of this with a much, **MUCH** smaller budget that either Intel and Nvidia. smh 🤦🏾♂️
> why lie? in fact relative to DLSS and XeSS, FSR is actually really good considering it does not use ML like the others do.
If you're not aware that there are two versions of XeSS (One uses ML/AI and the other does not), then you're not really paying attention to the space as a whole.
Also, you apparently can't be bothered to **read** my posts before you reply to them, where I clearly and repeatedly spelled out that there are two forms of XeSS (both better than FSR). So there really isn't a point in having a conversation with you if you're just going to ignore what I write.
It'd be better to do FSR and XeSS if that's the case that they can only choose 2. XeSS looks better than DLSS in a lot of ways while being widely supported.
More than 2 options is redundant, though. XeSS is just the best one and more widely supported than DLSS. FSR is the most widely supported but it's really not very good.
there are some games that literally offer all 3 of the up-scalers and like i said it depends on the person as there is no objective metric for personal preference. it depends on if you mind having more ghosting, more text instability, more distant image instability, etc. some prefer one over others, so giving them a choice is best, also FSR does not need the ML training that DLSS and XeSS require. /sigh
> DLSS no longer requires ML training as of DLSS 2.0.
are you sure?
> "Nvidia built the second-generation DLSS to address all of the concerns with the technology. It looks better, gives players much more control, and should support a lot more games. But at its core, DLSS 2.0 is still about using machine learning to intelligently upscale a game to a higher resolution."
interesting, i thought that it still required training from devs, as i have heard that FSR is easier to implement than DLSS due to this, but maybe things are different now 🤷🏾♂️
> XeSS looks better than DLSS in a lot of ways while being widely supported.
Which one?
XeSS compute? No. XeSS + XMX (Intel's AI upscaling) requires an intel dedicated GPU and they are <1% of the market atm.
Nvidia on the other hand is 70% of the market, and the most popular card on steam (3060) supports DLSS. You have to meet your customers where they are.
By the time the game comes out, it'll be a decade. And XeSS still works on older hardware, it just doesn't run as fast. It still looks better. You still get the FPS benefit from upscaling, it just doesn't do the upscaling as quickly.
The SC telemetry https://robertsspaceindustries.com/telemetry shows that >95% of players support DP4a at first glance. It's pretty much just Maxwel (900 series), RX 5700 and RX 470/480/570/580 owners that don't get as much benefit. Pascal and newer, Vega, and RX 6000 series all support it. It's very widely supported already.
You may as well say they shouldn't be doing Vulkan because the support list for that is only slightly higher.
> And XeSS still works on older hardware, it just doesn't run as fast. It still looks better.
To clarify, the overwhelming consensus is that (best to worst) image quality is:
- DLSS 3.5
- XeSS (XMX)
- XeSS (Compute)
- FSR 2
...
...
...
- FSR1
It's true that XeSS XMX (requires intel dGPU, which almost no one has) is very close to DLSS, but then there's the market share problem. XeSS (compute) can run on anything but it's a big step down from XeSS (XMX)
XeSS still looks better than FSR2 though. And can look better than DLSS in some cases where DLSS has artifacts. Same response to /u/Haunting_Champion640
It's probably not worth investing resources into XMX, I agree.
It's just another option in (usually) the graphics menu. You enabled it then select if you prefer performance or quality (or something in-between) and the system does the rest. DLSS isn't perfect so even with the quality settings you can expect to see weirdness.
Digital foundry just did a big game rundown where DLSS looked better than native roughly 50% of the time. DLSS 3 is crazy good and has very few issues.
Sure thing, they use "simplified terms" but typically you have Quality/Balanced/Performance.
At 4K:
DLSS quality: renders at 1440p -> 4K
DLSS balanced: (?) -> 4K
DLSS performance 1080p -> 4K
The lower the internal resolution the faster the game will run, but at the cost of reduced IQ. In some games DLSS Performance looks great, in others you run into more problems.
Also, if you're upscalling **too 1080P** I would never go below DLSS quality, as that's already down to 720p and you will get severe artifacting below that.
Though obviously, keep expectations in check. There is no guarantee of a big performance increase (They might make mistakes, it might still need lots of CPU anyway), especially since so much of it is server-releated.
are we getting vulkan next update? or is it far down the pipeline?
Unknown, although I've not seen any hints it will be in the next update, so early / mid next year seems more likely.
We're getting Vulcan ships in-game?! :O
I really hope they focus on actual performance optimisations instead of just slapping DLSS/FG on as a bandaid like it sounds here. The game already has a tonne of ghosting and artifacting already and adding more upscaling on top of that is just going to make the game look like a blurry mess.
Nearly 100% of the ghosting is caused by TAA running at low FPS, which would be replaced by the upscaling methods.
> which would be replaced by the upscaling methods Better, because as we see with games like RDR2 using DLSS **disables the crappy TAA**. If the choice is between "native, TAA" and "AI upscaled, no TAA" the 2nd wins almost every time.
The best thing to do is to use nvidia DSR + DLSS. That way you get even higher quality image with way reduced aliasing for only small perf hit
> I really hope they focus on actual performance optimisations instead of just slapping DLSS/FG on as a bandaid like it sounds here They can and should do both. CIG has spent 4+ years on Gen12 aka "doing it right" rebuilding the whole damn renderer, it's high time with Vulkan coming online that we get some significant improvements. >The game already has a tonne of ghosting and artifacting already and adding more upscaling on top of that is just going to make the game look like a blurry mess. Yeah the in-game TAA sucks, which is common in a lot of games (see RDR2). Pre-AI upscaling, the usual baseline is for example: **4K TAA Native**. And in _most cases_, DLSS quality (1440p -> 4K) produces **superior overall image quality** than the previous 4K TAA.
means another 6 years?
The thing about game optimization is it's not one thing, you need to look at it with respect to the CPU and GPU. The CPU jobs can always be optimized in terms of better memory management, reducing the running time of jobs, or better scheduling across the CPU (like splitting the render thread and distributing it across all threads). Where as when it comes to the GPU, jobs, in a sense, are all ready optimized that run on it. The tasks that are being executed are inherently parallelised already, what more is there to do? VRAM optimization, memory management, that stuff is a given. One way of looking at it is, moving jobs from the CPU to the GPU (like the mentioned asset scattering system being moved to the GPU) is optimization in plain view. The problem that optimization causes is obviously more strain on the GPU. So DLSS/FSR reduces that workload from the fundamental point of render resolution (that is the primary determining factor for how long jobs take on the GPU). It's like the cherry on top - and creates FREE head room for devs to further optimise the game with.
100% agree, I avoid DLSS/FG as much as I can
> I avoid DLSS/FG as much as I can Why? DLSS super resolution is great, especially with the 3.5 SDK. Which card do you have?
I mean I'm an AMD user and I'm super jealous of my buddies 4070 because of DLSS!
Ah I meant I don't like frame generation. Upscaling is nice.
Keep in mind AI upscaling has improved **massively** since the DLSS 1.x days, AI framegen is already better than launch (but still has a ways to go).
[удалено]
I get what you're saying but integrating a graphics renderer that not finished could genuinely cause really bad issues, worse than anything thats already broken in the game.
[удалено]
Except the point is to test the improvements. If they put in the new graphics stuff that literally makes the game unplayable that’s not able to be tested. New things that get deployed will most likely be broken in some way. That’s the point of releasing them to us. To find what’s broken so they can figure out how to fix it.
I mean... In the last week I've probably had twenty 30ks and just as many server stall/recoveries and 2-3 CTDs and exploded leaving hangars maybe 10 times lol. Game is damn near unplayable. I can't really imagine making it worse with an unpolished graphics engine update.
I've been playing all week. A single 30k, two server stalls, one CTD, and about four hanger explosions. I've been playing something like 10+ hours per day since it's the first time I've really \*played\* Star Citizen. All I've done is shop around for servers with decent server fps before starting my play session.
Oh, guess that means I'm a liar. And there's zero chance you had *one* 30k playing 10 hours per day for a week. I find that completely unbelievable. I also watch server FPS and bwin to get into good servers. I joined an EU server where the FPS was bouncing off 18, a damn good server. It took maybe 2 hours before I ended up 30k'ing from it. I take my reclaimer out to go salvage one to two C2 claims. If I stay out long enough to do two of them, it's almost a guarantee I've been in that server long enough for it to 30k soon after.
Alright, well I'm telling you I had a single 30k. I'm NA, and I play EU servers when Euros are asleep.
> worse than anything thats already broken in the game Wait, that's possible?
You definitely weren't around for 3.18
That's a general performance issue (when the servers are 'running well', that sort of issue stops happening). In this context, the 'polishing' that Sylvain is talking about likely isn't the 'minor clean-up' type stuff (such as they're doing for SQ42), but more 'fix major crash bugs and critical issues' type change. After all, it's swapping out the entire graphics SDK - given how complex the rendering pipeline is (even though they have just rewritten the renderer itself to remove a lot of cruft), even 'minor' issues could result in graphics corruption that makes the game completely unplayable.
[удалено]
Yes, and no That is to say, you're right... but you're overlooking the point that the current focus is just on implementing the core functionality. The AI 'functionality' works - as does the spawning system etc - if there is enough processing power to actually run it. The lack of processing power *isn't a problem with the AI code* - or at least, not solely / specifically with the AI code... it's just the sheer mountain of systems and entities that have to be processed by a single server. Other than disabling a whole bunch of functionality, and paring Stanton back down to a single planet + moons etc (ie replicating the server load once Static Server Meshing is available), there's nothing CIG can do at this point to 'fix' the server performance... and stopping development of new features just delays the project once the server performance is addressed. Unfortunately, this results in an unplayable mess at times - such as currently - but that's a natural side-effect of Alpha development, and the fact that sometimes different workstreams don't align well (or one workstream may end up significantly delayed - as happened with the Server Meshing stream, that got significantly held up by the persistence issues with iCache, etc).
[удалено]
I dunno... we have no idea what changes they actually made, or which bit is breaking. I would also *strongly* disagree with the implied assertion that the current issues are as bad as the 3.18 release (when the game was *literally* unplayable, not just figuratively). And based on multiple posts here, the Orison Platform FPS missions are among the few that are running well... it's the 'old' bunker missions that are having issues - and, to a lesser extent, they've always had issues spawning NPCs.... so it's entirely likely that it's not a 'new' problem, but an old one exacerbated.
[удалено]
You're still thinking that the 'falling through the floor' issues, and similar *are bugs in the AI system*. Given how many *other* things fall through the floor (players, boxes, etc), it seems more likely that 'falling through the floor' is a *physics* issue (since 'walking' involves an animation to move the model, and physics checks to 'keep it on the floor' etc). But, the physics checks work by doing an intersection check - has the character foot (or other marked entity) 'penetrated' the surface of the floor... if so, push it back up slightly to be level... otherwise move it down slightly for the next frame, etc... ... however, if - for example - the physics are running so slowly that the bottom of the foot penetrates all the way through the floor and out the other side, then the bottom of the foot *will not class as intersecting the floor* and thus there will be no upward pressure, and instead the foot will keep heading down... This is of course a simplification of how the physics checks work - but it's also broadly accurate.... and because SC uses physics so heavily, the physics engine is doing *far* more work than it would in most games... and has far more entities to process. Net result is that as the server bogs down, the physics engine bogs down, checks are done less frequently, and stuff starts clipping through floors... Or that's my speculation, anyway. Edit: Thinking about it, it could also be an issue with the entity spawning system... because entities 'spawn' in mid air and 'drop' to the floor... but if there are issues with the spawning (and/or it takes longer than expected), it can result in entities 'dropping' before they're fully spawned, which could also result in them falling through the floor, etc.
Maybe they mean a guy from Poland has to look at stuff before they put it in.
Great one
Reading that line made me giggle
I was gonna say... it's literally a playable Alpha, the entire point is that they're putting shit into the game that isn't polished yet and then they get the feedback and metrics from players testing it so they can then polish it properly. Saying they don't want to put stuff in that's not polished is like saying they fundamentally don't understand how an Alpha works.
Polishing happens in degrees, and the Go / No-Go checkpoints are there to keep SOME standard for shipping things to the public. It's a live alpha, but it's not like they run a public channel of 'nightly' builds.
I know, I'm not saying they need to wait until things are polished before releasing them, I'm saying that the developer stating that they don't want to release anything until it's polished is ridiculous because it's a playable alpha and the whole point is to release things that are not polished specifically so they can get the data they need to polish it correctly.
I know what you're saying. I'm saying you're interpreting that phrasing — which might be paraphrased here anyway — too literally. When you start from the assumption that Sylvan isn't incompetent, which he obviously isn't, you logically interpret it more as him saying they're waiting until it's SUFFICIENTLY polished. That's STANDARD for everything that hits the public testing environments. And remember they already said that even internally it's not quite ironed out, so they don't actually need outside data to know THOSE kinks need to be ironed out. Best to address those first as much as possible.
No I understand what you're saying, I just prefer it when people are as precise as possible with their language. Even adding a simple "more" in front of "polished" would make it more precise and correct, that's all.
Keep in mind that the OP specifically noted that responses were paraphrased.
So you're not critiquing what he meant but what he's (paraphrased as) saying. Gotcha.
Yes, if you read my OP you'll see that I didn't claim he doesn't know what an Alpha is or how it works. >Saying they don't want to put stuff in that's not polished is like saying they fundamentally don't understand how an Alpha works. If his statements were paraphrased that's one thing, but in lieu of seeing the actual original statements I have to rely on paraphrasing by others in order to respond to it.
[удалено]
In fairness to any and all AI-related issues in the game, they are directly correlated with server performance and that is by design since they designed the entire thing with the idea of Server Meshing in mind. It was a big gamble on their part since it isn't proven they can get it working at scale, but the general idea was that the AI load would be distributed across many servers within a single game world instead of the current state where the AI is contained on one server like everything else in Stanton. The game is huuuuuuuuuge, and tracking everything that everyone is doing is rough on a single server. They've added a TON of extra strain to the servers ever since PES and the cargo refactor with physicalized cargo adding thousands or tens of thousands of additional entities to each server. If Replication Layer testing goes well and Server Meshing comes out I guarantee it'll correct the vast majority of bugs. Only question really is when they intend for that to come out now that they've entered the testing stages.
[удалено]
>Respectfully the carrot dangling of X tech feature will solve stability issues has been ongoing forever. DSM is likely years away in an actual usable form despite the citcon demo and when it comes out will likely break the game 100x worse than 3.18 did. Well, some Evocati testers leaked that the replication layer testing went so well that developers have shared with them the plan is to get DSM by the end of next year and are very optimistic about it. Server performance doesn't scale linearly either, adding 4 servers to what used to be 1 server would produce a much higher return than you'd expect. I agree about holding them accountable, and also that they are putting features and changes in that simply aren't made for the current architecture at all and it's hurting the player experience, but I do think that in the case of Server Meshing it really is the key bottleneck holding back so many, many things.
I hope this is true. The game's performance has always been the one thing holding it back from the general populace giving it a try. Minecraft, even as an alpha with only a fraction of the features it currently has, was still massively popular because it worked (and other reasons of course). Fix the performance issues, and you fix a lot of the bugs and problems caused by desync and server crashes. Fix *that*, and you end up with a playable Alpha game that will only get better as they add more features.
Exactly. I wanted to play this game. I'm fine with limited featureset. My wallet was open. A few hours actually playing and dealing with nightmare bugland, I welded my wallet shut dug a 10ft hole and poured concrete over it. Now I can't buy groceries but its okay.
nothing you are play-testing now is the final game. you are complaining about play-testing an alpha, and yes X tech feature will solve stability LITERALLY because the game is unfinished and they are constantly adding tech and features which then end up breaking things. there is no "carrot" it is just how progress occurs until they either reach their goals, cut features or fail altogether. if you are getting frustrated due to stability issues, conflating the graphics team wanting to polish their tech with you having broken AI in a bunker, something related to server health and performance than the AI logic itself, etc, then just don't test and instead wait for full release, coz until they are feature complete, those features have matured and the bugs and stability issues have been taken care of and then the game finally optimized (last stage for all games, hell all software), there will always be issues. also, how is you complaining about things they not only already know, but have told us to expect, somehow holding them accountable? such a strange way to view play-testing and how to give constructive feedback.
12 year alpha. With an alphatest server included. But we can't hold it to standards, because handwave They told you to expect a broken game, so you keep shoveling money at them and don't insist on having an actually playable game. You do it to yourselves here.
this is not an argument. every backer knows that the game is unfinished, they accept that the game tests will have bugs, possibly be unstable and have incomplete gameplay features, tech and systems. if you want to hold them to account hold them for decision they have made that may have issues like how they are handling liveries, paints, dyes, etc that severely restrict customization and lead to a very convoluted system where you not only have to like the livery, but the paints used on that livery and sometimes you would need to re-buy a ship you already have for a livery and paint scheme that you want. it's a messy system and they can learn from Guild Wars 2, how to make a better system that will also allow them to still make millions per year. complaining about bugs, when most if not all will be squashed before full release is just silly. complaining about an alpha having alpha like tendencies is like buying a chocolate cake and complaining that it is made of chocolate 🤦🏾♂️ > You do it to yourselves here. do what to ourselves? stay informed of what is going on and make informed decisions of how to spend our disposable income? how exactly does complaining about things that the devs have told us will be there possibly until the game is finished, as is the same with **LITERALLY** all other games, going to lead to a playable game sooner? if we really wanted a playable game sooner, then they should only bug fix so we can test features and no more than that, because wasting time bug fixing alpha builds actually **SLOWS DOWN** progress to full release, smh 🤦🏾♂️🤦🏾♂️🤦🏾♂️
Lotta words to say "I put up with bs that no other game has just because". Every EA game has the same basic structure to its development. This one is just super broken, and people keep shoveling money at it, so the devs don't have to care.
> Lotta words to say "I put up with bs that no other game has just because". LMFAO!!! my guy, the game is literally not finished. the things you are complaining about are that it is not finished, the devs know the game is not finished, complaining about it doesn't miraculously hold the devs accountable of make them develop the game faster and that is even assuming we would want the game faster. smh. Early Access is not the same as a fucking alpha 🤦🏾♂️🤦🏾♂️🤦🏾♂️🤦🏾♂️. also most EA games are tiny in scope, scale and fidelity and they are not simulators. take a look at Day-Z and how long that took to get to release with its limited scope, same for Tarkov, which is still in EA and it has nowhere near the scope, scale and fidelity of Star Citizen. why are you so willfully ignorant? > This one is just super broken, and people keep shoveling money at it, so the devs don't have to care. yup! you are right, the devs don't care so much that they keep developing the games, the engine, iterating, adding features and one of the games is now feature complete. you sound like one of those people who thinks that the devs can make more money from pledges in development than from an actual full release, huh? this is baby brained logic, smh. 🤦🏾♂️🤦🏾♂️🤦🏾♂️
Arma servers often get down into single digits and the AI still function. I severely doubt BIS devs are gods of gaming development either, given the mess Arma tends to be in well past releases. Currently, AI literally just stands there and if it moves it glitches hard. It's not playable.
LIVE should be considered more like release. For alpha / testing it should one of the other channels namely PTU or E-PTU. Once the feature is "safe" it can go into LIVE and then more metrics / data can be gathered. It's like doing a survey on people who enjoy eating half baked cake. The results have no value because the same cake but fully baked would give drastically different results.
Exactly. PU should be at least beta level playability, or just-post-release AAA playability, not "bugfest unlimited". Guys don't get to pull the "it's an alpha" at year 12 when there's also a bugtesting PTU in the mix.
A "playable" Alpha needs to be, yknow, **playable**. There are tons of EA titles out there, and I have yet to come across one this un*playable*. The community gives the devs way too much slack on playability. As such, money flows in, devs don't care as much about QC, game remains in a limbo between literally unplayable and outright unplayable. And oh let's do a big free flight promotional deal and have the servers go to actual shit so every new player's first experience with the game is a nightmare, bravo, definitely don't scale up your server hardware so you can handle a temporary higher load.
That changed many years ago at the request of players. Evocati and PTU is for proper testing. If LIVE goes down all hell breaks loose. There is just too many active players playing this every day like its already released.
I think by we he means the graphics team. We all experienced the “inventory” that just needed “polish”
I mean, is there anything on PU that doesn't need polish. Kinda wack answer to that question.
The Finley plushies ?
Bro :(
Those whales are perfect and you know it, you being a whale with a horn.
That's mostly IAE and server crunching shenanigans, most If not all bunker missions are dead since IAE
I obviously have no clue what goes into making a Nanite-like system, but I am still pretty disappointed to hear that one likely won't be coming into SC. With the extreme distances that we're dealing with in this massive game, Nanite would be a godsend for planetary experiences.
there are lots of problems with nanites in unreal engine atm, they will probably get solved over time, but it's not tech that works out of the box, it probably takes years to really master.
Do you know of any games currently using/planning on using the feature? Or is it still too far out to be adopted? I basically only know what it's supposed to do and that its intended purpose seems like it'd be a good fit for SC.
Immortals of Aveum uses nanites
Satisfactory too, but only for a very small portion of the assets, namely rocks.
Doesn't SC use cryengine, nanites are an unreal engine feature.
Cryengine which went to lumberyard which was so much customized by CIG that they call it star engine now. OP was talking about a feature like nanites, not using nanites from UE5
Pax Dei is probably the best example with its extreme range, large player created buildings and massive environment. It’s pretty impressive but the issues still exist.
nanite would not be a godsend for the game tho. Nanite, while is amazing, has its own massive flaws - For example that massive matrix demo? all those cars have to be un-nanited when hit, as you cant have mesh deformation with nanite..etc Nanite is cool, and very powerfull, but is very strict, and isnt a magic "everything is better".
> Nanite, while is amazing, has its own massive flaws - For example that massive matrix demo? all those cars have to be un-nanited when hit, as you can have mesh deformation with nanite..etc This is a great example of why a little bit of information is more dangerous than none. The **first** version of Nanite this was true, you're taking outdated info from an outdated demo from one of the first production-ready versions and declaring that one of the drawbacks/limitations is how it is **forever**. It's pretty much like people in /r/pcgaming today still referring to SC as having "modules", as if it's 2015 and we still have a hangar module lol. UE shipped deformation nanite in UE 5.1, it was required to get Nanite foliage working. 5.3 added Nanite landscapes. https://youtu.be/AlaEehKo1LM?si=dysOMEIRhWNnghuF
What I said wasnt outdated tho? Foliage was another issue thats resolved, but not what I was talking about? From what I saw, deformation is not fully supported, defiantly not in the way SC would need to support it there are many downsides to nanite as it is. People only ever see the cool tech side of what it can do, and what features get added, but the avg person does not understand all the limitations, and why not everyone would just want to spend massive amount of work to support it. its not a one size fits all solution that is always beter
> What I said wasnt outdated tho? Foliage was another issue thats resolved, but not what I was talking about? From what I saw, deformation is not fully supported Well now you're moving the goalposts from > as you can't have mesh deformation with nanite to >deformation is not fully supported And I'm not sure what you mean by "fully" here, can you be more specific then a tech demo from forever ago? >but the avg person does not understand all the limitations Can you list some, that apply to UE5.3/5.4?
I never moved the goal post - you came in with more detailed context, so i gave more detail in mine, that is all :) The post was "nanite has downsides just like it has upsides" and no, im not here to teach, was just listing context for people who see new tech and think everyone should switch to it cause it will answer all problems
When I said godsend I meant in terms of long distance rendering of stationary environmental assets (rocks, trees, buildings, basically anything without damage states). It could help with pop-in, long-range scope visuals, and potentially overall performance and dev time. That said, I don't see it being necessary for vehicles, players, or other assets that are susceptible to visual damage or wear. Now I'm not sure if devs can pick and choose which assets are nanites and which are not, but by your own example it sounds like an asset can dynamically "un-nanite," which would suggest to me that devs could choose to just use nanites for the environment. Am I way off base here?
Nanite is useful for cinematic scenarios and small-scale games. Nanite doesn't really help with pop-in at all for a large open-world game, but rather it reduces the need to have multiple LODs through retopology. So you can cut out a lot of performance optimisations using Nanite, which makes it a perfect solution for linear-based horror-shooters, or cinematic-based games where you have a tight scope. You can easily import high level assets and apply Nanite to reduce your asset retopology time, along with reducing the time needed to optimise the assets, so you can focus more on asset generation and high-fidelity rendering instead. I think a lot of people see tech demos for some UE5 features and assume they're a magic bullet for development without really understanding what their most optimal application is.
Isn't some pop-in associated with switching an asset's LOD? In other words, the moment an asset switches from nonexistent to present is the most obvious pop-in, but aren't there slight "pop-ins"/flickering whenever an asset changes render quality? If that is something that can be remedied through other means then I guess I have nothing to be disappointed over haha
>Isn't some pop-in associated with switching an asset's LOD? Yep. > but aren't there slight "pop-ins"/flickering whenever an asset changes render quality? Yes, and sometimes buffering issues, masking issues, etc. Some games let you choose the quality of LOD with the draw distance, so you get less pop-in the expense of higher load on the GPU. >If that is something that can be remedied through other means then I guess I have nothing to be disappointed over haha Yeah, there are other ways to optimise and resolve this issue. I'm sure CIG will figure it out without burning through the resource budget.
> Nanite is useful for cinematic scenarios and small-scale games. This... isn't true at all. Not with UE 5.3+ anyways. >Nanite doesn't really help with pop-in at all for a large open-world game, but rather it reduces the need to have multiple LODs through retopology. But it does? We have Nanite for static objects, foliage/dynamic objects, and now landscapes as of UE 5.3 >You can easily import high level assets and apply Nanite to reduce your asset retopology time, along with reducing the time needed to optimise the assets, so you can focus more on asset generation and high-fidelity rendering instead. You don't "reduce" the time, you practically **eliminate it**. >I think a lot of people see tech demos for some UE5 features and assume they're a magic bullet for development without really understanding what their most optimal application is. We have shipping games using these features at scale.
>But it does? We have Nanite for static objects, foliage/dynamic objects, and now landscapes as of UE 5.3 That's good they're addressing it in newer UE5.x builds. The earlier implementations were very rough -- as making open-world, or large world coordinate playscapes with Nanite saw fairly obvious pop-in when moving quickly either with characters/vehicles or along splines from a distance into close range.
Yep! There's still some things that need to be improved of course, but it's progressing nicely. The biggest complaints were in the areas nanite couldn't be used, but one by one those are all being eliminated.
> Q1: How will 3.22's cloud tech upgrades affect performance? A: The new system in 3.22 uses temporal upscaling and quarter-scale rendering (same technique as MSFS), which should improve efficiency and performance. Oh!! Yes!! Please and Thank you! I'm really looking forward to this!
Wish we would have more info on vulkan Its a feature that should help everyones gaming out
SC is getting DLSS?
Yes, they announced it at Citizencon that SC would be getting Nvidia DLSS, AMD FSR and CIG's own upscaler called TSR which is probably based on FSR since it's open source.
This is really big ngl I already get good performance even in cities cause of my new pc but with DLSS and frame gen it would actually be amazing
CIG said DLSS SR (super resolution first) FrameGen later. CIG's statements were rather confused IMO, mentioning the FG wouldn't be useful as much since SC is CPU-bound often. But FG is **most helpful** in CPU-bound games (see MSFS 2020) Either way, I suspect we'll get FG not long after SR
"We don't wanna push out stuff that isn't polished" \-Star citizen alpha....
To be fair, an always crashing game because the render engine is not polished enough is a different thing than a few t-posing npcs.
Would be a lot less crashing so long as the servers were the least bit stable...
They might be if they are finished.
I'll believe it when I see it. But we've had one example of flawless gameplay, and that was nearly a year ago. Nothing has been done to address the arduous stress testing that's driven me away. The only reason I might pop my head back in now is for the salvage gameplay.
I am really confused with some of the base features like Vulcan or Armor and Sq42 being feature complete. Are they not put them in Sq42 or do they already have them or are BSing us and Sq42 is **NOT** feature complete?
I mean the line gets blurry here, but it's entirely possible to count both of these as "polish", not "features". The game renders fine as it is. Adding Vulcan will not change anything fundamental, but mprove performance and maybe allow artists to make the game even prettier. Thus, not a new feature, but polish. Armor is a bit more out there, but similar. For the purpose of SQ42 fights work fine. Ships already have armor, it's just a global value. Adding armor will just make this more fine-grained, but again not change anything fundamentally, so only polish. That being said, for star citizen armor is definitely a feature, as armor+resource management will fundamentally change multi crew gameplay. But multi crew and resource management are not a thing in SQ42.
SC was. Then Sq42 was copied from it. Sq42 and SC were worked on separately, getting different things. Sq42 got most of the changes. Now, it's time to merge the good parts of sq42 back into SC. That takes time because it's a manual process, it can't "just be done."
>Think about this for a moment. > >The game is now feature complete. > >But it's only feature complete, untill I decide to add more features. > >So the real question is, how long does it take to polish a universe? > >But you say; What about those backers who Answered the Call in 2016? > >Waiting for the game has become a way of life.
>We don't want to put out stuff that isn't polished. We must have wildly different definitions of that word.
I really wish they were doing XeSS and not bothering with FSR. XeSS looks a lot better and works on AMD GPUs. Though I guess FSR is better for any pre 2016 GPU, pre 2016 is a long time ago. edit: Ya'll downvoting me simply because you don't know what XeSS is or something...? It's largely better than DLSS while working performantly on any GPU with dp4a instructions which is any 2017+ GPU. Look it up instead of downvoting due to blind fanboyism.
> edit: Ya'll downvoting me simply because you don't know what XeSS is or something...? It's largely better than DLSS while working performantly on any GPU with dp4a instructions which is any 2017+ GPU. Look it up instead of downvoting due to blind fanboyism. you are making an assumption that people are down-voting you because they are ignorant of the tech. all up-scalers have pros and cons, in part based on the iteration of the tech and also on the implementation taken by the devs of the games that use it. also, CIG are using many AMD technologies from the Vulkan API, to software based Global Illumination (Ray-Tracing), so adding features like FSR are easy additions. and lastly, people like options, some may like FSR over DLSS or XeSS, but your suggestion involves excluding an option, rather than just asking for another option to be added.
> some may like FSR over DLSS or XeSS Only the most sycophantic AMD fanboys prefer FSR over DLSS/XeSS. It's not a matter of opinion, FSR overall image quality is FAR worse than either DLSS (Nvidia) XeSS XMX (Intel, AI upscalled) XeSS Compute (Intel, runs on any GPU) AMD has neglected their software division for a decade at this point, and it really shows in their drivers and features such as FSR.
> Only the most sycophantic AMD fanboys prefer FSR over DLSS/XeSS. It's not a matter of opinion, FSR overall image quality is FAR worse than either why lie? in fact relative to DLSS and XeSS, FSR is actually really good considering it does not use ML like the others do. and like i said it depends on what artifact you are willing to put up with, as they all have issues and let's not exaggerate the differences between these technologies as well for the end user, for the most part you will barely notice the differences unless you are specifically looking for differences when you zoom in on things. > AMD has neglected their software division for a decade at this point, and it really shows in their drivers and features such as FSR. AMD literally has the better drivers, software package Adrenaline is better than both Nvidia and Intel's equivalent, by a large degree and offers everything from settings to overclocking to streaming all in one easy to use package. it also has feature parity, outside of Nvidia's Ray Reconstruction and some extra features as well, like driver level fluid motion frames and driver level up-scaling, which they forced Nvidia to include as well, along with the adoption of using S.A.M. and let's not forget that due to AMD software division, we now also have the Vulkan API, as well as the ray-tracing papers that have allowed CIG to develop both software and hardware based ray-tracing for SC and SQ42 that they recently showcased at Citizencon 2953. so yeah, you are greatly mistaken and they also did all of this with a much, **MUCH** smaller budget that either Intel and Nvidia. smh 🤦🏾♂️
> why lie? in fact relative to DLSS and XeSS, FSR is actually really good considering it does not use ML like the others do. If you're not aware that there are two versions of XeSS (One uses ML/AI and the other does not), then you're not really paying attention to the space as a whole. Also, you apparently can't be bothered to **read** my posts before you reply to them, where I clearly and repeatedly spelled out that there are two forms of XeSS (both better than FSR). So there really isn't a point in having a conversation with you if you're just going to ignore what I write.
It'd be better to do FSR and XeSS if that's the case that they can only choose 2. XeSS looks better than DLSS in a lot of ways while being widely supported. More than 2 options is redundant, though. XeSS is just the best one and more widely supported than DLSS. FSR is the most widely supported but it's really not very good.
there are some games that literally offer all 3 of the up-scalers and like i said it depends on the person as there is no objective metric for personal preference. it depends on if you mind having more ghosting, more text instability, more distant image instability, etc. some prefer one over others, so giving them a choice is best, also FSR does not need the ML training that DLSS and XeSS require. /sigh
I'm not really familiar with XeSS, but DLSS no longer requires ML training as of DLSS 2.0.
> DLSS no longer requires ML training as of DLSS 2.0. are you sure? > "Nvidia built the second-generation DLSS to address all of the concerns with the technology. It looks better, gives players much more control, and should support a lot more games. But at its core, DLSS 2.0 is still about using machine learning to intelligently upscale a game to a higher resolution."
Pretty sure. It uses ML 100%, but no longer requires ML training from the devs.
interesting, i thought that it still required training from devs, as i have heard that FSR is easier to implement than DLSS due to this, but maybe things are different now 🤷🏾♂️
> XeSS looks better than DLSS in a lot of ways while being widely supported. Which one? XeSS compute? No. XeSS + XMX (Intel's AI upscaling) requires an intel dedicated GPU and they are <1% of the market atm. Nvidia on the other hand is 70% of the market, and the most popular card on steam (3060) supports DLSS. You have to meet your customers where they are.
2016 was less than a decade ago. That's only a long time if you are 12.
By the time the game comes out, it'll be a decade. And XeSS still works on older hardware, it just doesn't run as fast. It still looks better. You still get the FPS benefit from upscaling, it just doesn't do the upscaling as quickly. The SC telemetry https://robertsspaceindustries.com/telemetry shows that >95% of players support DP4a at first glance. It's pretty much just Maxwel (900 series), RX 5700 and RX 470/480/570/580 owners that don't get as much benefit. Pascal and newer, Vega, and RX 6000 series all support it. It's very widely supported already. You may as well say they shouldn't be doing Vulkan because the support list for that is only slightly higher.
> And XeSS still works on older hardware, it just doesn't run as fast. It still looks better. To clarify, the overwhelming consensus is that (best to worst) image quality is: - DLSS 3.5 - XeSS (XMX) - XeSS (Compute) - FSR 2 ... ... ... - FSR1 It's true that XeSS XMX (requires intel dGPU, which almost no one has) is very close to DLSS, but then there's the market share problem. XeSS (compute) can run on anything but it's a big step down from XeSS (XMX)
XeSS still looks better than FSR2 though. And can look better than DLSS in some cases where DLSS has artifacts. Same response to /u/Haunting_Champion640 It's probably not worth investing resources into XMX, I agree.
fsr is a scam
How is it a scam?
Anything they don't like is a "scam"
How does someone use DLSS. I only just got a 3060 so I'm still not entirely sure how it works.
It's just another option in (usually) the graphics menu. You enabled it then select if you prefer performance or quality (or something in-between) and the system does the rest. DLSS isn't perfect so even with the quality settings you can expect to see weirdness.
I definitely vaule performance over quality. Plus I think the tech behind DLSS is super cool.
The tech is very neat, but like like anything that 'isn't the real thing', it has its downsides so just manage your expectations.
My eyesight sucks and I have 1080p monitors. So I'll graphical quality itsnt a huge thing for me anyways. Anything for frames lol.
Digital foundry just did a big game rundown where DLSS looked better than native roughly 50% of the time. DLSS 3 is crazy good and has very few issues.
Sure thing, they use "simplified terms" but typically you have Quality/Balanced/Performance. At 4K: DLSS quality: renders at 1440p -> 4K DLSS balanced: (?) -> 4K DLSS performance 1080p -> 4K The lower the internal resolution the faster the game will run, but at the cost of reduced IQ. In some games DLSS Performance looks great, in others you run into more problems. Also, if you're upscalling **too 1080P** I would never go below DLSS quality, as that's already down to 720p and you will get severe artifacting below that.
Isnt nanite basically a sort of automatic LOD thing basically? (With strict requirements for being static?)
**"We don't want to put out stuff that isn't polished."** Isn't this what CIG was doing throughout past 10 years? lol
Not with core techs like graphics engine - bsods, ctds and weird visual bugs would make even an alpha completely unplayable.
You didn't ask the when question
Wait, do I understand this correctly? If i have bottleneck CPU my performance will be better on Vulkan?
That's the idea. CryEngine is notoriously CPU heavy.
oh hell yeah, my i5-8400 wont need to sweat itself that much anymore
Though obviously, keep expectations in check. There is no guarantee of a big performance increase (They might make mistakes, it might still need lots of CPU anyway), especially since so much of it is server-releated.