[a / b / c / d / e / f / g / gif / h / hr / k / m / o / p / r / s / t / u / v / vg / vr / w / wg] [i / ic] [r9k / s4s / vip / qa] [cm / hm / lgbt / y] [3 / aco / adv / an / asp / bant / biz / cgl / ck / co / diy / fa / fit / gd / hc / his / int / jp / lit / mlp / mu / n / news / out / po / pol / qst / sci / soc / sp / tg / toy / trv / tv / vp / wsg / wsr / x] [Settings] [Home]
Board
Settings Home
/3/ - 3DCG



Thread archived.
You cannot reply anymore.



File: 1437283918469.png (21 KB, 336x341)
21 KB
21 KB PNG
https://vrworld.com/2017/11/28/new-real-time-lighting-technique-holy-grail/

Opinions on this?
>>
>>594060
Hmm...
>Precomputed Local Reconstruction from Sparse Radiance Probes
I can imagine this to essentially be like a reflection capture acting in reverse. You set up probes that send out rays to determine how light should bounce within the scene and bake that information. Then, when a light is used, the it queries the probes for GI and they illuminate the surroundings based on the radiance map stored in the probe, taking into account the angle and intensity of the source.
Of course, the flexibility of such a system is pretty much what you'd expect from anything based on probes. The holy grail is for fully dynamic GI, so that if something in the environment changes, it acts accordingly. Still, its not that often that things are fully dynamic, so it's still an appreciated development.
>>
>>594066
I have no idea how that works and desu i don't fucking care. I do however care when it comes to the end result.
Does their Demo look good to you?
I think it looks good and that is good enough for me. I hate light-baking and if it makes my workflow easier and faster while giving good end results i am happy.
>>
>>594092
The thing is you still have to bake whenever you change the geometry in your level.
>>
>>594096
yeah you are right, i overlooked that sparse radiance probes thingy.
But maybe light leaking won't be a problem and at least we don't need a separate UV-map for baking.
>>
>>594092
>>594104

This has nothing to do with light maps or speeding up the difficulty light baking. The technique requires a computationally intensive bake and I bet the requirements for light maps would only increase.

This technique is targeted at quality of final result only. It gives an impressive GI-like look in realtime but if it catches on you will still have to do a hell of a lot of work to get it looking good.
>>
>>594096
then why is he moving a big ass sphere in the level and it's lit dynamically?
>>
File: .png (96 KB, 231x218)
96 KB
96 KB PNG
still leaking tho
>>
>>594131
Its DYNAMIC "REAL TIME" HIGH QUALITY INDIRECT LIGHTNING.

NIGGERS ITT DONT KNOW SHIT ABOUT ACTUAL 3D. THOSE FAGGOTS THINK THAT IF IT SAYS 4MS THEN HURRRRRRRRRRRRR ITS NOT REALTIME IT REQUIRES BAKING DURRRRRRRRRRRRRRRRR

THIS IS STUPIDITY AND FAGGOTRY. THESE FAGGOTS HAVE SUCKLED ON THE TEAT OF UNREAL BLUEPRINTS AND KNOW NOTHING ABOUT HOW ACTUAL ENGINES WORK.

"BAKING" IS A MISNOMER. THIS IS JUST ANOTHER STAGE IN YOUR ENGINES LIGHTNING ENGINE, APPLIED BEFORE THE DEFERRED SHADING STAGE. IT TAKES 4MS ACCORDING TO THE VIDEO - WHO KNOWS WHAT HARDWARE THATS ON OR WHAT REZ BUT YOU HAVE ONLY 8MS/FRAME IF YOU WANT 120FPS AND 16MS/FRAME IF YOU WANT 60FP
>>
>>594145
https://users.aalto.fi/~silvena4/Projects/RTGI/index.html
Read the paper, it's a pascal titan x. The dynamic geometry is a added in a specific way (from what I read they just have to be rather large, not sure whether their shape is restricted in any way) also they will only provide occlusion, no light bounces of them. So yes according to the paper there is still baking/precomputation required, it's not fully dynamic.




Delete Post: [File Only] Style:
[Disable Mobile View / Use Desktop Site]

[Enable Mobile View / Use Mobile Site]

All trademarks and copyrights on this page are owned by their respective parties. Images uploaded are the responsibility of the Poster. Comments are owned by the Poster.