Intro
As you probably know if you’ve seen my previous posts, I’ve been building GI technology after GI technology in an attempt to achieve Realtime low-impact GI, My latest attempt is the closest I’ve gotten to this goal, the attempt is a novel method called EGI (Environmental Global Illumination), EGI (referred to as i5), Is the 5th major rewrite/reattempt at this form of GI.
Brief Technical Overview
Each iteration is defined by i#, for example my first ‘true’ gi system is named i2,
i2 SRTGI
The first ‘true’ gi method I’ve used, SRTGI (Simple RayTraced Global Illumination) was a dualbounce global illumination method, it has been deprecated and merged into i3 as the ‘TraceSun’ config option. i2 only calculates GI from the sun.
i3 ARTGI
A rewrite of i2 designed to unify some features as well as add support for ‘emitter probes’, ARTGI (Advanced Raytraced Global Illumination) functions basically the same as i2 however it has been changed from raycasting from the sun to a function that intakes an object value allowing for the emitter probes system.
i4 RTEGI
The first novel, ‘is it really gi?’ approach, RTEGI sample the environment similar to the new i5 EGI system however the way they sample is much different, RTEGI grabs color data from its raytracing, it sends 3 rays per frame and blends the final product together using color3:lerp()
i5 EGI
A continuation of ‘is it really gi?’, EGI samples the environment by getting objects in a set area, It blends the colors it receives in a similar way however with the much less costly GetParts Functions, It samples 25 object colors per frame and it samples in a cubic area of 30x30x30.
‘Is it really gi?’ explained
While no EGI and RTEGI are not on a functional level GI, it isn’t because they don’t raytrace but rather they don’t illuminate based on light, The ‘GI’ is essentially ENVAmbient, It adds ambient light to a scene matched to colors within said scene rather than based on the scene and the lighting within the scene.
Why dont i4/i5 support lighting?
Short answer :
Performance.Long answer:
The current methods I know of aren’t performance friendly,
MaximumADHD’s LightLib is too costly to run every frame, every probe
Raycasts are costly (but possible) to run every frame, every probe however the goal is Realtime performance friendly not costly in any way.Why EGI? What’s next?
The new EGI method is extremely low impact and can run on most low to high end desktop hardware. After basic EGI is done it will be renamed to SEGI and the new i6 AEGI will release, what will the difference be? AEGI will include support for light based emission, In other words AEGI adds to the lighter areas of a scene then lets the light flow through until its emission is 0. Ill release i6 and images of it when im ready.
What is the point of Horizon?
I intend to demonstrate i2,i3,i4,i5 and in the future i6 and i7 in a place with a super easy to use interface, Shortly after the release of Horizons I will be open sourcing the i2/3 architecture (After some polishing), Functionally the architecture wont change from the version in horizon, including bugs I’m too lazy to tackle for what’s now ‘legacy’ to my team.
Ok why do I care?
My team will open source everything until the last iteration, As the systems evolve and mature they release to the public, This demo shows them off before that release. Technically you can steal them with exploits because the systems are local however I advise against it as the versions published early within horizons are usually unpolished and messy.
Finally, The release.
Horizons Game Link
