GuyWithBeard

Members
  • Content count

    506
  • Joined

  • Last visited

Community Reputation

1904 Excellent

1 Follower

About GuyWithBeard

  • Rank
    Advanced Member

Personal Information

  • Interests
    Art
    Programming

Recent Profile Visitors

10680 profile views
  1. Gamma correction - sanity check

    Yep. I missed that exact flag. However, texconv seems to do linear-to-SRGB conversion even if you leave it out as long as you specify an SRGB format as output format. So, what I assume happened was that my input texture, already in SRGB, was treated as linear and was converted to SRGB a second time. This caused the texture to come out very bright.
  2. Gamma correction - sanity check

    Well, I managed to get the textures to look correct. I incorrectly assumed that texconv (of DX SDK fame) would be able to detect if an image was already in sRGB format or not. Turns out my images lacked the necessary metadata, so now my texture converter assumes a texture is in sRGB if it is set to output into sRGB, and that took care of the overly bright textures.
  3. Gamma correction - sanity check

    No need to apologize, this is very helpful. Some of my confusion came from the fact that I tried to do the same sanity check in Unity, by setting the project to use linear color space and clearing the screen to [128,128,128,1] and it actually comes out as 128 when color picked in GIMP, while my render window is cleared to 186. Although I realize I have no idea what Unity is doing behind the scenes so this probably is not helpful at all. Anyway, I realized that I have been converting my textures incorrectly to sRGB which probably explains why they are showing up brighter than they should. I'll fix that and output one of them on screen and see how they look...
  4. Gamma correction - sanity check

    I feel like you are dodging my actual question Anyway, thanks thus far. I will have to read up on this a bit I feel... EDIT: For the record, Matt77hias, edited his previous posts to provide more info. Thanks dude!
  5. Gamma correction - sanity check

    Yes, but in this case I render the color instead of sampling it. Would rendering the color to screen and doing a print-screen of that equate to your third sampling step? Ie. should I expect 128 or 186? (actually it came out as 188).
  6. Gamma correction - sanity check

    Yes, I know that. But if the pipeline was configured correctly, shouldn't a clear color of 128 come out as 128?
  7. Gamma correction - sanity check

    To be honest I don't quite have a use for Forward+ at the moment. That's why I put it in parentheses. I just happened to stumble upon this fine article and figured it looked interesting: https://www.3dgep.com/forward-plus/ Anyway, I might get to HDR at some point but rendering is only a small part of the development I am doing so I simply haven't gotten to it yet. I am by no means a graphics programmer per se. And speaking of, I have moved over to using sRGB textures and an sRGB back buffer now on both Vulkan and DX12 and I would like to do some more sanity checking if you don't mind. The image output is a lot brighter, as you would expect. However, simply clearing the window to a solid color (ie. not doing any real drawing) is also a lot brighter and I am unsure if that is correct. I made my clear color [128, 128, 128] and it seems to come out as [188, 188, 188] (checked by doing a print-screen and looking up the color in GIMP). Since I should now be working in linear space which is then converted to gamma space before being presented to the screen I would expect the color to come out the same. Black comes out as black and white comes out as white, so it seems to be allright. However, I thought the whole point of working in linear was that half-way between black and white would come out as that. Where did I go wrong? (and thanks in advance for explaining these fundamental things) EDIT: Textures also seem to come out a lot brighter, so there's clearly something wrong. I will have to investigate.
  8. Gamma correction - sanity check

    Yeah, I guess the alpha channel is practically unused in the backbuffer. On a related note, it seems that would only be possible for the "work back buffer" or whatever it should be called, as my Vulkan driver reports that the only two formats supported for the actual back buffer are VK_FORMAT_B8G8R8A8_UNORM and VK_FORMAT_B8G8R8A8_SRGB.
  9. Gamma correction - sanity check

    Cool, thank you @knarkowicz, I should be good to go then.
  10. Gamma correction - sanity check

    I was going by the GPU gems3 article I linked above where they suggested you use an sRGB format to get efficient linear-to-gamma conversion. As for the rest, my renderer is forward (+) so there is no G-buffer and I don't plan to do HDR any time soon. EDIT: ...but as I read your comments it seems like I should perhaps go the HDR route, so feel free to throw any good articles at an HDR-virgin like me.
  11. Gamma correction - sanity check

    Interesting. I was reading this article: https://developer.nvidia.com/gpugems/GPUGems3/gpugems3_ch24.html and they make a big deal about the fact that the conversion to sRGB should the the very last step before displaying on the screen. It seems to me that having a main color buffer in linear space would be good since then you could both write to it and read from it for intermediate steps without having to care about sRGB at all. That's why I planned to have a linear space main color buffer. Just to be clear, if I stick to the plan but change the main color buffer to DXGI_FORMAT_R8G8B8A8_UNORM_SRGB and then read from it as I apply, say, a fullscreen effect such as FXAA, the result will be incorrect as I will be reading sRGB values when I should be reading linear values. Right? So in this case, the only thing left to do, if I want correct behavior, is to use a floting point main render target?
  12. So I am finally fixing up my renderer to work in linear space after not caring (enough) about it for many years, and I wanted to do a sanity check on my plan to make sure I am doing it correctly. Up to this point I have had pretty much everything in DXGI_FORMAT_R8G8B8A8_UNORM, including textures (diffuse), swap chains and any offscreen buffers. My plan is roughly the following: - Load diffuse textures as DXGI_FORMAT_R8G8B8A8_UNORM_SRGB. Normal maps and other non-color textures should still be non-sRGB as far as I know. - Create the swap chain back buffers in the DXGI_FORMAT_R8G8B8A8_UNORM_SRGB format. - Render the scene (both the main render pass + all other color render passes) into offscreen buffers in DXGI_FORMAT_R8G8B8A8_UNORM format. My plan is to have one main texture which acts as the "back buffer" during the rendering process. It is there simply to have a linear-space buffer to work with. - After all rendering is finished, I will copy the linear space "back buffer" to the actual back buffer of the swap chain. Does that sound right? Also, will the graphics API allow me to copy the linear buffer to the back buffer with a normal texture-to-texture copy or do I need to handle the linear-to-gamma change somehow? I have heard that the APIs handle the conversion when rendering to an sRGB buffer (ie. output from a PS) but is the same performed when copying from a linear texture to an sRGB texture? My targeted APIs are currently DX11, DX12 and Vulkan. Cheers!
  13. Vulkan Vulkan render pass interdependencies?

    Cool, thanks. I am gonna go with that for now because I am in the middle of implementing large feature and now is not the right time to rewrite my render pass system.
  14. Vulkan Vulkan render pass interdependencies?

    BTW, did you manage to hide away all resource barriers and transitions into your render pass system or do you still have to issue barrier/transition commands on your command buffers at the rendering code level?
  15. Vulkan Vulkan render pass interdependencies?

    Interesting. I wonder if you could force render passes into a specific execution order (ie. the order they are recorded into the command buffer) by using only VK_SUBPASS_EXTERNAL as srcSubpass and dstSubpass. EDIT: And by that I mean that the vulkan-tutorial.com article seems to suggest that you can refer to a subpass of a previous/subsequent render pass using VK_SUBPASS_EXTERNAL, although I am a bit unsure if that is what it really means. Of course, it wouldn't be utilizing the GPU to its fullest but it would ensure correct behavior...