Search Unity

  1. We are migrating the Unity Forums to Unity Discussions. On July 12, the Unity Forums will become read-only.

    Please, do not make any changes to your username or email addresses at id.unity.com during this transition time.

    It's still possible to reply to existing private message conversations during the migration, but any new replies you post will be missing after the main migration is complete. We'll do our best to migrate these messages in a follow-up step.

    On July 15, Unity Discussions will become read-only until July 18, when the new design and the migrated forum contents will go live.


    Read our full announcement for more information and let us know if you have any questions.

[Open Source] FSR 3.0 Upscaler for Unity (BIRP, DX11, PPV2, multi-platform)

Discussion in 'Assets and Asset Store' started by Astfgl, May 15, 2023.

  1. Astfgl

    Astfgl

    Joined:
    Jan 19, 2014
    Posts:
    87
    [Github]​

    Hey all,

    These past few months I have been working independently on researching FidelityFX Super Resolution 2 (or FSR2 for short) and seeing if I could make it work within Unity. My goals were rather specific: I wanted to make it work with Unity's built-in render pipeline, Post-Processing Stack V2 and the older DX11 graphics API, as well as on Mac, Linux and consoles.

    When starting out I had no idea if this was possible at all. After all, FSR2 is generally associated with more modern PC graphics APIs (DX12 and Vulkan) and more advanced rendering pipelines. My particular needs were the driving force for how I approached this project and they called for some unorthodox solutions. I was half-expecting to run into some insurmountable roadblocks and having to give up halfway through, but to my pleasant surprise I managed to make FSR 2.2 work, in Unity, on the built-in render pipeline, with DX11 and even on Linux, MacOS, and both 8th gen and 9th gen consoles. And the results are, well, rather spectacular:



    Compared to the standard post-process anti-aliasing methods offered by Unity (FXAA, SMAA and TAA), FSR 2.2 produces a much sharper and cleaner picture, with better sub-pixel detail resolution, far less temporal shimmering and no unsightly ghosting artifacts in fast motion. In addition to that, because FSR2 upscales from lower internal rendering resolutions, you will see improved framerates even when compared to having no AA. This is a major boon for games that are GPU-bottlenecked, as it will improve both image quality *and* performance.

    While I did work on FSR2 for Unity with a specific game in mind (more on that later), I developed this plugin as a standalone project with the intention of open sourcing it and allowing anyone to play around with it. And so that is what I'm doing now: the source code of FSR2 for Unity is available on Github right now, licensed under MIT meaning you are free to do whatever you like with it. More details on how this implementation works can be found on the Github page.

    Right now this project only offers an integration with the built-in render pipeline. The core FSR2 implementation however is render pipeline-agnostic, so there's nothing stopping anyone from building a URP or HDRP integration based on the same core classes.

    I have also been testing this with Unity's Post-Processing Stack V2 (PPV2) to make sure the two play well together. While this does work, the setup is not ideal yet: PPV2 currently has to run entirely before FSR2 which works fine for most effects, but ideally effects like bloom, depth of field and motion blur should be applied after FSR2's upscaling. It still produces rather nice results though:



    I have spent some time trying to adapt FSR2 into a PPV2 post effect, but it seems PPV2's framework is a bit too rigid to make this work well. The way I'm looking at it now, I think the best way forward would be to modify PPV2 itself and customize it to make it upscaling-aware, to add FSR2 as an alternative anti-aliasing method, and to split the existing built-in effects into before- and after-upscaling steps. This is something of a project in itself, but I hope to look into this in the near future.

    As I mentioned, I worked on this project with a specific game in mind and I have been collaborating with its creators over the past couple of months to integrate FSR2 into that game, after demonstrating my initial results. I cannot divulge right now which game that is, but rest assured that this implementation is already being battle tested. Hopefully within the next few weeks I can tell you which game it is and I'll also be able to show you better comparison pictures.

    [edit]
    The game in question is Isonzo, more details and screenshots in the post below.

    Before anyone asks, I am aware of what Alterego Games are working on and it is not my intention to 'compete' with or in any way undermine what they're doing. I felt justified in working on my own project because my priorities (focus on built-in render pipeline, DX11, Mac, Linux and console support) did not appear to align entirely with what they're committing to, at least not initially. I also couldn't be sure if their approach to integrating FSR2 into Unity would work for the game I had in mind. You should see my project more as a tinkerer's version of FSR2 for Unity; if you're not afraid to get your hands dirty and adapt it to work for your particular application, then you might find a good starting point here. If you're looking for something more plug-and-play, more polished and with a better guarantee of long-term support, then you will want to keep an eye on Alterego's project. The way I see it, having more options available is never a bad thing.

    Have fun picking this apart! I'm looking forward to seeing all of your reactions.
     
    Last edited: Jun 21, 2023
  2. Dark-1-Games

    Dark-1-Games

    Joined:
    Mar 26, 2014
    Posts:
    101
    Major props for the amazing work!
     
    Astfgl likes this.
  3. Astfgl

    Astfgl

    Joined:
    Jan 19, 2014
    Posts:
    87
    Thanks!

    As you could read in the other thread, Alterego and I have joined forces, which means that their asset will gain the multi-platform advantages from my implementation, while my work will benefit from their URP and HDRP integrations. This should lead to the best of both worlds: FSR 2.2 available for everyone, everywhere.

    In the meantime I have also been testing on mobile platforms and, well:

    IMG_0002.jpg IMG_20230517_114923.jpg

    It's looking very promising. I'll have to do a bit more research and testing before I can confidently say Android and iOS are fully supported, but it's definitely working already.
     
  4. TheDigitalzombie

    TheDigitalzombie

    Joined:
    Feb 22, 2016
    Posts:
    7
    Absolutely awesome! Thank you!

    You already stole 10 hours from me and it's still going. But thats because of my strange setup and not related to the implementation. Ah, I'll get there ...
     
    Astfgl likes this.
  5. pwka

    pwka

    Joined:
    Sep 19, 2012
    Posts:
    49
    Amazing job! Awesome that you made this available to everyone!
    Does this mean that your open source solution will also get options for urp and hdrp?
    Cheers!
     
  6. Astfgl

    Astfgl

    Joined:
    Jan 19, 2014
    Posts:
    87
    Thanks, and you're welcome!

    That is unlikely to happen anytime soon. Of course I don't want to cut into Alterego's sales too much, which would happen if I made open source URP and HDRP integrations. Besides that, my personal experience with URP and HDRP is very limited so making integrations for those would cost me a lot of time for research, time that I think is better spent elsewhere right now.

    The way I'm looking at it now is: the open source project contains the backend of the FSR2 implementation, together with a single reference integration. Alterego's asset will be the 'product' that has all the integrations, is more polished and user-friendly, and that will receive more professional long-term support.
     
    pwka likes this.
  7. pwka

    pwka

    Joined:
    Sep 19, 2012
    Posts:
    49
    Yeah, I still want to buy Alterego's solution. Antialiasing in Unity is getting worse, and FSR is gamechanger in that regard. Thanks for the clarification!
     
  8. Astfgl

    Astfgl

    Joined:
    Jan 19, 2014
    Posts:
    87
    While Alterego Studios have been finishing up their asset (congrats to them on the release!), I have been working on steadily improving the core FSR2 backend code, as well as creating a new integration for the built-in render pipeline. I already alluded to this in my original post:
    I have now fully integrated FSR2 into Unity's Post-Processing Stack V2 codebase and released it as a drop-in replacement package on the Github page. Source code is also available. This gets FSR2's placement in the render pipeline much closer to the ideal picture suggested by AMD:

    placement.png

    With this, post-processing effects that should get rendered at full resolution instead of being upscaled, such as bloom, motion blur, depth of field and film grain, are now applied after FSR2 upscaling. This means that previously problematic effects that caused noticeable artifacts are now looking correct. The integration itself also feels much more natural and easier to implement into a project.

    I should note that while this PPV2 package is perfectly usable in its current state, it's not trying to be everything for everybody. It still only supports the built-in render pipeline (URP support for PPV2 was dropped a long time ago), it doesn't support VR (yet) and I'm sure there will be more features currently missing. If you're using BiRP with an unmodified PPV2 package, then this should be easy to drop in. Otherwise, you should see this package as a better example of how to fully integrate the core FSR2 classes into a render pipeline.

    Aside from that, the following work has been done on the core FSR2 implementation since my last post here in this thread:
    • The FSR2 shaders have been updated to FSR 2.2.1
    • The experimental auto-transparency & composition feature that was added in FSR 2.2 has been implemented.
    • The issue where enabling auto-exposure caused a black screen on some platforms has been fixed.
    • The ESRAM-related issue on Xbox One when auto-reactive mask is in use has been fixed.
    • Various optimizations to reduce VRAM usage.
    • Some refactoring to improve clarity and readability.
    I'm also currently working on dynamic resolution support using ScalableBufferManager, and I hope to look into VR soon as well. At the very least, to get an idea of what is required to make VR work with FSR2.
     
  9. Astfgl

    Astfgl

    Joined:
    Jan 19, 2014
    Posts:
    87
    Finally I am able to reveal which title I have been working on these past few months to develop and test this implementation of FSR2. The game in question is Isonzo, part of the WW1 Game Series. Yesterday the update with FSR2 integration was released on Steam. Consoles will follow soon.

    Here is a comparison between No AA, FXAA, TAA and FSR2 Quality & Performance on the Cengio map:
    screenshot-20230310-181529_NoAA.png screenshot-20230310-181550_FXAA.png screenshot-20230310-181601_TAA.png screenshot-20230310-181635_FSR2_Quality.png screenshot-20230310-181659_FSR2_Performance.png

    I have been working as a programmer on the WW1 Game Series team for several years, where I was primarily responsible for producing the console versions. Upon release of Isonzo late last year, I was rather unhappy with the overall image quality and performance that we were able to achieve, particularly on consoles. Unity's anti-aliasing solutions all made the game look worse and all other alternatives we looked into did not work for us for one reason or another. Meanwhile FSR2 had been open sourced shortly before and I knew that would be a great fit for our game, but with all my other responsibilities I simply did not have the time or energy to properly investigate it.

    At the end of last year I ended my tenure on the WW1 team, with the intention of taking some time for myself to work on several research projects. Isonzo's image quality remained a pet peeve of mine however, so properly researching FSR2 for Unity was one of the projects that I wanted to work on. When FSR 2.2 was open sourced in mid-February, that was the trigger for me to genuinely pick up this project and see if I could make it work. And the rest, well, is history.

    Working together with the WW1 team to integrate FSR2 into Isonzo has really helped a lot to quickly get this FSR2 implementation up to speed. It gave me a concrete use case to test my work against, it confronted me with many real-world problems that my prototype projects didn't show, and it gave me a lot of feedback to help fix bugs and to push me to keep improving the quality. It has made the core FSR2 implementation very solid and a good foundation to base other game integrations on.

    The integration in Isonzo is based on the Post-Processing Stack V2 package that I released last week, or rather is backported from it to the older customized version of PPV2 that Isonzo uses. Initially I used the image effect-based integration but that did cause some graphical issues in places. Migrating to the PPV2-based integration cleared up the problems we had with effects like motion blur, and certain full screen overlays like screen flashing, blinking and blindness effects. That finally made the FSR2 feature feel production-ready.
     
  10. Astfgl

    Astfgl

    Joined:
    Jan 19, 2014
    Posts:
    87
    Here is another comparison, this time on the Gorizia map:
    screenshot-20230310-182009_NoAA.png screenshot-20230310-182024_FXAA.png screenshot-20230310-182044_TAA.png screenshot-20230310-182113_FSR2_Quality.png screenshot-20230310-182153_FSR2_Performance.png

    FXAA simply blurs the image, while TAA smooths over a lot of the fine details. FSR2 by comparison keeps things crisp and sharp and brings out a lot more texture detail, even when compared to No AA. Also take note of thin geometry like grass and trees; FSR2 manages to reconstruct those very accurately, leading to much fuller-looking foliage than on any of the alternatives.

    What's not visible in these still shots is just how bad the ghosting artifacts are with TAA in motion. When the first-person weapon model moves across the screen, TAA produces an awful looking ghostly trail behind it that is very noticeable and distracting. FSR2 is not without its motion artifacts either, but instead of a ghost trail it will merely show some pixellation in places that are under-sampled, which is far less distracting. FSR2 also suffers a lot less from shimmering artifacts in motion compared to the other options.

    (The forum only allows a maximum of 5 uploads per post, hence the need for this separate post.)
     
  11. baggyg

    baggyg

    Joined:
    Nov 21, 2013
    Posts:
    30
    Sounds very progressive on all fronts. Between yourself and Alterego, do you think we could see VR support any time soon?
     
  12. Astfgl

    Astfgl

    Joined:
    Jan 19, 2014
    Posts:
    87
    I looked into VR a while back and quickly came to the conclusion that VR support in Unity is a complete mess that's shoehorned into the different rendering and post-processing pipelines in a multitude of awkward ways. That makes it hard to know where to even begin with integrating FSR2.

    I think the best way forward would be to generalize the texture array input/output support that I already added for HDRP some time ago, and then leaving it to each render pipeline integration to manage which buffers and array indices get passed to FSR2 and when. That means the core FSR2 dispatching code won't really have to know about VR, it just gets some buffers that it needs to upscale. Any other approach would massively over-complicate the core FSR2 classes and make it that much harder to maintain.

    Anyway, I guess what I'm trying to say is that VR support is not a trivial thing; it will require a bunch more research and each render pipeline and stereoscopic rendering variant will have to be considered separately.
     
    baggyg likes this.
  13. blaher

    blaher

    Joined:
    Oct 21, 2013
    Posts:
    80
    This is awesome.... though motion is rough on moving plants. I read the section about motion vectors... any links or info on how to go about "rendering motion vectors" or what you mean by this? is this something in hdrp only? any way to fix blurry motion/ghosted mess of plants w built in render pipe?
     
  14. blaher

    blaher

    Joined:
    Oct 21, 2013
    Posts:
    80
    Agree re Unity VR. My Fractal raymarcher game began around 5 years ago... I've honestly forgotten what version of unity I started on, but the OG VR support the raymarcher worked well on oculus1. Every version of unity since broke my raymarch shader in some new way. I eventually gave up trying to keep it VR functional. I've spent months of effort trying to figure out what they busted until it just wasn't worth it to do again as several times I've modified the shader to fix it just broke again in a new way next unity version.
     
    AcidArrow likes this.
  15. Astfgl

    Astfgl

    Joined:
    Jan 19, 2014
    Posts:
    87
    Yeah, motion vectors are essential for FSR2 to do its job properly, and sadly there are a lot of rendering packages out there that don't include motion vector support.

    For Isonzo we're using The Vegetation Engine, which also doesn't support motion vectors out of the box. My first temporary solution was to disable wind effects on vegetation, which did the trick but obviously the artists were not happy about the completely dead and static foliage. We had to go in and manually add a motion vector pass to TVE's shaders, based on Unity's standard motion vector shader, adapted to use TVE's vertex animation and alpha cutoff logic. With that in place our foliage now looks nice and crisp in motion with FSR2 enabled.

    Unfortunately this is not something I can provide a generic solution for. It depends entirely on what vegetation system you're using in your project and which features you do or don't use. Best thing you can do is badger whoever built your foliage renderer to include official motion vector support. Otherwise your only option is to manually add a motion vector pass like we did. This is not restricted to any of Unity's render pipelines, by the way.
     
  16. khos

    khos

    Joined:
    May 10, 2016
    Posts:
    1,494
    Well done! Sounds like a very useful asset/script. Silly question, on the github page, where do I do to download it, if I get FSR2Unity-master.zip it does not contain all the files, maybe I am doing something wrong.
     
  17. Astfgl

    Astfgl

    Joined:
    Jan 19, 2014
    Posts:
    87
    That's odd. The Download ZIP function is managed by GitHub and it should automatically include everything that's in the latest commit on the master branch. I can't really fix anything about that. Which files do you think you are missing?

    Anyway, I would recommend you use a Git client to clone the repository instead of downloading a ZIP. That makes it easier to pull in any changes in the future. Alternatively, if you're only interested in the pre-built post-processing stack package, then you should download that from the Releases page on GitHub.
     
  18. dklassic

    dklassic

    Joined:
    Sep 29, 2018
    Posts:
    4
    Hi there, awesome job here! I was wondering if you're interested in creating an equivalent for DLSSUnity? Since DLSS Unity Module already exists only that HDRP is the only RP that has implementation using it (and actually publicly viewable).

    I'm aware of the existence of DLSS - Upscaling for Unity. However, their package for BIRP which utilizes the same approach as your custom Post Processing package doesn't seem to work on my project. On the other hand, your FSR2 PP package doesn't work on my project as well, while your Component version of FSR2Unity works perfectly.

    So I was wondering if you have any interest to implement a DLSS Component version? I suppose it is technically possible for me to try to bang my head against the wall for several months to adapt your work to work with DLSS, but it would be great if you're willing to use your existing knowledge to do a (potentially quick) adaptation!
     
  19. Astfgl

    Astfgl

    Joined:
    Jan 19, 2014
    Posts:
    87
    Hi,

    I don't have any immediate plans to work on DLSS, and I'm rather tied up in other projects at the moment. I could have a look at it sometime, but I can't make any promises.

    What's an interesting question to me is why the custom PPV2 packages do not work for you? Are you already using PPV2 in your project? If so, do you have any modifications of your own made to it that makes it impossible to use these custom packages? Or are you using a different post-processing system altogether?

    For Isonzo, we were using PPV2 before but were using an older version with a bunch of modifications made to it, so I couldn't just use the custom FSR2 package as-is either. Instead, I ported the changes made to add FSR2 support over to Isonzo's custom PPV2 code. The changes made to the PPV2 package aren't huge (a couple of extra files, plus some integration code in PostProcessLayer.cs), so manually porting over those modifications is very doable.

    If you insist on using the Image Effect component, it's probably easier to adapt the component to work with Alterego's DLSS plugin, rather than trying to build a new DLSS integration to work with the existing component. Either way, be aware that the Image Effect component isn't great and doesn't work well with any kind of post-processing. It exists mostly for reference, as a basic example of how to make an FSR2 integration.
     
  20. dklassic

    dklassic

    Joined:
    Sep 29, 2018
    Posts:
    4
    Thanks for replying!

    I know why your implementation doesn't work on my project, it's because I'm using a dual camera setup which is out of the scope of your project (I'm the guy who opened this issue).
    Alterego Games claimed that their implementation works on multiple camera (only that in BIRP only one camera can actually use FSR2, the other has to rely on other AA method, which makes sense), but actually running their PPV2 on my project ended up providing identical errors when attempting to use your PPV2 implementation.

    I've known that I can slightly misalign Rect setting of cameras to prevent Unity from syncing the two cameras, so I can just perform reconstruction on the first camera which is much GPU intensive than the other anyways. So at the very least if a working Image Effect component version of DLSS exists, I can suppose just integrate it the same I did using your FSR2 component.

    I'm just a hobbyist learning to make a random game, so I'm not really sure if I'm ready to dive into the nitty gritty part of rendering yet. But, well, I suppose when in the future I have no other stuffs to do, I'll see if I can adapt your work or Alterego's work to make DLSS run on Image Effect component, as a learning opportunity.

    Cheers, thanks again for replying!
     
  21. Astfgl

    Astfgl

    Joined:
    Jan 19, 2014
    Posts:
    87
    Ah sorry, for some reason GitHub didn't notify me of your followup post last month, so I completely missed that.

    Yeah all I can really say is that stacking multiple cameras in BiRP is a bit of a mess. At least URP and HDRP have the explicit concept of a camera stack that you can directly query and control, so for upscalers it's easier to determine what and where they should be applied. In BiRP which cameras belong together and in which order they render depends on what layers they're attached to, which viewport settings they have, their relative depth values, and whether they render to a render texture or not. You'd have to take all of that into account and then make some best guess as to what the actual camera stack is. BiRP being a black box doesn't help either, meaning you can't even reference Unity's own code to verify that you got it right.

    Slightly misaligning the camera rects is a clever workaround. It'll prevent Unity from directly passing render targets between cameras, meaning you don't get the issues with the color and depth buffers from an upscaled camera not matching what the next camera expects. However I would expect it to cause a slight performance drop, as Unity would have to perform an extra blit in-between the two cameras. It might not matter all too much in your case.
     
    dklassic likes this.
  22. Astfgl

    Astfgl

    Joined:
    Jan 19, 2014
    Posts:
    87
    Just now I pushed an update to Github that upgrades the project to FSR 3.0 Upscaler. Now before you get too excited: this only covers the upscaling part of FSR 3.0, which in itself has barely changed from FSR 2.2. This is more of a maintenance release, bringing the project up-to-date with the latest shaders and logic from AMD.

    FSR 3.0 Frame Generation is a whole different can of worms, which falls outside of the scope of the current project. It'll require more research to see if porting that to Unity is at all feasible. The built-in render pipeline is almost certain to be out of the question, though URP and HDRP integrations may be possible. It's already clear that FSR 3.0 Frame Generation will be a lot less universally portable and compatible than FSR 2/3 Upscaling was.

    I have taken the opportunity to rework some parts of the project that I wasn't entirely happy with before, and fixed a few bugs along the way. Also I made sure to test the upgrade on the most relevant platforms and Unity versions, to ensure that compatibility remains the same.

    Upgrade notes:
    • Classes are renamed from Fsr2 to Fsr3Upscaler; this might require some searching and replacing in application code.
    • The QualityMode enum has a new value: NativeAA. The other modes have been shifted up 1 in value.
    • The ResourceView struct has been moved out of the Fsr2 class and into the FidelityFX namespace. This makes code using ResourceView a bit cleaner, and the struct is generic and reusable enough to justify moving it into the main namespace on its own.
    • Shaders are no longer loaded through the callbacks interface, but rather provided directly to the FSR3 Context through an aggregate class. This way we no longer encourage the use of the Resources folder and it fits in better with PPV2's resource management, while still giving game devs enough flexibility in where/how shaders are loaded.
      • Consequently, the FSR3 Context no longer requires a reference to the callbacks interface.
     
    szymongvox, baggyg, Gasimo and 2 others like this.
  23. slimshader

    slimshader

    Joined:
    Jun 11, 2013
    Posts:
    190
    Hey, fantastic project, any chance for VR support before frame generation (or at all)?
     
  24. Astfgl

    Astfgl

    Joined:
    Jan 19, 2014
    Posts:
    87
    I haven't given up on VR support yet, but every time I go into it with a new idea or a fresh perspective, I feel like I'm running into a brick wall again sooner or later. It would really help if someone with more of a vested interest in VR and/or more experience with VR in Unity would have a look at this. The project is open source after all, and contributions are welcome.
     
  25. WaaghMan

    WaaghMan

    Joined:
    Jan 27, 2014
    Posts:
    245
    Hi!

    Great project, about time someone gave some love to the good old PPv2 package.

    Integration of the package was more or less painless, given that we had our own modifications to PPv2 done by ourselves (mostly to avoid unnecesary commandbuffer updates, more reasonable depth of field settings, etc).

    Still working around some issues (mainly native resources being leaked, or at least so does Unity tell), but I just wanted to ask, is usage of OnRenderImage strictly necessary? Obviously if I comment it right now it doesn't work, but it's a shame because when FSR is disabled, this means an additional blit is unncesarily performed.

    A potential solution is to have the OnRenderImage on a separate script and enable it only when FSR is enabled, but it's a hassle.
     
  26. Astfgl

    Astfgl

    Joined:
    Jan 19, 2014
    Posts:
    87
    Interesting question. I would say OnRenderImage isn't strictly necessary as it's only used to perform a final camera blit when the "Direct to Camera Target" option is disabled, and to do some housekeeping at the end of the frame in preparation for the next frame.

    Obviously that final camera blit gets skipped when "Direct to Camera Target" is enabled, which I assume you already have, and that end-of-frame housekeeping could technically also be done in a coroutine after a "yield WaitForEndOfFrame".

    The only question mark is with the [ImageEffectUsesCommandBuffer] attribute used on the OnRenderImage method. It's one of those black-boxy Unity BiRP things that isn't all that well explained, especially its interaction with the Camera.forceIntoRenderTexture flag, and to make it even more confusing it's also only compiled into non-editor builds of your project.
     
  27. WaaghMan

    WaaghMan

    Joined:
    Jan 27, 2014
    Posts:
    245
    We don't have direct to camera target enabled (we use a couple of legacy postprocesses on specific cases), so OnRenderImage() isn't needed in our case. Didn't really know that it's there precisely to NOT do a blit when that setting is enabled.

    In any case, I went with the separate script with OnRenderImage() on it, so that extra blit is only performed when FSR is enabled, and it works like a charm.
     
    Astfgl likes this.
  28. WaaghMan

    WaaghMan

    Joined:
    Jan 27, 2014
    Posts:
    245
    Hi!

    Just found out a specific case which may end up in blurring textures/unintended behavior:

    Currently, CreateFsrContext() causes a change to all loaded Texture2D mipbias to prevent blurriness because of low resolution.

    When FSR is disabled, the change is supposedly undone, however the set of Texture2D objects in memory may have changed (usually because of objects loaded dynamically), and these new texture2d will from now on have an incorrect lod bias, ending up blurred with FSR disabled.

    My solution was to assign the intended value instead of adding / substracting it. It wouldn't be compatible with textures having specific lod biases set beforehand, but we're not using that feature so it shouldn't be aproblem.
     
  29. Astfgl

    Astfgl

    Joined:
    Jan 19, 2014
    Posts:
    87
    This is exactly the reason why setting the mipmap LOD bias is part of a callbacks interface that can be overridden and reassigned externally. Unity, in particular the built-in render pipeline, doesn't have a clear and consistent way of keeping track which textures are part of the 3D scene and need to have that mipmap bias applied and which ones are, say, part of the UI. Add third-party packages and dynamically loaded textures in the mix and things become especially muddled.

    This all means that the mipmap bias adjustment is a very application-specific thing and it's up to the game developer to implement this properly for their own use cases. The implementation provided in the Github project is intended as "just" an example for reference, a very simple implementation that covers the most basic use case but that isn't particularly smart about it. The README also acknowledges this fact.

    I was honestly considering removing the mipmap bias callback altogether when I upgraded the project to FSR 3.0, replacing it with some generic utility functions and leaving the rest to the integrator, but that would've made it much too easy to overlook the necessity of applying a mipmap bias, likely leading to even more questions about why textures become so blurry when FSR is enabled.
     
  30. WaaghMan

    WaaghMan

    Joined:
    Jan 27, 2014
    Posts:
    245
    Indeed, it's just another thing to the huge pile of changes that would be greatly appreciated if someone decided to give some love to the workhorse that is the built-in renderer. But oh well.
     
    Astfgl likes this.
  31. Astfgl

    Astfgl

    Joined:
    Jan 19, 2014
    Posts:
    87
    Finally! FSR 3.1 was released as open source by AMD today, something I had been eagerly waiting on for months!

    I got to work on it straight away and although FSR 3.1 is very different in its structure compared to FSR 2.2/3.0, it wasn't too difficult to figure out what's changed and I have it up and running in Unity already:

    screenshot-20240709-224037.png
    As you can see, it now comes with a fancy debug view that will help a lot with analyzing what FSR3 is doing behind the scenes.

    The good news is that there is nothing about the new shaders that would increase the requirements of FSR3. It's all still bog standard HLSL code that compiles without issue using the standard Unity shader compiler, so I don't foresee many problems getting it to work on all the same platforms as before.

    The bad news is that I'm about to go off on holiday for a week, so I won't be able to properly test and polish this stuff for a while. :rolleyes:

    The plan of course is to open source this under the MIT license once it's ready, and I'm sure it will find its way to The Naked Dev's FSR3 plugin as well sooner or later. I'm really looking forward to seeing how FSR 3.1 performs once it's integrated into a proper game!
     
    hopeful likes this.