Jump to content
  • Advertisement


  • Content count

  • Joined

  • Last visited

Community Reputation

1012 Excellent


About pcmaster

  • Rank

Personal Information

  • Role
  • Interests

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Yeah, I can't tamper with the existing colour correction tuned on LDR after Reinhard-like tonemapping. Not on this project. I like the second idea though. I'll give it a shot, but I'm too tired after looking at this for long days. After all my experimentation, the approach from Infamous Second Son that I linked inspired me and it works with an modification. They devised a ColorGradeSmoothClamp function which is y=x near 0 and y=1 near 1.5. I used our original Reinhard-like HDR/(HDR+0.2) instead of this one and it works surprisingly well: select maximum component of HDR tonemap the maximum component using the same tone-mapper as the original pipeline (but not RGB, only the max component) scale = tonemapped max component / max component colour grade (original hdr * scale) re-expand: graded / scale This works precisely for identity colour grading (which is a must) as well. Of course, the grading is done on a slightly different LDR value because the scale comes only from tonemapping the maximum component, but the resulting colours don't shoot too far when the tonemapper clamps them to 1, it looks pleasant and similar. I wonder if artists will agree Simple inverse tonemapping LDR->HDR just didn't work for me because of the singularity near 1.0. Neither can I use a totally different tonemapper than the original, because I'd be feeding the colour grader totally different LDR values. Is there a tonemapper without a singularity in its inverse form, which utilises close to the full LDR range?
  2. How can values around well under 10 be so washed out with the curve I've presented? 10/(10+1) = 0.91 = not quite 1.0 The value in the colour buffer could ideally be the radiance [W⋅sr−1⋅m−2], from the rendering equation for Lo(x, w) = Le(x,w) + Li(x,w) where x is the point on a surface visible through your pixel, w is the direction to it, Le is the radiance emitted from that point in your direction and Li is the radiance reflected from the scene (from all directions towards our point x and exiting in our direction). In our simpler cases, there will be no GI, Le=0 (no emission) and Li = radiance coming from all light sources. Radiance is "radiant flux [W] 'divided' by solid angle [sr−1], area [m−2] and dot(N,L) [dimension-less]", radiant flux is in Watt and that's what I guess the powers of the lights should be in. I hope somebody will correct me or make it easier to comprehend.
  3. Hi community! Do you know about any articles that deal with abusing existing 8-bit colour grading LDR LUTs when you want to use them for HDR10 (HW HDR) output? The case is when you mustn't touch the existing LUTs but still want the HDR to maintain the artistic feeling (as much as possible). I've found this one http://www.glowybits.com/blog/2016/12/21/ifl_iss_hdr_1/ (section Color Grading). I'm currently testing it. With the approach I devised, there's a problem when the LUT blows "okay" colours to "fully blown" near 1.0: ldr = hdr / (hdr + 0.2) // reinhard-like tonemapper from the existing game graded = lut(ldr) // until now, this is exactly what the existing game is doing in LDR) reconstructedHDR = -0.2 * graded / (graded - 1) // singularity with graded = 1 My approach works fine as long as the LUT isn't too aggressive. When it is, I'm toast I tried many things to somehow clamp it, or dial it back if it flies too high, but nothing is satisfactory. The original game, as most games, applies colour grading after doing the tonemapping. If it was before, I wouldn't really have a problem, would I? .P
  4. Hi! Your function Uncharted2Tonemap converges to 1, but very slowly. Try this function, called Reinhard operator: ldr(hdr) = hdr / (hdr + a), where a = 1.0 for the start. Try plotting it, you'll like it. This maps low values to similar values (behaviour "similar" to gamma correction/sRGB for a=0.2, for example) and very high values closer to 1.0 (LDR white). From your first screen-shot, it appears that the scene is pretty dark. If it wasn't, you'd have fully-blown white (white-ish) areas with values >1.0, which you don't seem to have. Therefore, after you tonemap it, it's dark. That's correct behaviour. Your input data doesn't seem to be. The input HDR value must be linear, not sRGB, be sure to have it like that. Your render target will be either R16G16B16A16_FLOAT or R11G11B10_FLOAT (don't know OpenGL equivalents by heart). You should do all your light calculations in linear space. When sampling your textures, the texture sampling functions should return linear values. You can try by de-gamma-correcting your input values (pow(hdr, 2.2)) to see if you aren't off. The output back buffer, however, will be expected to be sRGB (I expect), so depending on what your system is doing at the end you might need to do it yourself, so add this simple approximation (or not, experiment): finalLDR = pow(ldr, 1.0/2.2) (gamma correction). Also, with a Reinhard tonemapper, but also that you posted, there isn't a very big difference between a value HDR 10.0 and HDR 100.0: Reinhard with a=1.0: 10 / (10 + 1) = 0.909, 100 / (100 + 1) = 0.990 Uncharted2(10) = 0.706, Uncharted2(100) = 0.904 Remember you're trying to fit a big range (0..1000 nits) to a small LDR range (0..1 with 8-bit precision).
  5. pcmaster

    Communism 2.0

    Slayemin, I wonder which country you stem from I come from one that tried the 1.1 version and almost everything that could go wrong did. The idea is nice, indeed, just too many people aren't nice. A lot of misplaced violence is needed to manoeuvre everyone into obeying any such an artificial system. Of course - just for a game economy? Totally exploit such ideas! Did you check up on China? They're implementing a similar point system but I have a bad feeling it's going even more wrong right from the start than imaginable.
  6. pcmaster

    VSSetConstantBuffers1 Problems

    I haven't used this variant personally, so I was just shooting from the hip. It's a bit surprising, indeed. Maybe it has to do with a typical 256 byte texture alignment - who knows if some implementations don't have to do it with textures behind the scenes and texture descriptors usually contain 256-aligned addresses... Also, write-combining at least 256 bytes instead of only 16 bytes over the various complicated buses to the GPU-visible memory seems reasonable. You're trading minimum overhead in regards of time for (possibly no) overhead in regards of memory.
  7. pcmaster

    Accepted to college but..

    I'm very sorry, it's very unfortunate. Is the school in the USA? It isn't like that everywhere in the world.
  8. pcmaster

    VSSetConstantBuffers1 Problems

    Hi! Are you sure the numbers and offsets are correct? The documentation says that "an offset of 2 indicates that the start of the associated constant buffer is 32 bytes into the constant buffer". It isn't an offset in bytes but an offset in 16-byte (float4) constants.
  9. Hello! Previous year in my job we implemented a HDR output (as in HDR10 / BT.2020 / ST.2084 PQ back-buffers) on one of our games on the consoles, which do support HDR10 over HDMI. The HDR compatible hardware (monitors, televisions) has already been around for a year, with varying quality. I wonder if there's already HDR-HW output exposed in the PC drivers? Windows 10? Vulkan? DX 11? DX 12? Which vendors? For those unfamiliar, I'm talking about outputting HDR signal to HDR hardware (using r10g10b10a2_unorm + PQ backbuffers, or better). Thanks, .P
  10. pcmaster

    Packing uniforms into matrix

    You could batch the per-draw-call values into elements of an array inside of the constant buffer and index by the index of the individual objects (where to get that from? per-draw uniform update :D) The whole constant buffer with values for N objects would be uploaded at once. Max size is platform dependent. I'm not sure how well could this perform and if in-shader indexing of arrays in CBs is available and/or performant.
  11. pcmaster

    Packing uniforms into matrix

    Rather than 3x3 it might help to lay them out as float4 (vec4) and upload them at that granularity. Also make sure each float4 is 16-byte aligned, just in case. Btw, did you mean updated every draw-call rather than every frame? Uploading 100 bytes (?) once a frame costs nothing even on the poorest mobile HW.
  12. pcmaster

    Your opinion on my game?

    Isn't there also a video?
  13. Can you show us the declarations of Input1-4 and Output1-4 as well? Also their descriptors used to create the SRV and UAV.
  14. pcmaster

    Do indie game designers play their own game?

    As for AAA, the amount of playing your own title during development varies heavily between disciplines (testers > designers > artists ~ programmers) and it varies even more between individuals. For engine programmers, 98% time it's enough to launch a test scene or load a suitable mission, watch the logs, make a capture or step a bit for a few minutes and turn it off again (your local version will most likely crash or manifest artifacts anyway :D) Tools programmers might not play the game too much either. Gameplay coders do much more, for obvious reasons. After release, many AAA employees play the game through for the first time. And many don't. As far as indies go, I believe most will play it after release.
  15. pcmaster

    Discard vs Clip

    It isn't useless to ponder about it. That's how we learn, for example. The reference documentation is very vague on purpose. It's up to the vendors how they achieve it. Do they run none/some/all of the work in vain? Everything is legal! And they will! Will it somehow differ between vendors and generations? You bet! Yet it will be compliant. As long as the results match the prescription, vendor is allowed anything. That's why it's most challenging to achieve the most performant results on all PC setups; it's much easier on consoles where you can be sure about what will happen.
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!