GTPNewsWire
Contributing Writer
- 20,178
- GTPHQ
This is the discussion thread for a recent post on GTPlanet:
This article was published by Jordan Greer (@Jordan) on December 24th, 2018 in the Gran Turismo Sport category.
Polyphony Digital Shares Technical Document on GT Sport's HDR & Wide Color Support
- Thread starter GTPNewsWire
- 28 comments
- 5,105 views
- 3,277
- France
Another presentation in Japanese : Procedural Hard Surface Design | Akira Saito | SIGGRAPH Asia 2018 (Tokyo)
I think all the buildings at Tokyo Expressway are made with Houdini. (And the speaker is wearing a Pikes Peak jacket
) In general, Poly is less secretive today wich is great! And the studio is still hiring, I wonder how many people work at Poly?
- 261
- Lisbon
- 3,792
They can bang on about HDR all they want, but cockpit view certainly is not HDR. it's simply the worst DR of any racing game.
- 2,546
- Brazil
Another presentation in Japanese : Procedural Hard Surface Design | Akira Saito | SIGGRAPH Asia 2018 (Tokyo)
I think all the buildings at Tokyo Expressway are made with Houdini. (And the speaker is wearing a Pikes Peak jacket
In general, Poly is less secretive today wich is great! And the studio is still hiring, I wonder how many people work at Poly?
Everytime i see this Procedural Hard Surface Design my mind goes wild thinking PD is secretly making a sequel to Omega Boost
- 817
- California
- Lux_Klonoa
- Lux Klonoa
This could be useful for the rest of the industry. Yeah, I'm looking at you, Red Dead Redemption 2! >_>
- 177
- Cyprus
- apocalypxoticnow
I just went through the slides. I didn't know before but I guessed they adapted HDR10 since most modern TVs with HDR have it. Lots of info there. Definitely worth a read for the enthusiasts of video rendering. Some of the solutions PD found to problems of implementing HDR is so simple and yet effective. HDR rendering still seems to be in an experimental phase because there seems to be world wide standard (maybe apart from BT.2020). These guys know what they have done is not perfect but they are aware of the bottlenecks and what areas need improvement. This is a masterpiece in progress.
One of the problems is that a system ideal for Polyphony isn't always exactly what is released by a dozen TV manufacturers. Often, it's not even what the engineers at those manufacturers wanted, nor what the photographers, scientists and technical folks wanted; the realities of life and work mean that you're going to get a mixed bag limited by time, money, pride and greed and try and deal with it.
Now, since this one is in English (interesting), there's not so much need to translate every slide like I did for the last one on Iris. But, I can explain a few things.
First, your typical display is a effectively 24-bit; 8 bits of Red, Green and Blue each. RGB, I'll use that a lot.
8 bits gives you 2^8 = 256 values (0-255) and thus, assuming that "greyscale" is when R, G and B are the same, that means you only have 256 levels/steps of brightness, from pure black to pure white.
In practice, since we see different colours as different brightness (even though they're the same) you can use tricks by making the gray slightly 1/256th more blue (darker) or R+G aka yellow (slightly lighter). This only works in the midrange, where the difference in saturation is relatively small. So you CAN sorta fake more brightness levels in, but technically it's a bit ghetto.
OK, back to the presentation. They go into what colours the human eye can see. Typically, we have 3 cones that detect R G and B. Since it's organic and biological, it's not linear, or consistent or 100% reliable, but pretty good. Fits >95 of the population damn well, so that's designated as normal.
Now, apparently the human eye can see 46-bits of precision. That's obviously not worth blowing absurd amounts of memory/storage space on, and building screens to that level, so Dolby Imaging got it down to a 1:10,000 range of brightness.
NOTE: for those of you who can't count in binary - 2^10 = 1,000-ish. Therefore, 13-bit precision i about 8,000-ish (14-bit is 16k) so if we're being proper we'd be using 13 bits per channel. But for RGB that means a 39-bit buffer, which is dumb. 3 times 10-bit buffers, one each for R+G+B gives you 30 bits, + 2 bits for other random things, which fits nicely in a 32-bit buffer. That's what they use in most game engines nowdays for Normal Map buffers, as well as HDR lighting buffers.
Again back to the presentation. The human eye can see differences as low as 1nm in wavelength. In english, that means a change in colour. Given we see about ~400nm band, that's a ~0.25% change in hue, impressive!
NOTE: this is different for men and women. Women are FAR, FAR, FAR more likely to be this sensitive to changes in hue than men (differences in eye and brain makeup). Lads, we see things differently, and also you're a lot more likely to be colourblind as well. We handle vision differently, relying more on the brain vs the eyes. It's assumed to be a hunter vs gatherer type thing from our evolutionary history.
One of the big problems they have is that the 'stantards' aren't yet set and enforced like they need to be. One 'HDR' isn't always like another.
NOTE: this drives everyone mad.
This is in part because of the different types of displays, so there isn't a huge amount you can do about this for now. Until there's either one type of screen, or both have enough overlap to fit the entire HDR spectrum, it's going to be a problem.
The curves, gamuts, gamma, etc are all different ways of manipulating that 256 or 1024 step gradient in different ways. As it turns out, since we don't see brightness as completely linear anyway, and most things we see are in 'patches' of brightness, we can clump those steps closer where we need to, and spread them out thinner where we can't notice the difference so much.
THEREFORE:
Now there's 999 different competing standards and different ways TVs, monitors, and softwares are set up from the factory. Great.
Thankfully, you can use math to compare them and find out the best one.
Skipped a fair bit, going to the tonemapping.
Tonemapping is the process of converting an 'unlimited, raw' brightness into something that's both pleasant to look at, works with the display to look realistic and handles 'changes of exposure', in games auto-magically.
Page 118 -123 explains this perfectly, and is what you really need to look at. The slight dip in the curve at the darker colours 'crushes the blacks' which is appealing to viewers. The dead straight linear section in the mid-tones is what makes things look photo-realistic, and by compressing the bright bits you can get away with saving some extra detail for the mids.
Therefore, you can have something that's good looking, stylish, photo-realistic and efficient all in one!
I'm not making this up when I say the people who do the tonemapping for Polyphony are worth their weight in gold. Seriously.
Skipping a bit, they go into some of the calibration tests they use for the cameras, The important part is they get everything 'neutral' so that they can align everything perfectly in-engine. Remember, you want to do lighting calculations with everything CORRECT and then at The End (post-processing) add tint/exposure/etc calculations. Keep the data as clean as possible, for as long as possible, otherwise you put dirty errors in and pay the price.
Then there's a lot of testing and specifications on format types.
And some more on colour grading. This is basically the artist-controlled version of tonemapping - whether you're combining RGB into one channel for a black and white / greyscale image, or your're tinting it warm or cool, or whatever. Functions much the same way, it's just an operation on the image you perform as post-processing.
One interesting note is that they do get some colour shift in the bright areas (and presumably very dark areas too). This is because they run the tonemapper per-channel I think. So as the RGB values are on different bits of the curve, they can get separated as the curve changes up/down. I would have thought they'd try and shift things into HSV and keep the HS locked 100%, but since it's only noticeable at very bright areas, and only if you're looking for it, they took what I assume is a slight performance boost by saving a step. Hey, when you need those tenths of a millisecond, every cut operation counts...
Anyway, that's the normal-people english version of their presentation. Hope that explains a few things.
- 15,529
- Cairo, Egypt
- GTP_SEMS
- 242
- Netherlands
Interesting article, especially about the calibration and testing with the different tv's. But one thing i also would like to know is what color tone profile they would recommend, as it changes the image a lot.
On my tv I use warm2 (Samsung) as that was recommended by a digital foundry video. But it would be nice to know what the developers use and recommend.
On my tv I use warm2 (Samsung) as that was recommended by a digital foundry video. But it would be nice to know what the developers use and recommend.
- 3,277
- France
Another presentation : Making catalog pictures of cars with games ~ Story about modeling and rendering in Gran Turismo ~ (in Japanese)
https://cedil.cesa.or.jp/cedil_sessions/view/1955
You can create a free account.
It is not yet perfect.
Based on this we will proceed to the future of rendering in ray tracing.
https://cedil.cesa.or.jp/cedil_sessions/view/1955
You can create a free account.
It is not yet perfect.
Based on this we will proceed to the future of rendering in ray tracing.
Last edited:
- 15,529
- Cairo, Egypt
- GTP_SEMS
They have arguably the best modeling, yet there is still no way to freely look at the interior and take pictures. Baffling.
- 566
- Spain
- Freeman_Cruz
Well, they know it at least.
In yellow:
→ Actually, there are not too many ways to see interior build-ups in the game, including Scapes.
Obelisk
Premium
- 9,529
- United States
- RMedia_Obelisk
- 1,748
- vspectra06
- vspectra06
