i need a favor re: imperfect shadow maps

Started by
11 comments, last by Lightness1024 11 years, 5 months ago
but crytek doesn't do any preprocess for LPVs, right? so they're generating that voxel grid in real-time by deconstructing/resampling gemoetry?
Advertisement

but crytek doesn't do any preprocess for LPVs, right? so they're generating that voxel grid in real-time by deconstructing/resampling gemoetry?

Not *exactly,* no. The specific process that survived its way into Crysis 2 was to generate a reflective shadow map that described the amount of reflected light, then inject every texel from said RSM into the light propagation volume. This is specifically how global illumination was achieved, and the reason why there aren't any indirect shadows; visibility was entirely implicit. You can run a separate grid that contains information on how much light (if any) is allowed to pass through a certain voxel and use that to help propagate light more correctly, but this wasn't done in Crysis. The results can still look quite acceptable when combined with SSAO or alternate techniques that generate SH visibility directly.

EDIT: Here's the actual LPV paper.
clb: At the end of 2012, the positions of jupiter, saturn, mercury, and deimos are aligned so as to cause a denormalized flush-to-zero bug when computing earth's gravitational force, slinging it to the sun.
with LPV everything is doable without precomputation in 10ms per frame for 2 cascades depending on the quality of your injections. though, geometry injection is difficult to get right and theoritically flawed because of density issue from buffers with perspective. this is not mentioned in the papers but its a real flaw and issue that makes camera GV unsuables and therefore GV is almost useless. It works more or less from at least 1 million or 2 millions blockers (points injected) which takes more than 50ms per frame per cascade which is not acceptable. nvidia demo even uses peeling up to 4, multiplying this cost by 4 ! of course, to remain reasonable they reduce injection quality and the result is a flcikering solution with camera movments. also quite frankly the propagation is poorly controllable and in many demo i've seen doesn't seem to respect a correct energy attenuation. the paper says they respect perfect energy conservation, which from experience, I don't believe they actually have. Andreas Kirsh mentioned some mistakes, and he himself made some mistakes in his anotations (c.f. radiance formula that misses surface term). Mixing SH and Radiance/Intensity/Flux into one technique is the best recipe for getting a mix of un-understandable units and magnitudes of the values you manipulate. c.f Sebastien Lagarde "to Pi or not to Pi in your game lighting equation", c.f. "radiance from irradiance" [ramamoorthi] which is a very complex paper that has brought confusion in the mind of many since its existence, and making people mix the both terms like if they were equivalent much too often.
Also, I have nowhere seen a clear explanation about units that stores SH distributions representing light (is it radiance, intensity, flux...) and the normalization that are necessary or not (pi, 2*pi, 4*pi, smthg else ?)
the result of all these complications make that LPV can be good or bad depending on how much you rely on your math (probably false) or empirical values (probably false as well, but at least artist tunable).

This topic is closed to new replies.

Advertisement