WOOT! Snapshot tiling fix is here!

Back in July 2012, I indicated that Runitai Linden had a long-awaited fix for the “tiling” issues affecting high-resolution snapshots for some people.

The issue was initially reported in JIRA MAINT-628 at the end of 2010, and has impacted viewer releases since then, becoming the subject to intense investigation by users and LL alike. The problem has tended to make itself known when taking images at a higher resolution than that of your monitor, resulting in lines breaking-up the captured image in a tiling effect.

In July Runitai commented on the JIRA thus:

Runitai Linden added a comment – 18/Jul/12 1:57 PM

Fixed in viewer-cat

Fix was to use a large render target for snapshots that are larger than the window, but only when lighting and shadows is enabled. Screen space effects will still show seams when lighting and shadows is disabled.

If the graphics card is unable to allocate a single render target large enough for the high res snapshot, the old method of tiling is still used. On my GTX 580, I could take artifact-free snapshots up to 3500 pixels wide, but could not allocate a full set of render targets at 4000 pixels wide, so the old method is used.

Changes involve an invasive set of changes to LLRenderTarget, so QA should be careful to check various shadow modes, ambient occlusion, depth of field, and anti-aliasing with lighting and shadows enabled. Running with Debug GL enabled will likely cause a crash now when taking high-res snapshots (expected and acceptable behaviour), since the driver reports “out of memory” when trying to allocate a large render target. When Debug GL is not enabled, the viewer handles this error condition gracefully and continues to function.

Sadly, in the interim, things went slightly pear-shaped with LL’s viewer code, with major bugs appearing in the beta code branch which brought updates to a juddering halt which they were sorted out. Those reading my weekly project news updates will be aware of the issues, which were finally sorted out last month. However, in the interim, a LOT of high-priority work has backed-up, with the result that MAINT-628 appeared to be in a holding pattern with a lot of other work, waiting for the high-priority stuff to clear. When I asked Oz Linden about the situation, he could only say that the JIRA looked likely to be out “pretty soon” – which suggested a potential wait of a few more weeks.

However, for those using the SL viewer – the wait is over!

Beta viewer 3.4.3.267755 was released on December 5th, 2012, and the release notes contain a small but significant entry:

MAINT-628[c] Highres snapshot – Rendering artefact (Window sized frame buffer regardless of snapshot size)

I’ve just been playing with the release, having long suffered from the tiling issue when trying to capture images at almost anything over my screen resolution of 1440×900 and the results are superb. The following two images were captured at the same image resolution (3500×2154). The top was captured using the current SL release viewer, and the lower image with the new beta viewer. The results are clear – but click to enlarge each, if required. Note the tiling line across the sky in the first image and the lack of any such line in the second.

The problem again: an image captured on my PC at twice my screen resoltuion (1440x900), using the release SL viewer, 7th December. Note the tile line in the sky (click to enlarge)
The problem again: an image captured on my PC at 3500×2154 resolution, using the release SL viewer, 7th December. Note the tile line in the sky (click to enlarge)
Rough the same image shot using the new beta viewer at the same resolution  - no tiling line (click to enlarge)
Roughly the same image shot using the new beta viewer at the same resolution – no tiling line (click to enlarge)

So, for those who have been afflicted by the tiling bug, the wait is almost over. You can either grab the beta viewer and start snapping in high res, or wait for the fix to arrive in your favourite viewer – the wait shouldn’t be that long now, hopefully!

28 thoughts on “WOOT! Snapshot tiling fix is here!

    1. *BLUSHES* :).

      Tbh… I scanned the release notes (rather hurriedly) on the 6th but completely missed the update, as it was indented under another (unrelated JIRA). I think that tricked my brain into thinking they are related and so I skip-read.

      …Or at least, that’s my excuse :).

      Like

    1. Yep.

      Both images were captured in deferred mode (lighting and shadows enabled). That’s my default mode.

      Like

  1. Woot woot woot indeed! Those are wonderful news! How many hours have we consumed tinkering those ugly tiles from our high-res snapshots? It’s not about the black lines only but sky, water and shadows around them.

    Like

    1. It’s the hours (and being completely kackhanded with photoshop) which have kept me only snapping at 1440×900.

      The only problem I have now is that I’ve got a slew of places to revise and resnap and tonnes of flicker images to update. Not to mention the ability to produce decent videos from stills…

      Although I suppose that’s my diary sorted for 2013 :).

      Like

  2. Blimey. About bloody time if you ask me! This bug has been outstanding for AGES as you say. I’ve simply had to accept taking pics at my screen’s resolution (fortunately a semi-useful 1920×1200) but always missed taking at 3840×2400 which is what I used to do.

    Any idea when this may make it into Firestorm?

    Like

    1. That’s down to the Firestorm team, I’m afraid. FS is currently on the 3.4.1 code base, the beta viewer is on 3.4.3. I assume Firestorm (and other TPVs) may go dirrectly to 3.4.3 as they update.

      Like

    1. Unfortunately, it doesn’t seem to work at all sizes, at least for me. Tiling is gone at double my screen resolution, but at triple, tiling is worse than before. Max res is scary bad.
      (samples here)
      Still, I am happy to be able to just double my screen resolution and now have to work in Photoshop to eliminate tiling damage.

      Like

        1. Send me the link and I’ll add it.

          Runitai’s JIRA update from July does indicate that the fix has a limitation on it, so it may not work on ultra-high resolutions (hence why I included the text in this report as well). Not sure if that is coming into play with your efforts.

          Like

          1. I sent you the link via DM, Inara, thanks. I suspect you’re right, that I am stepping outside of the fix parameters, especially since the tiling goes way beyond simple gridlines. (Note: triple resolution is the setting I usually use, never had this behaviour before.)
            Still I am thankful to just be able to double resolution without gridlines.

            Like

            1. Have added the link for you. Strawberry has found similar issues as well, so would suspect you’re both hitting the upper end of the scale wall. I can get 2.5x my screen resolution OK, but coonfess, I haven’t tried going further.

              Like

  3. Finally! OK, when the guys of the Firestorm team include this fix in their next release, i’m definitely upgrading my viewer!

    Like

    1. Niran’s is a bleeding-edge viewer which, as NiranV Dean states, is tailored primarily to his needs. As such many people are uncomfortable using it.

      Also, whether one uses Niran’s or not, the MAINT-628 fix isn’t featured in the current release of Niran’s Viewer, so I’m uncertain as to why you are raising the issue.

      Like

      1. Niran included a similar fix in his viewer, but it still left some tiny black edges (only visible at 100% image size). However a real fix to the engine is more than welcome.

        Like

        1. I tested all V3.x viewers taking snaps at 3500 x2154 today. All showed the same tiling issue (incl. Niran’s latest) with deferred enabled on my system.

          Like

  4. For everyone’s information. I will post to the jira as well.

    I tested the latest beta viewer. On my hardware (See below) it only works up to 4096×2193 with “constrain proportions” activated. (I have a 1080p monitor, 16:9)
    Above that, it starts generating artifacts on the right side of my saved images.


    on images 7,8, 12 and 14, you can clearly see them.

    However, on my friend’s system (Intel pentium G640, CPU-embedded HD intel Graphics, can run shadows (!)), she only gets it rarely, and especially on 5016×2974.

    my system:
    (CPU: AMD FX(tm)-8350 Eight-Core Processor (4891.52 MHz)
    Memory: 12210 MB
    OS Version: Microsoft Windows 7 64-bit Service Pack 1 (Build 7601)
    Graphics Card Vendor: NVIDIA Corporation
    Graphics Card: GeForce GTX 560/PCIe/SSE2
    Windows Graphics Driver Version: 9.18.0013.1061 (Geforce 310.61)
    OpenGL Version: 4.2.0)

    Like

    1. Thanks for the updates 🙂

      Runitai does indicate that at the upper end of the scale, the problem can resume, but he looks to have have hit issues around 4000 pixels across on his system.

      Has anyone yet encountered the memory crash issues Runitai also mentioned?

      Like

        1. Latest Firestorm release build, or dev build? If latest release (4.3.1.31155), that is only merged to LL 3.4.1 code, and so doesn’t have the MAINT-628 fix. Not sure on the status of dev builds.

          Like

          1. She crashed while doing the huge screenshot, but that was FS 4.2.2.29837. mainLoop Bad Memory Allocation thingy. Nevermind O.o

            Like

  5. one part of the issue had in nov its fifth birthday.
    It’s so cool we now have this fix 🙂
    sure i would love to see the old maximum capture-size (6k wide) also, but maybe some Devs will tweak the source to a higher maximum.
    AFAiK FireStorm will anticipate this fix with 4.4.0 (or so, FIRE-4725 ). What all other Devs will do too (as long as LL do not pull the fix back) when they grab LLs viewer-source.

    Like

Comments are closed.