SEGI (Fully Dynamic Global Illumination)

You need to install the unity Post Processing stack. To do this
* Click Windows
* Package Manager
* The 'All' tab
Then find 'Post Processing' in the list.
Click on it to select... Then install by clicking the install button towards the top right of the package manager window

 

thank you first ,i will have a try

 

It's just washed out when SEGI is enabled in your demo scene... any ideas?

 

Same result here, but it is much darker. No result in any of the demo scenes !

 

Thanx for testing it out ^_^. Your feedback is very much appreciated.

Nearly done working on an elegant solution to the problem. Aside from correcting the sampling logic, I've added a little more configurability to the inspector and you'll be able to both the intensite /and/ the attribution which allows dialing to the sweet spot.

Will push to the repo later when I've finished testing it out.

 

Here you go guys https://github.com/ninlilizi/SEGI/releases/tag/v.0.9.3

Let me know how you get on.

 

Hi Ninlilizi,

Thank you very much you decided to improve SEGI.

Unfortunately you latest update doesn't work properly at all. To simplify the scene I removed torches and keep Sun only.
In forward mode there is no GI at all. In deferred mode GI exists but it doesn't look like GI.
No GI:


SEGI 0.9.3 deferred


SEGI 0.83 (old)

 

Oh wow... Now that's a problem and a half. *puts on another jug of coffee*

 

Hi there,
Quick question. Does SEGI work with the HDRP?

 

So after spending way too long examining all the version and forks available... It seems where I went wrong was my choice of fork for a starting point.. It's just wrong when compared to the official releases. I went with the one that had the most post SE 'fixes' listed in the commit history. Because I thought that would make a good starting point.

All the SE versions produce differing results too... After playing with them all. The asset store version seems the best looking of the bunch... So I'm in the process of merging all my changes into that now.

Not yet... Though I plan on adding SRP support once I put out a version that actually works properly. I'm about 50% done refactoring the render loop to be SRP compatible. I'll be targeting the Lightweight pipeline first. Then the HD after that. I'm doing procedural stuff in VR for my own game. So that's my main motivation in working on this.

 

Hey guys,
Just checking in as I've been quiet for a few days.

I've rebased my changes against SE's head rather than the fork I'd previously used. Which has fixed the previous problems. I'm also most the way done with porting SEGI to the Unity PostProcessing stack. Which is the first step towards SRP support. I've not tagged a release yet though. As I've still some stuff with the forward rendering to fix. Though Deferred mode is working as expected if anyone's brave enough to pull from my repo.

 

@Ninlilizi Aww great!, thank you for keeping our hopes alive for a good realtimeGI!! I ll test your repo out ASAP

 

Doesn't seem to work. Unity 2018.2, fresh project, using the included test scene.

Getting this error:

 

Weird..... I'll look into that.....

In Other news.... After a really frustrating couple of days I've made progress on the forward rendering path.

 

Looking at that error... With it originating from OnPreRender I think your using an older commit as that function hasn't been used since I ported to the Unity PostProcessing stack. do a git Pull against the Head and see if it persists.

 

SEGI had weird issues breaking all particle billboard direction, was this fixed by any chance?

 

Particles are a nightmare.... But my main test scene I work against has a giant spinning, glowing particle thing in the middle of it.... So I'm very aware of this problem.... It's not fixed yet.... But I'm reminded it's a massive punch in the face of a problem every-time I look at the screen. I'll def try and find a way of tackling that after the core functionality is solid and stable.

 

Actually I just grabbed the latest files from the repo, the error doesn't appear anymore but the GI itself still doesn't work, there are only reflections.

 

Yeah.... Forward mode is still incomplete... Got a few more days works there.

Switch to Deferred... That uses the old logic... But it does actually apply the GI to the rest of the image. But the new reflection stuff I've been implimenting is currently forward over.... I'm gonna port that over so it's comparable results with both rendering paths once forward is done.

I'll tag an actual release when it I've got everything sorted.

 

Right, as your trying this thing out... I pushed a version that actually applies the GI to the final image just for you ^_^

 

I finally have a version ready for testing.

This release constitutes a major rewrite versus the previous ones. First off... In preparation for eventual SRP support it has been converted from a standard image effect to a Post Processing effect. As such, to use this you need to import the PostProcessing2 stack using the package manager. Then add SEGI as a pp effect. Please refer to the PP2 wiki if your unsure how to go about this.

It has been rebased against SE's repo versus the fork I'd used previously, which has corrected many of the previous problems.

Forward mode has been non-trivial to implement. But as it now stands looks far sharper than deferred mode which behaves much as before.

With the Deferred rendering path... A complete unlit scene is rendered first... Then lighting calculations are performed in a series of gBuffers, all of which an image effect has access to. SEGIs functionality very much depends on access to these gBuffers. Which simply don't exist when using the forward rendering path. In Forward the lighting is calculated by the material shaders and image effects get the final result and nothing more to work with. So I essentially had to devise a way of substituting for data that does not exist.
How I achieved this was to internally implement my own 'fakeBuffer' that contains the key data that SEGI requires. This is done by a special shader I wrote that reconstructs the missing data and writes it to a cubemap. Essentially unlit Albedo plus main directional light direction and strength are encoded into the RGB. And specular smoothness is written into the Alpha. It is generated at a lowish resolution and then subjected to a bilateral upsample to near render resolution, which minimise the performance impact of this extra pass while avoiding any visible aliasing from being introduced.

This release is currently 2018 only. After some hopefully positive feedback I will then introduce 2017 support. And hopefully that will give up a solid modern base for which to base future improvements.

https://github.com/ninlilizi/SEGI/releases/tag/0.9.4b1

 

Oh wow, the the first big GI progress from anyone in a while! I'd love to try this out when I get the chance over the next few days. I have to ask, is performance and draw range similar to original segi in deferred? And how does forward compare?

Looking forward to seeing how it goes!

 

Performance and draw range is comparable to original SEGI.... Forward is comparable in performance GPU wise, but expect extra draw calls so it's a thing if your at the CPU ceiling.

I plan to take a good stab at improving performance... But I want to be sure I've got a good solid foundation that actually works as expected first. Optimising a thing before it's baked is quite self-defeating. I've made quite substantial changes across the board while maintaining behaviour similar to original SEGI. I'm using this thing for my own procedural VR thing, so I have quite a strong motivation to improve and maintain it long term. But as I basically spent the first 2/3 of this year learning to shader specifically just to tackle SEGI, I expect someone to find something I've overlooked. So continuing to share my work back to the community helps me get better at what I do as much as it's beneficial for others. Plus it would be rude not to

 

hi @Ninlilizi !!! A quick question...

SEGI currently supports points of light and spotlight?

regards

 

That question comes to something that quite surprised me while familiarising myself with the codebase.... Going by some of the in-dev screenshots of the past, it very much looks like it was accounting for point lights.... But the pathtracer itself only cares about the main directional light in it's calculations... The reflections however pull from a gbuffer that contains final color and specularity so it piggybacks a bit of point light color while tracing for the main directional light... The current forward implementation is main directional light only.

If there is interest in some approximation of point light sources in the GI I can certainly give that a shot. But the caveat is short of some out the box creativity it's only going to be bad for performance.

 

I seem to recall Sonic Ether saying that point lights weren't supported but emissive surfaces were, so you could essentially fake point lights with very small emissive spheres.

 

Ohhh... Emissives.... That explains so much.

 

I think also something about how the number of emissives doesn't affect performance. Maybe. My memory is fuzzy on that one.

Are you considering support for either of the standard SRPs as a future enhancement? I don't know how much of a rewrite it would take for either LWRP or HDRP. It's perhaps not worth trying to attempt at all, given the fundamental differences between the legacy renderer and the SRP approach.

 

Actually I was.... That was the motivation for converting to a PostProcessing2 Effect from a normal drop on camera effect.... I've basically done about half the work required already for SRP support as part of that.

 

You are a godsend to us runtime, procedural content hopefuls.

 

Before SRP support however..... Performance is my next priority... I've an idea of a way of caching the pathtracer results where most the GPU time is eaten up... But it's gonna be a little tricky and a lot of work to implement if it works reliably enough at all.

 

Hey, put me down as interested in point light approximation - even if it does cause some performance degradation my project would only ever have GI as an optional toggle anyways, so I am willing to sacrifice performance for that. Excited to see someone working on realtime GI still!

 

Emissives in SEGI are supposed to be "free," as I recall. Are you sure you wouldn't rather use them? You could possibly set up your lighting prefabs to toggle between emissive and point depending on your GI state.

 

It may be a good option to have SEGI work also with the points of light and spotLight even if some performance is lost ... Maybe the way to go is to have it with an option that deactivates or activates the calculations of points of light and spotLight in any So, anyone could have it or take it away according to their needs ...

regards

 

@zornor90 : why not create a small script that gets all point light sources in a scene and replaces them with emissive boxes? With a distinct naming convention you can easily toggle between SEGI and non-GI lighting.

 

Still quite a hassle.

 

You should hxGI thread too, he shares high level idea and pitfalls that might be beneficial.

 

Oh, I have definitely followed all of the realtime GI solutions with great interest. I've been working on a procedural game for 2 years and not having GI has been very frustrating

HXGI in my opinion is more promising, as it uses a much more modern approach to GI which works better for interior scenes, but it looks like development on that is currently paused

 

Dang I didn't know this was revived. What did I miss after Summer?

 

Fall, you miss fall

 

Mind if I make a suggestion for optimization?

While the whole point of SEGI is to provide "realtime GI" saving voxelization time by pre calculating static mesh voxels, some sort of pre calculation won't be bad. You'd have to figure out how to merge the two "precalculated" and the "dynamic" voxels data, but if done it would save a lot of time. I know that some of you might not like the idea of "pre calculation" but even for the most extreme procedural environment, there will always be static things in general. And almost 70%+ of the things on the screen will be static once placed or spawned. How you implement it is up to you, and not my field of expertise, but hope you consider what I said.

Also, segi has cube boundaries for calculating voxels (If I remember correctly) but how about frustum occulusion of voxel generation? I am not too sure if that will help with the voxel generation speeds, and it might end up like a screen space effect - if the mesh is not visible on screen, no contribution to GI - but then you could have a cube cascade for things out of camera, and this might just do the trick regarding performance. Again, this is just what I thought off the the top of my head and could be a total waste of time. Either way, I support you and hope I can use your version (Do we even have a name for it yet?) for my HDRP project soon.

 

Absolutely, suggestions are always welcome.

I'm currently mulling over a few options for caching voxel data.... At the moment I've added a 'Update After X' option.... Which only revoxelizes the scene if you've moved a specified distance.... So if that's enabled it won't update the voxel's each frame which saves a lot of time. I plan to add a callable function to that so people doing procedural can also trigger a refresh from their code when something changes.

How to go about caching is an interesting problem to solve. As the voxels are stored inside a 3D texture array, that dataset can become quite large over time if the player is moving around a large chunk of map. One option is to set a max amount of RAM to put aside for voxel caching.... The other is potentially paging the excess data to disk. Then add a function people can call to set a chunk as dirty.

The problem with frustrum culling the voxels. Is atm, voxels can be generated. And the player can look in all directions without having to re-compute.... Start culling, and as soon as you look to the side. You either have to regenerate everything, or workout whats been exposed and somehow just fill in the extra pixels. Which is a whole bunch of draw calls for what's potentially just a few pixels. Just not very good for efficient CPU usage.

No, I don't have a name for my fork yet... I guess eventually as it becomes it's own thing it would be a good idea to differentiate it from everything else going on. But baby steps.

In the mean time, I've just pushed a few changes that save a few % of GPU time while pathtracing and produce visually acceptable results with much less steps while reflection tracing.

See bottom right of the below image for reference: (with a GTX1060)

 

I really appreciate your workings and efforts on improving SEGI. Unfortunately, I think the current look is still "buggy". If I turn off the torchgroup and set the EnvLighting to black in the Lightings-Settings of Unity, the scene looks like there's no GI at all. I can see with the Debug-Settings, that voxelization and GI is running (albeit they also seem to output quite deifferent results than SEGI 0.93).
I hope, I don't discourage you!

 

With all that said, i also think there is no visible GI result in the images !

 

Uh the image you posted doesn't seem to have GI at all?

 

Ah, yeah.... I appreciate input... It lets me know what aspects people care about.

As it was... In Forward, the application of GI was lighting more specifically based on light direction and specularity. Where as the old Deferred behaviour was a more general 'light everything' ... It makes the effect more subtle in places. But as it sounds people would prefer the old behaviour... I shall do that instead

 

Hmm, this sounds like you are calculating only directional shadows in forward mode and no any GI stuff like color bleeding from bounced light !?

 

The GI stuff is being calculated. Whats happening is that in Deferred the world space normals used in GI calculation are pulled from a GBuffer that includes the object normals AND mainlight direction in the worldspace normal calculation. But in Forward, that GBuffer does not exist. So I was substituting the camera depthnormal texture. Which encodes for main light direction but omits object normal data... .So I was attempting to compensate by encoding object normals separately... That seems to have the effect however of cancelling out the GI application where that extra data exists, rather than the desired behaviour.

 

Below is a quick comparison between forward/deferred without the extra information I was trying to emulate. If this is acceptable I can run with this behaviour instead. Or if people would prefer I could continue to figure a better way of emulating the missing GI normal attribution?

Totally upto you guys, what you'd prefer?

 

@Ninlilizi: I'm wondering where the different look comes from. Below is the same scene in SEGI 0.9.3


EDIT: Or is this the output of the gbuffer replacement?