This sounds like foveated rendering I think. The video seems like an extreme example.
I could see it being pretty handy option for traditional gaming, not just VR.
-
Hey, guest user. Hope you're enjoying NeoGAF! Have you considered registering for an account? Come join us and add your take to the daily discourse.
Game Graphics Technology | 64bit, procedural, high-fidelity debating
- Thread starter Dictator93
- Start date
This sounds like foveated rendering I think. The video seems like an extreme example.
I could see it being pretty handy option for traditional gaming, not just VR.
There is a slight misconception about out of fovea vision in computer graphics,
I guess. People think vision just gets blurred when being out of fovea (like
we see in the demo above), but that's not the full story. For example; look
straight ahead and put one of your hands way to the right or left and spread
your fingers. You can make out the fingers pretty good. They aren't that much
blurred. Hence, out of fovea rendering needs, next to some blurring, an edge
detector to enhance some of the edges.
I guess. People think vision just gets blurred when being out of fovea (like
we see in the demo above), but that's not the full story. For example; look
straight ahead and put one of your hands way to the right or left and spread
your fingers. You can make out the fingers pretty good. They aren't that much
blurred. Hence, out of fovea rendering needs, next to some blurring, an edge
detector to enhance some of the edges.
So I know I brought up Hairworks and similar implementations last time, but I'm still looking for the answers to one thing with little success. Been reading the Nvidia tweak guides and every time Hairworks or Purehair in the case of RotTR is mentioned, it just says "tens of thousands of hair strands", sometimes even tessellated hair strands. What I'm wondering is, how many polygons are actually used on these hair implementations. I've been looking around the Internet for answers for at least two weeks now but no dice.
If the tesselation is done by standard dx11 pipeline and source is quad of 2 triangles the maximum poly count per hair is 128. (Dx tesselation has maximum multiplication of only 64 and you need 2 triangles for camera facing quad.)
Of course the hair can be pre-tesselated, so maximum can be higher.
If I have understood correctly both of the approaches scale tesselation with distance as well as amounts of strands. (They increase width of hair to keep volume similar.)
Due to scaling saying 200000 strands for a creature is feasible.
So assuming that the tessellated hair strands are 128 polygons each, and a character model like Lara Croft has 30,000 individual strands of hair, doesn't that make the poly count 3,840,000 for the hair alone? Doesn't that seem insanely high?
Think I definitely misunderstood something somewhere. Can you please elaborate a bit more?
icecold1983
Member
So assuming that the tessellated hair strands are 128 polygons each, and a character model like Lara Croft has 30,000 individual strands of hair, doesn't that make the poly count 3,840,000 for the hair alone? Doesn't that seem insanely high?
Think I definitely misunderstood something somewhere. Can you please elaborate a bit more?
Does pure hair even use tessellation? I think its unlikely. If it does its definitely a very low level
Hmm, you're probably right that it doesn't. How about The Witcher 3, then? I recall reading that Geralt's beard and hair use tessellated hair strands. Similarly, the hair strand count would be tens of thousands and if tessellated to the same degree, would be millions of polygons as well. Am I getting something off here?
icecold1983
Member
Hairworks uses isoline tessellation. Not a good solution for todays gpus. Purehair is compute based and much more efficient/better looking
Now if you guys don't mind, I'm wondering about the raw polycount only. I'm not talking about how efficient or demanding a solution is. What's been killing me for the last two weeks is the polygon count for these hair implementations.
I believe for FFXV, hair is compromised of 20K polygons and it uses a mix of polygon strips and hair strands.
icecold1983
Member
Hairworks results in micro polygons which is bad even for nvidia gpus. Dont know about exact numbers tho
Hmm, thanks for trying to answer. Hopefully Dictator swings by.
Yes, it's very high. (For lara model I'm sure they do not tessellate to that high as it's mostly straight hair.)So assuming that the tessellated hair strands are 128 polygons each, and a character model like Lara Croft has 30,000 individual strands of hair, doesn't that make the poly count 3,840,000 for the hair alone? Doesn't that seem insanely high?
Think I definitely misunderstood something somewhere. Can you please elaborate a bit more?
Although I'm quite sure that the tessellation is rarely at 64x. (at least it shouldn't be 64x for whole time.)
Nvidia hardware is quite good at discarding small polygons that do not contribute to the image, AMD Polaris should be quite good as well.
Here is some tutorials on hairworks etc. (Shows LoD etc.)
http://www.cgmeetup.net/home/nvidia-hairworks-presentation-and-tutorial/
https://developer.nvidia.com/content/hairworks-authoring-considerations
Documentation.
http://docs.nvidia.com/gameworks/content/artisttools/hairworks/product.html
TressFX
http://gpuopen.com/tressfx-3-1/
http://amd-dev.wpengine.netdna-cdn....The-Fast-and-The-Furry-Nicolas-Thibieroz.ppsx
Purehair/TressFX3 in Deusex
http://cdn.wccftech.com/wp-content/...-in-Deus-Ex-Universe-Projects-TressFX-3-0.pdf
Thanks for the links. I may finally get the answer I seek!
Anyway, do we have any idea roughly how many polygons Lara's hair on Purehair uses? Pardon me if it's in those links, I can't read them now, I'm in class.
Okay, so assuming the tessellation factor is at 4, that would be 4x2=8 polygons per hair strand. 30,000 hair strands would be 240,000 polygons for the hair alone. Even that seems kinda high for XB1 hardware.
dr_rus
Member
Not good for GCN GPUs you mean, NV GPUs are perfectly fine with it, subpixel triangles will be discarded. Purehair doesn't use any compute as far as I'm aware (unless you mean for animation / physics), it's purely VS/PS based.
Dictator93
Member
Speaking of hair...
This came out the other day... the talk in its full with commentary and whatnot. Quite interesting.
ZBrush Summit 2016: Naughty Dog
This came out the other day... the talk in its full with commentary and whatnot. Quite interesting.
ZBrush Summit 2016: Naughty Dog
Awesome read, but I'm wondering how long this will sit in the experimental branch. There's also the issue that Vulkan isn't widely used yet either.
I'm always excited to hear about advances that make doing work on the GPU more efficient. Not sure when this will ever translate over to games properly though lol.
Nice.
Matt Pettineo (Ready at Dawn) posted a series about spherical gaussians (used for TO1886's lightmap representation) on his blog.
https://mynameismjp.wordpress.com/2...ries-lightmap-baking-and-spherical-gaussians/
Excellent Timothy Lottes post series about post processing and HDR and why we can never have nice things:
https://timothylottes.github.io/20160721.html
https://timothylottes.github.io/20160723.html
https://mynameismjp.wordpress.com/2...ries-lightmap-baking-and-spherical-gaussians/
Excellent Timothy Lottes post series about post processing and HDR and why we can never have nice things:
https://timothylottes.github.io/20160721.html
https://timothylottes.github.io/20160723.html
Motion blur raising the APL? I wonder if this is the cause of UC4 looking overly bright out on the beach scene during HDR gameplay.
I wonder if some may also mistake this for auto-vignette in games as well...
So, if I'm understanding this right, the GI solution in The Division uses the typical (?) pre computed irradiance transfer, but can be considered real time because it is updated every frame? I recall Mirror's Edge Catalyst doing something very similar. Also, 0.95 ms on XB1? That's relatively cheap for a 33.3 ms frame time.
Updating the lighting result in real time for cheap GI is the entire point of precomputed radiance transfer.
In The Division, there's essentially an ultra-low-precision representation of the game world that probes use. Using this simplified representation, the game can render an ultra-blurry "cubemap" of sorts at the location of each probe every frame.
These probes then get used to create a lighting volume, which is used when rendering the actual scene.
The simplified world representation can be lit by the sky and sun, by local dynamic lights, and by the probe results from the last frame (this results in light bounce). However, it's only aware of geometry that existed at the time of precomputation; dynamic objects are lit by the results of the probes, but they do not affect the creation of those results. This is the "not real time" aspect of it: the representation of the scene that light bounces through is baked.
antyk
Member
I learned a new word on page #16 - a "surfel". A surface voxel? A voxel's surface?
Dictator93
Member
Ah, interesting. Thanks for the explanation. There are so many methods of "real time" GI that I should list down all of them, haha.
This here is pretty much the sexiest volumetric smoke I have seen sofar. I am a pretty technical artist myself, but this here is wizardry for me. People like fancy effects, so thought I would share ^^
https://www.youtube.com/watch?v=hWNX9jGEt8k
http://shaderbits.com/blog/creating-volumetric-ray-marcher
https://www.youtube.com/watch?v=hWNX9jGEt8k
http://shaderbits.com/blog/creating-volumetric-ray-marcher
This looks awesome. I would love to see nebulas in a space game that look like that.
There was alias free sampling of volumetrics a while back.
https://github.com/huwb/volsample
http://advances.realtimerendering.com/s2015/index.html (more detailed description in .PPT)
https://github.com/huwb/volsample
http://advances.realtimerendering.com/s2015/index.html (more detailed description in .PPT)
Thanks for sharing!
Wanted to see their approach to GeoGache in gaming as I use it a lot in Maya/Max to lighten the load of my working scene when doing VFX stuff at work.
Dictator93
Member
There was a paper / blog entry I think not too long ago about adding a blue noise filter instead of the usual white noise or dither pattern stuff you see for things like screen space ambient occlusion among other diffuse stuff, anyone have a link to that?
I cannot find it :/
I cannot find it :/
Here is nice collection of links on subject.
http://momentsingraphics.de/?p=127
Also nice one.
http://loopit.dk/banding_in_games.pdf
Found some nice presentations.
I3D2017 papers
including.
Real-Time Global Illumination using Precomputed Light Field Probes
Tiled Light Trees
Hopefully GDC2017 will make this thread bit more active again.
I3D2017 papers
including.
Real-Time Global Illumination using Precomputed Light Field Probes
Tiled Light Trees
Hopefully GDC2017 will make this thread bit more active again.
dr_rus
Member
In Paper they test light trees with 65k lights but does anyone have any idea how many lights current gen games average and max per frame?
dragonelite
Member
The slides are talking about performance improvement that is the marketing DX12 used.
Not that it would be easy, or do mean more like Dx12 marketing on games?
Because a lot of games if i'm not mistaken just did d3d11 on d3d12 ports.
i think some CryEngine games had like up to 5k per frame.
I think Frostbite supported even more, but dunno about real usage.
Based on how abysmal most DX12 implementations have been, I'm not surprised in the slightest.
The only good DX12 game I can think of is Gears of War 4 and it was a Microsoft-owned studio that created it lol
Because most studios just convert some of their engine code to DX12 and call it a day.
Star Citizen devs said that they first eliminating all old legacy code that was there since DX9 and convert everything to DX11 and then convert core components from there to DX12.
They working on it for a year already and they still do not have ETA, because its really big change for such a complex engine.
Frozone
Member
The number of lights could be any number if using deferred rendering (limited only by the framebuffer size). The actual cost of lighting is in creating shadows for each one. I've only seen at most 2 shadow-casting lights within a good radius of the camera. IMO, this is the biggest hurdle to jump for that next step in realism.
Thanks for this!! I am also looking forward to the GDC as well!!
Not quite. Shadow is an added (potentially big) cost but the lighting is nowhere near free even in deferred lighting engine. The metrics used usually is in term of lighting overdraw (how many lights can I afford per pixels?). Depending on how efficient your deferred engine is, acceptable values may vary widely.
Framebuffer size doesn't limit amount of lights.
Doom had quite nice amount of shadowing lights, it used shadowmap caching to reduce unnecessary work.
I wouldn't wonder if modern games have up to tens of thousands of lights in a normal frame.
Uncharted had fun little trick with 64k lights for a bounce light from flashlight. (Lights distributed in dithern pattern within frame, TAA to combine.)