SEGI (Fully Dynamic Global Illumination)

That's a great idea actually simply because people will ask how to make SEGI faster/more efficient and then we'll say proxies and then they'll ask how to do that SO...lets just get a guide up detailing what needs to be done so we can all just link to it

-Steven

 

NOT IT!

 

I have to be honest and say if I saw these images side by side and were asked which looks better, I wouldn't know! They just look different.
But this is an amazing thing. The takeaway I'm getting from this is "Performance improvements and it still looks awesome". That's precisely the direction I was hoping segi would go.

Very pumped for this feature . Keep it up!

 

Agree !

 

This is coming along very nicely! And I'm surprised nobody mentions the Vram usage improvement (divided by 4!?! that's awesome!).

However, please Sonic, in the next update when you add the cascades, let us the ability to turn on or off this sequential order rendering. I am very septic toward this technique.
I'd rather have a constant low-frame rate than an instable high frame-rate any time of the day. This technique so far sounds like a try to focus on numbers instead of user experience.

Anyway this is a great update! Keep up the good work!

(Also I didn't saw you contact shadow asset on the asset store last time I checked, hasn't it been released?)

 

yup

 

It's here: https://www.assetstore.unity3d.com/en/#!/content/77836

 

It is great!

Sonic, could you add Voxel Resolution 512? Actually, my 1080 has enough memory and can handle 512 in the current version SEGI. I've add 512 option in the script myself but light in a scene was overexposed; I guess the structure that keeps voxels is not float, so it was just the byte overflow. I believe it would be relatively easy to fix.

Sonic, in the code there is line that confuses me:
voxelSpaceOrigin = new Vector3(Mathf.Round(origin.x / interval) * interval, Mathf.Round(origin.y / interval) * interval, Mathf.Round(origin.z / interval) * interval) + new Vector3(1.0f, 1.0f, 1.0f) * ((float)voxelFlipFlop * 2.0f - 1.0f) * voxelTexel * 0.0f;
Is that a bug?

 

Agreed!
Actually, considering the potential of cascading, having the ability to manually enter the voxel resolution would be great (I'm sure I would be able to use 32x32 for low specs in a descent way, and being able to push it without limits would really make it future proof).

 

+1 to 512x512 (even if it will consume 4.2Gb of VRAM without cascades) and values below 128x128 - sometime it can be useful for bullshots or just for own pleasure seeing better lighting on the level.

At least if it is all about just minor efforts from coding side...

 

This is really exciting news! Thanks for the update Sonic.

 

Just another quick update, I've changed the cascade updating scheme such that each cascade level gets updated approximately every 2^cascadeLevel frames. So, the first level (closest to the camera) gets updated every other frame, and each successive cascade level gets updated half as often. This means that the GI data closest to the camera updates often, and the GI data furthest from the camera is updated less often.

Here's a graph demonstrating this updating scheme. The X axis is the frame number, and the Y axis is which cascade level to update (lower is closer to the camera). I'm definitely not a mathematician, so I'm sure there's a simpler way to calculate this. https://www.desmos.com/calculator/x20ts2lsg7

When a cascade is finished updating, it pushes its voxelized result to the overlapping area of the higher cascade levels. This means that the higher cascade levels don't need to revoxelize what's already been voxelized by a lower level and this area is skipped during voxelization.

I'd also like to look into being able to specify "dynamic objects" and have them voxelized every frame regardless of which cascade level they're in. This may or may not be practical, but it's something I've been thinking about.

I agree with you that it's not optimal that one frame costs more to update than another, but the alternative is to stack all of the updates together every single frame and this would really not perform well. Perhaps I'll think of another alternative, but for now, I feel that the updating scheme outlined above is the best compromise.

I suppose I can enable setting the resolution that high, although you must keep in mind that not only will VRAM usage go up, but voxelization and voxel data preparation will take much longer. For this reason, I think that a 512x512x512 voxel data resolution is impractical.

With cascades, the new "high" equivalent setting resolution is 128. I can include an "ultra" option for 256, although it won't perform well, once again.

And as far as that weird line of code that you found, that was an experiment I was doing where I was temporally jittering the voxel volume by half a voxel texel (like TAA on the voxels). I multiplied that term by 0 to disable it and I guess I forgot it was there and never removed that term!


I've got a question for everyone as well. Do you think that SEGI should just move to cascades instead of a single voxel volume with mipmaps, or should I keep both functionalities and have the user decide? If things keep going the way they appear to be going in development, cascades seem to be the superior option across the board. So, if this ends up being the case, will there be any need to keep the old functionality?

In any case, for the first few updates of SEGI that include cascade functionality (and perhaps indefinitely), I'll probably have SEGI.cs (the main script you've been putting on the camera) have the old functionality, and have a new script "SEGICascaded.cs" with the cascade functionality. This will be the most painless way for me to keep both functionalities, and it'll keep the results in your scenes that already have SEGI.cs on your camera the same.

 

Save dev time and go with the superior solution. Now, if having the functionality of both is trivial, then more user options are always better.

 

I've just tested the free asset "Corridor Lighting Example" with SEGI, Voxel Resolution 256. Nice! Out of box, just deleted reflection brobes and all lights, no LOD optimisation. Then I've tryed 512 - agree, it is too much, 34FPS max. However, please keep 256 as the option for the cascades solution.

I vote for the cascades as the high priorite.

 

This forum has been fairly dedicated to experimenting with SEGI as updates are pushed out. Probably a good idea to enable both options for now while the asset matures and let one option deprecate naturally, if that occurs.

 

Thanks for the awesome updates. Can not wait to try this out. I would definitely say exactly like SteveB above:

 

That absolutely should work !

 

Whether or not you support just cascades or both solutions completely depends on the development time required to maintain both vs how many people would use it for how much benefit.

My gut feel is go with cascades to be able to drive more value elsewhere.
I suppose that's what I would prefer personally.

 

Hey guys, can we make "Update GI" to refresh slower? that may improve performance.

 

Seems to me that the cascades is a good way to go. Might be worth maintaining both for a short amount of time to see what the community comes up with? My gut says the cascades though are good because of the performance gain.

The thing Im most concerned with atm is the metalness reflections looking really dark. We've been really happy with SEGI and folding it into our project (hate waiting on enlighten so much). I believe you mentioned you are working on it though.

 

As the question seems to be about whether a single voxel volume with mipmaps has a reason to stick around, I personally think that if cascades continue to be superior in performance and visual quality across the board, then there are no reasons not to completely commit to the superior method.

However, if it turns out that cascades cause problems for certain scenes, that aren't a problem for a single volume, then there may be a place for them..

I'd say it's worth the gamble

 

I'll add to the 'both methods' voices - at least for the first release of cascades, so users can give both a good test in the wild. I suspect that's extra extra work, and you're already doing so much.

 

This can be done from long time ago. Read thread. I don´t remember how exactly.

 

Thanks, found that post (from July 13):
https://forum.unity3d.com/threads/segi-fully-dynamic-global-illumination.410310/page-6#post-2705803
Anybody knows how to use that script (where to put that code)? Just to test how spiky will be FPS if update interval is about 10 frames...

 

Just put it on any gameobject and give it a reference to the SEGI Object on your camera. Adjust the time to the interval you want.

 

Hell just chuck it onto the Main Camera right under SEGI and you're golden

 

VertexSoup made a much improved version of the script taking also movement into account for triggering an update.
Be sure to use his version :
https://forum.unity3d.com/threads/segi-fully-dynamic-global-illumination.410310/page-7#post-2708866

 

Could it be that SEGI is not working in unity 5.5.1
nothing gets voxelized ect. (emissive mats not working)

in any of the 5.4 versions i got no problems at all

 

The last version works with Unity 5.5 f3 as I know. That should work with 5.5.1 too.

 

yeah it does
Found out that Assets seem to change their "Update" Status based on the unity version you look at them.
-> some Assets need to be redownloaded even if they are "up to date"
or maybe the downloader is broken ^^

 

Here some live tests with that script (first two shots with all post effects enabled):


When enabled this SEGIHelper script gives around +10% of performance (and it is definitely working - update delay is easy to see). Changing "Update interval" from default 1 second to 0.16 (160 milliseconds - roughly each 4th frame) still gives same +10%. Feels like "Update interval" only affecting voxelization stuff but not affecting lighting calculations inside those voxels*?* (most heavy thing here) and they still perform their duties every frame...

 

Only downside of this script is that the screen seems to freeze for a tiny bit of time when the GI is told to update. I hope that with the cascades implementation, the performance is stable enough to make such scripts obsolete...

 

Hmm... In practical scenarios the voxelization is the most heavy stuff. Have you tried out a standalone build? What is you performance if you hit play and disable UpdateGI manually after initial voxelization is done?

EDIT: I've just seen that you have a pretty high resolution. Maybe the lighting part is slow then. What GPU do you use?

 

GPU is GTX 1070, SEGI settings was on high:


Here is screenshots from build with screen resolution 1280x720 and 2560x1440 - performance is almost linear to amount of pixels on the screen (0.92M and 3.7M):


Also did that test with disabling GI update at play - if SEGI Helper script is enabled there no performance boost, if disabled I have got +10%. Somewhat expected result - almost everything in the level has simple shaped GI proxy geometry, there is not so much to voxelize.

 

I love your Reflections, looks similar to candela ssr. is it nearly the same and to you plan a opengl or vulkanrt version?
So i can use it on Mac and Windows?

 

@sonicether, great job! I very intrested in your asset, because my game target to DX11+ videocards with realtime generated levels... And I need ask some questions:
1. Do you plan implement SEGI for OpenGL/Vulcan/Metal apis?
2. We use custom shaders... Any SEGI api need to be integrated to them?
3. Whats plan in time goes from beta?
4. SEGI can handle big maps (with isometric like in diablo 3 camera)? SEGI update grid when camera moves or not?
P.S. Anyway - its greate job, man! Dont leave to work on this!

 

Hello everybody,

i thought i had read something about SSAO vanishing from the store and coming back as a free asset (waiting for approval or something). This is quite some weeks ago and since that time i´m regularly checking the store for the asset.

SSAO was on my wishlist for quite some time and i wanted to have it for my current project, since i´m already using Bloom and SEGI. Any news when the asset is coming back? I don´t really care if it´ll be free or not (though a free version is much appreciated), just need it for the project.

 

Check the SESSAO thread.

 

when will this update be out

 

Hi Guys !
New to Unity and SEGI, it's a real pleasure to work with.
I'm making some test for a job.
The constraint is everything is realtime.
Everything is working great except for strong reflection like glass and mirror.
The SEGI reflection is not enought precise to make it work and the reflection probe in realtime doesn't take in account SEGI.

I test to do a target texture, to see if there are any GI in the output.
And it's ok.


I have got an idea to make a cubemap from this camera output, and to inject that in the reflection probe.
But there is a strange problem ^^;...
My cubemap take into account my camera \o/ it's great !
But it take the viewport too oO !


Is there a way to avoid that ?
Am i doing something wrong ?

 

Maybe try to run cubemap script (good idea!) when you switched to "Game" view?

 

Thank you for the answer Lex4art.
Did it ! And not working
It is possible a script issue ?
Here it is :

Code (CSharp):

1. using System.Collections;
2. using System.Collections.Generic;
3. using UnityEngine;
4.  
5. [ExecuteInEditMode]
6. public class RenderCubeMap : MonoBehaviour {
7.     public Cubemap m_cubemap;
8.     public Camera m_camera;
9.  
10.     // Use this for initialization
11.     public void OnEnable () {
12.         m_camera = GetComponent<Camera>();
13.     }
14.  
15.     public void Update()
16.     {
17.         UpdateCubemap();
18.     }
19.  
20.     // Update is called once per frame
21.     void UpdateCubemap () {
22.         if(m_camera != null && m_cubemap != null)
23.         m_camera.RenderToCubemap(m_cubemap);
24.     }
25. }
26.  

 

I’ve found out that using GI blockers is mandatory in some cases. Besides GI blockers creates pretty good shadows from GI.
The simplest way to create the GI blocker is duplicate an object and assign new material with GIBlocker shader. I have concern about the performance. Does anybody know about the cost of GI blocker? Should I use LOD or even create a scaled cube (or set of cubes) to replace the original object?

 

I can't imagine fidelity would be important with a GI Blocker so yea, I'd totally use an LOD or even as you said just basic cubic volumes.

 

Hey there!

Got this leaks

almost disappear when I turn off half resolution. Is this a bug or what?

 

http://i.imgur.com/KIda2eD.png

 

The reflections in SEGI simply use voxel GI data, not screen-space data like candela ssr.

1. Once Unity exposes or integrates Vulkan/Metal API, I'll make sure SEGI works with them.
2. Your custom shaders need to be deferred, in that, they need to write to the deferred gbuffer.
3. It's hard to say how long it'll be in beta. Development for this project is largely unpredictable.
4. It really just depends on what kind of lighting detail your scene demands. Cascades should really improve how well SEGI handles large scenes.

Yep, GI blockers are definitely important! Just be sure to assign a unique layer to them so you can have your main camera not render GI blockers (omit the GI blocker layer on the camera culling mask and include it in the GI Culling Mask in SEGI so they're only voxelized and not directly rendered).

This can happen when half resolution is enabled and your game window resolution is not an even number in both axes. Try setting it, for example, to 1280x720, and those artifacts should disappear. I need to improve the bilateral upsample pass so that it can handle odd resolutions.

 

1. For glcore all done or only planned?
2. Its very nice. We use deferred.
3. Good luck with it!
4. We dont have far planes for cascades, only diablo style view. All geometry in frame can (as i think) handled with one grid. If grid can build aroud custom proxy object (not around camera) and it will updated when proxy move - its will be perfect.
5. Can I sample information like SH lightprobe for point in grid volume? For example if I want GI on transparent objects.

 

For #5, I suspect you'll have to wait until forward-rendered objects are supported--something many of us would like to see.

 

Yep!
I just came here to see if Forward-rendering has been added yet, sad to see it's still not compatible.
Our game's main shader requires forward rendering, so although SEGI looks beautiful in use we're unable to use it until Forward Rendering is added