SEGI (Fully Dynamic Global Illumination)

One thing to note is that SEGI is a screen-space effect, and it needs (almost certain) the depth buffer.

The problem with dual camera setup is that some things are not passed between cameras, which makes a lot of screen-space effects limited (and shadows on first person objects).
I was able to get around a few problems by implementing a 3 camera setup using a render texture, which allow me to have screenspace effects that need the depth buffer of the first camera, like ambient occlusion and allowed me to have first person shadows with a more or less simple setup. You can check it here. http://forum.unity3d.com/threads/fr...nt-shadow-support-and-independent-fov.356711/ , it's free and you can see how i did it and change it if you need to.

Now, that implementation is also limited. Depth based effects don't cross cameras (i've been trying to merge depth buffers, but haven't spend much on it), so you could use SEGI on the first camera and it will work well with the environment (haven't test it, but it should), but it won't affect the first person models, so the second camera doesn't get SEGI.

I'm working on another technique that only uses 1 camera + custom code in shaders and all of these problems should go away

 

Thanks @eskovas. I'll check this out when I get the chance.

As it is right now, I don't mind losing the SEGI effect on the weapon camera. If there is an easy fix that passes whatever necessary information between cameras, I'm cool with it.

I'm curious to learn if anyone has a solution worth trying too.

 

Updated helper a bit to trigger either after certain time or passed distance. Feel free to build upon it. Use at your own risk.

Code (CSharp):

1. /*
2.     Original author: scheichs, http://forum.unity3d.com/members/scheichs.401530/
3.     Modified by: Peter Matejovsky, Vertex Soup
4. */
5.  
6. using UnityEngine;
7.  
8.  
9. /// <summary>
10. /// Helper class for SEGI enabling it to update GI either after set time interval or camera move distance,
11. /// whichever is triggered first.
12. /// </summary>
13. public class SEGIHelper : MonoBehaviour
14. {
15.  
16.     [Range(0f, 10f)]
17.     [Tooltip("Regular update interval in seconds.")]
18.     public float updateInterval = 1f;
19.  
20.     [Range(0f, 100f)]
21.     [Tooltip("Update distance in meters after SEGI is triggered to recalculate GI.")]
22.     public float updateDistance = 10f;
23.  
24.     internal SEGI _segi;
25.     internal float _nextUpdate = 1f;
26.     internal bool _warmUp = true;
27.     internal Vector3 _lastPosition;
28.     internal float _updateDistanceSquared; // using cached square of distance for some performance gain
29.  
30.     void Start()
31.     {
32.         if (!_segi)
33.         {
34.             _segi = (SEGI)GameObject.FindObjectOfType(typeof(SEGI));
35.  
36.             if (!_segi)
37.             {
38.                 Debug.Log("<color=red>No SEGI in scene to use!</color>");
39.                 return;
40.             }
41.         }
42.         _lastPosition = _segi.transform.TransformPoint(_segi.transform.position);
43.         SetUpdateDistance(updateDistance);
44.     }
45.  
46.     void Update()
47.     {
48.         if (!_segi)
49.         {
50.             return;
51.         }
52.  
53.         CheckUpdateDistance();
54.  
55.         if (_segi.updateGI && !_warmUp)
56.         {
57.             _segi.updateGI = false;
58.         }
59.  
60.         _nextUpdate -= Time.deltaTime;
61.  
62.         if (_nextUpdate < 0)
63.         {
64.             RefreshSEGI();
65.         }
66.     }
67.  
68.     void OnDisable()
69.     {
70.         _segi.updateGI = true;
71.     }
72.  
73.     /// <summary>
74.     /// Enable to dynamicaly set update distance from other scripts.
75.     /// </summary>
76.     /// <param name="distance">Distance in world units (Meters).</param>
77.     public void SetUpdateDistance(float distance)
78.     {
79.         updateDistance = distance;
80.         _updateDistanceSquared = distance * distance;
81.     }
82.  
83.     /// <summary>
84.     /// Assign target SEGI from external call.
85.     /// </summary>
86.     /// <param name="target">SEGI MonoBehaviour</param>
87.     public void SetTargetSEGI(SEGI target)
88.     {
89.         _segi = target;
90.     }
91.  
92.     internal void CheckUpdateDistance()
93.     {
94.         if ( Vector3.SqrMagnitude(_lastPosition - _segi.transform.TransformPoint(_segi.transform.position)) > _updateDistanceSquared)
95.         {
96.             _lastPosition = _segi.transform.TransformPoint(_segi.transform.position);
97.             RefreshSEGI();
98.         }
99.     }
100.  
101.     internal void RefreshSEGI()
102.     {
103.         _segi.updateGI = true;
104.         _nextUpdate = updateInterval;
105.         _warmUp = false;
106.     }
107. }
108.  

 

Double nice!

 

@eskovas I had a chance to try out your asset. I take it there is no way of getting around having to add that object script to every object in the game?

 

Great mod and clean-up of the Helper script. Just 2 notes that would make it even more perfect:
1) Maybe you can check if SEGI's followTransform property has been assigned and if yes check the distance to that one.
2) In order to avoid graphical issues you could clip the max distance to half(?) of SEGI's voxel-space size.

 

If you want first person shadows using that method, then it's necessary. Every other things i've tried simply didn't work or had worse performance.

Btw, if you have more questions about the asset, ask them in the official thread this is a SEGI thread.

Edit:
I'm still waiting for that one person that can make a First Person Render actually work in Unity. Seriously, i see this in every FPS game and Unity still doesn't have a solution!
My solution is just a "hack" and a workaround. Not really an implementation.
I've also talked and asked many people about this, and none of them have been able to solve it. It's really weird.

 

I think this is important to mention here...

...when you think about what it is GI brings to lighting, consider the broad strokes of warm bounce lighting on a sunny afternoon, color being passed from surface to surface, the even distribution of ambient light from a cloudy day or just the opposite, but the fading light energy of ambient occlusion. This is why it isn't necessary to have every single polygon contribute it's insignificant light energy distribution out into the rest of the world.

Think of how many games got by with simulating bounce lighting from the warmer parts of lighting, or heck using negative lights to darken areas. Now with advances in AO which are quite robust, we've been able to achieve a very high level of fidelity without 'actual' global illumination.

Raytracing isn't even a 'thing' yet really, and we're still faking shadow-mapping. Here we're sitting on realtime GI that is rather performant and I'm not even finding myself doubting it's fidelity...it feels right. People can argue all they want on how much it saps performance, but honestly just like the requirements of the bleeding edge immersion of VR, I'm not expecting any system with less than a 980 to be running a game with realtime GI.

REALTIME GI

...so yea, we're looking quite good here with this bad boy.

Now @sonicether, where's that next release!?! Lol!!

Cheers guys

-Steven

 

I'm wondering if we'll get an update when screen space tracing gets done as it should significantly improve the visual quality over what has gone before.. that's a wild guess though, was just looking at the roadmap on his site. Thankyou to everyone providing solutions and workarounds for current shortcomings.. only updating the GI intermittently is a very good idea

I could have sworn i saved my post about VR but in short - Haven't tried SteamVR, works slowly but consistently with OVRCameraRig and oculus native in 5.4b25. It's not 'fast' at all but this is absolutely to be expected. Making proxies for your scene and updating intermittently should both provide good gains, opportunity to test this out on a meaningful project maybe coming soon. If you have any card less than a 970, don't get the hopes up that is will be for you necessarily, and this should be an understood and accepted caveat. Although if it does get particulrly faster (which is probably will) then you never know, just right now its a beta, unfinished, you're testing as early adopters, that should be understood.

No, i thought this was a tired trope but here you go, it's not really going to work well right now in your mmorpg full of speedtrees if you can't figue out how to do what Eskovas did (again, thankyou) yourself.

 

@SteveB the effect I am going for is not achievable by GI, hence why bloom is very important and ultimately the ability to render bloom post GI.

My plan is to pump up the emission on certain lights to create a deer in the headlight effect; where you cannot really see your enemy when in direct light. The following image is overkill, but something along these line:



When bloom is applied to the main camera as oppose to the weapon camera, the effect dies:



I'm using SEGI for different reasons in my project. Both SEGI and SE Bloom are important though, and that's why I am in need of being able to render both as planned in their respective orders.

 

Oh you might have misunderstood me. I was merely using your comment to start soap-boxing to everyone else...that GI isn't necessary on a granular level, and what you said just triggered my thinking on this. People have been arguing about SEGI and the need for it to be 100% GI, 100% of all their objects in 100% of their game worlds, and I can't help but roll my eyes a bit, especially when you step back and realize just what it is we have in our hands currently.

But yea, my comment wasn't directed at you in fact.

Cheers man

-Steven

 

Sorry @SteveB, my misunderstanding. S'all good man

EDIT: I do have to second how glorious it is to have what we have in terms of technology!

 

So, I setup something like this where only half the voxel volume was voxelized per frame, and the problem was that whenever the voxel volume moved, half of the volume would contain invalid data. I tried reprojection techniques to solve this problem, but it couldn't be solved completely.

Here's the thing, though. Once voxel cascades comes along (I've got the basic functionality working, I just have to adjust the tracing algorithm to look good again), there will be an option for how many cascades you want to "update" per-frame. Having only one cascade update per-frame is a lot faster than voxelization is currently (since each cascade is only 64^3 or 32^3 resolution).

Oh, and I'll be submitting an update in the next few days for the "Smarter voxel data encoding for reduced memory usage and faster voxelization" feature on the roadmap. This improvement provides a 1.5x speedup for voxelization (in my tests). I've just gotta make sure everything is totally working before I submit the update.

 

Oh i see, that makes sense. Maybe, one solution for that would be to have a really low resolution voxel on the invalid section of the volume, and the next frame would voxelize with the normal resolution.
Anyway, i'm just throwing around ideas. Thanks for trying out my suggestion

Looking forward to the next update. I'm up for anything that can boost performance.

 

Ah shows me being wrong but it's a good wrong in this case

 

Hi,

First : Thank you so much for SEGI. If my english wasn't so bad, I wrote a song so the bards can spread your glory.

I use SEGI for architectural visualisation and I want the SEGI reflections on perfectly transparent windows.
However, transparent objects interact with the GI so I exclude the windows by puting them in an other layer.

Is there a way to have SEGI reflections but not the GI on the windows ?
Maybe if reflections and GI have seperate culling layers ?

I can't wait to see SEGI become even better.

Thanks again for making such great assets.

 

Update to v1.01 Added 2 new checkboxes as requested. It is untested as I modded SEGI locally a bit. Use at your own risk.
Might add trigger collider helper version of this script so you can setup areas where recalculation will happen upon player entering trigger. (No time for that but it should be trivial to implement)

EDIT1: typos )
EDIT2: changed override from half of voxel space size to max of that value.. Sorry for that..
EDIT3: fixed null reference exception when use SEGI follow transform is checked but transform is null

Code (CSharp):

1. /*
2.     Original author: scheichs, http://forum.unity3d.com/members/scheichs.401530/
3.     Modified by: Peter Matejovsky, Vertex Soup
4.  
5.     Version: 1.02
6.     Fix: Null reference exception on update last position call.
7.  
8.     Version: 1.01
9.     Added: Use SEGI Follow Transform mode.
10.     Added: Use Half Voxel Space Size override for distance check.
11.     Note: Increased range slider for distance to 500 units.
12. */
13.  
14. using UnityEngine;
15.  
16.  
17. /// <summary>
18. /// Helper class for SEGI enabling it to update GI either after set time interval or camera move distance,
19. /// whichever is triggered first.
20. /// </summary>
21. public class SEGIHelper : MonoBehaviour
22. {
23.  
24.     [Tooltip("Enabling this option will use SEGI \"Follow Transform\" instead of this one.\nIf there is no Transform assigned on SEGI, distance check will NOT be performed at all.")]
25.     public bool useSEGIFollowTransform = true;
26.  
27.     [Tooltip("Enabling this option will set update distance to half od SEGI Voxel Space Size.\nThis oprion will ignore \"Update Distance\" value.")]
28.     public bool useHalfVoxelSpaceSize = true;
29.  
30.     [Range(0f, 10f)]
31.     [Tooltip("Regular update interval in seconds.")]
32.     public float updateInterval = 1f;
33.  
34.     [Range(0f, 500f)]
35.     [Tooltip("Update distance in meters after SEGI is triggered to recalculate GI.")]
36.     public float updateDistance = 10f;
37.  
38.     internal SEGI _segi;
39.     internal float _nextUpdate = 1f;
40.     internal bool _warmUp = true;
41.     internal Vector3 _lastPosition;
42.     internal float _updateDistanceSquared; // using cached square of distance for some performance gain
43.  
44.     void Start()
45.     {
46.         if (!_segi)
47.         {
48.             _segi = (SEGI)GameObject.FindObjectOfType(typeof(SEGI));
49.  
50.             if (!_segi)
51.             {
52.                 Debug.Log("<color=red>No SEGI in scene to use!</color>");
53.                 return;
54.             }
55.         }
56.  
57.         SetUpdateDistance(updateDistance);
58.         SetLastPosition();
59.     }
60.  
61.     void Update()
62.     {
63.         if (!_segi)
64.         {
65.             return;
66.         }
67.  
68.         CheckUpdateDistance();
69.  
70.         if (_segi.updateGI && !_warmUp)
71.         {
72.             _segi.updateGI = false;
73.         }
74.  
75.         _nextUpdate -= Time.deltaTime;
76.  
77.         if (_nextUpdate < 0)
78.         {
79.             RefreshSEGI();
80.         }
81.     }
82.  
83.     void OnDisable()
84.     {
85.         _segi.updateGI = true;
86.     }
87.  
88.     /// <summary>
89.     /// Enable to dynamicaly set update distance from other scripts.
90.     /// </summary>
91.     /// <param name="distance">Distance in world units (Meters).</param>
92.     public void SetUpdateDistance(float distance)
93.     {
94.         updateDistance = (useHalfVoxelSpaceSize) ? Mathf.Min(_segi.voxelSpaceSize * .5f, distance) : distance;
95.         _updateDistanceSquared = updateDistance * updateDistance;
96.     }
97.  
98.     /// <summary>
99.     /// Assign target SEGI from external call.
100.     /// </summary>
101.     /// <param name="target">SEGI MonoBehaviour</param>
102.     public void SetTargetSEGI(SEGI target)
103.     {
104.         _segi = target;
105.         SetLastPosition();
106.     }
107.  
108.     internal void CheckUpdateDistance()
109.     {
110.         if (useSEGIFollowTransform )
111.         {
112.             if (_segi.followTransform == null) return;
113.         }
114.  
115.         float distance;
116.         distance = Vector3.SqrMagnitude(_lastPosition - ((useSEGIFollowTransform) ? _segi.followTransform.position : _segi.transform.TransformPoint(_segi.transform.position)));
117.  
118.         if ( distance > _updateDistanceSquared)
119.         {
120.             SetLastPosition();
121.             RefreshSEGI();
122.         }
123.     }
124.  
125.     internal void SetLastPosition()
126.     {
127.         _lastPosition = (_segi.followTransform != null && useSEGIFollowTransform) ? _segi.followTransform.position : _segi.transform.TransformPoint(_segi.transform.position);
128.     }
129.  
130.     internal void RefreshSEGI()
131.     {
132.         _segi.updateGI = true;
133.         _nextUpdate = updateInterval;
134.         _warmUp = false;
135.     }
136. }
137.  

 

The problem you are seeing is because SEGI calculates the reflections based on the voxels it created, so if you exclude something from voxelization, then it won't be used for GI calculations. Reflection is "basically" an effect of bounce light/global illumination but on the specular level and not diffuse.

For that kind of environment (architectural visualisation) i suggest screen-space reflections and planar reflections. Those should work very well.

 

Not sure wtf just happened, but adding this script just boosted my framerate again...but by quite a bit.

Using my gaming laptop right now, with a 970m (this is 'mobile' not a desktop 970; I'm targeting a 980 'desktop' card as min req), I was getting around 65 fps with the old script (on Insane settings), and now I've seen it blip as high as 133 fps, no other changes beyond your script...

...nm I'm also using Scion on top of it all.

 

...hmmm okay just to make sure I wasn't crazy (and you can see the screenshot yourself!) but I restarted Unity and now I'm back to 65 fps avg. Just shows you what kind of overhead the Editor has on your playbacks, but this also means this scene is capable of greater performance in Standalone

 

Pulsating emissive textures seem not to work correctly.
the emissive parts contribute to the GI but seemingly only the "highest" value.
when the emissive part darkens the GI effect stays the same.

 

Hello everyone! I just purchased the asset, but I tested it quickly but I'll have to wait a few weeks before going back at it again.

I have just a few questions :
- Is VXGI scene dependant or not? (like ssao or bloom for example, the polycount doesn't directly changes the effect's performance).
- I quickly saw that the number of setpasscalls was about doubled when "Update GI" was active and half when disabled, will the cascading be reducing the drawcalls in this fashion as well?
- Last one, since the VXGI needs no additionnal light emission and reflection, but we can't rebake it ingame, do you think it would be possible to write something in the shader to make it overrride or ignore these ambiant lights? (This way, we could have good looking vxgi for close object and cheap unity light for the distance)?

Anyway, as I said, I tested it quickly, and I must say the results are absurdly good, especially for someone like me who is really into optimization (and especially LODs) this effect is a complete no brainer for people who want to have good/current gen graphics, and I'll finaly be able to have descent lighting in the procedural game I'm making!

 

Hi!

Well asked...

...well said.

(My reply is so utterly useless lol)

Cheers man!

-Steven

 

Showing off one of our pro-bono projects that we recently converted to use with SEGI.

Spoiler: HMS Unicorn

I made use of that script posted above to not only handle the SEGI updating but to manage our realtime reflection probes as well. On my older i5 3570 w/ 16gb and a 660GTX I can get around 90fps and that is mostly a slowdown due to the model being a crapton of poly.

 

The voxelization segment is scene dependent. It needs to render the scene once to be able to voxelize everything, so if you have a very complex scene used by SEGI, then it will need to process every geometry to create the voxels. That's why you should use as many proxy meshes as possible, and include as few objects as possible in the GI layers.

The script above and the improvements Sonic has been making should improve its performance.

Like i said before, that double drawcalls happens because SEGI does it's own render, so if you use the exact same geometry, it will basically re-render everything. Try using proxy meshes and include less objects in the GI layers.

That i don't know, Sonic will have to answer that for you.

Very true, although performance can still be too heavy if you want to target less powerful hardware.

One great thing, like i said before (in the other "new old" forum), Light probes break batching, so not having to use them with SEGI is pretty nice.

Edit:
@sonicether Can you confirm what i've been saying in this thread is correct? i don't want to be saying anything that's not correct about SEGI.

 

Good to know thanjs for the answers @eskovas!

You seem to know your topik, so I won't doubt what you said, (I'm just trying to think about a way to properly use the effect as a modeler so far).

Holy crap that's awful if it's true. I mean I knew it was breaking batching to have some lighting static baked meshes, but I didn't knew it was also the case for light probe lit meshes. If that's the case, it means they really don't want us to use enleighten! XD

Also sorry for the further question, but if you disable the layer in the effect for some objects as you said in your answer (it will still be lit by VXGI but won't contribute to the lighting), does its geommetry (the non contributing meshes) still decrease the effect's performance or is it no longer a problem?

 

I posted on the old forum how shock I was to learn that using light probes causes nothing to be batched. I spent months here trying to figure out why so many items in my scene was not being batched. Unity needs to get this info into the restrictions portion of dynamic batching.
Cause I posted on the old forum "What is the benefit of using this asset over Enlighten?" because I couldn't understand why someone would use this asset. Then @eskovas mentioned lightprobes + batching issue. So this is probably the main reason to for me use this asset now.

 

Yeah, i figured it out about 1 month ago. I was also pretty surprised. What made me test this was that i noticed that my version of Unity had a bug (still has even though they told it was fixed), when i have renderers that have light probes enabled and i set them to lightmap static and bake, it will not disable the light probes support for those renderers.
Since i never disabled the light probe support on each renderer in the beginning, because i thought because those objects that were lightmap baked wouldn't use light probes, then i never thought that there was a bug that made them still use the light probes.

From what i've found on the forum and by testing in a completely empty project, is that if objects use at least one different light probe between each other, then they won't be batched.

Since in my game i have many objects with LODs, having those LOD versions not batch is pretty bad. I tested disabling Light Probes on all my objects, and instantly got 200+ less batches on average.
Although, using SEGI is still more expensive than objects that don't batch together.

If Unity would make LOD versions of a high poly model use its information for lighting, then there wouldn't be any problem.

 

This test runs solid at 2560x1080 with a Gygabyte GTX 1080 G1.

Statig GI = 60FPS rock solid
Non Stati = 30-50-60 FPS, more 30ish.


The visuals are quite impresive. The sponza demo is breathtaking. I wish the demos that are shown in the asset store where also availalbe such as the space shaft, space corridor and the dinning room.

I guess that refreshing every 5 secs , 10, 30 secs would be similar to backing lightmaps.

 

I have noticed that my frame rate will be inconsistant when running scene in editor.. some time the scene will be 300fps..then next time i fire up scene it will be 140fps or lower... nothing changed in scene. very strange actually

 

I think dev and others will be able to help you if you provide profiler data

 

@sonicether bought this over the weekend, I think for a first release/beta, you've done a great job. The effect is pretty cool and I like what it does to the shadows.

Performance wise whilst not cheap its entirely usable in a game, I will probably end up allowing higher end users to enable it, just as they would SSR. I did notice one issue, not sure if you're aware - when SEGI is enabled particle billboards don't face the camera anymore.

Anyway here's a pic of my game with SEGI enabled runs at a steady 60fps out the box ie no optimization script etc, its still in the early stages and by the time I end up finishing it, I'm sure SEGI will be quite optimized anyhow.

looking forward to future updates

 

I posted a page back about a room I was working on, and the ceiling was actually composed of high poly geo plus a full image effects stack. I was getting steady 60FPS. Here (see attached), I have a Cornell Box, but WITHOUT the high poly geo and only SMAA. Less draw calls, same settings, but worse performance. I don't know how to account for that...

[EDIT: everything is static, only emissive materials]

 

Hey SE, I've always been impressed with your work and I am certain this will be a blast. Also, please consider focusing on large scenes since that is exactly where the current Unity's solution is weak at.

Nevertheless, I am absolutely getting this.

 

There are lots of people doing procedural content, and people who are not but want to in the back of their heads. When you have stuff with voxels (which is actually how SEGI started - Sonic Ether did this stuff in Minecraft before) a dynamic lighting system becomes very interesting.

 

I am seeing some strange behavior as I convert from ProBuilder objects to meshes... The meshes seem to "glow," even though they are using the exact same materials as the ProBuilder objects. At first I thought this was because I have overlapping UVs on my meshes, but I did a test without overlap and it still happens. Any ideas why this might be happening and how to stop it? Here are some pic examples:

 

Are the materials related to the Unity PBS materials and if so what is their smoothness value?

Additionally - i'm now using this in my game idea as de-facto. It does a beautiful job where the usual routes would be a total pain in the arse. Everything is procedural. Using simplified geometry i'm hitting acceptable VR speeds on a 970 (Oculus' lower limit). Cheers.

 

Default smoothness of 0.5, the glow doesn't stop when I set it at zero. Emissive is zero as well. In any case it doesn't happen on ProBuilder objects, so I don't think it is the material, but something to do with the way it calculates light level/bounces off the mesh.

 

It looks like SEGI reflections. Have you tried disabling the reflections on SEGI?

 

Have you tried completely different materal on the entire object just to see if that emission is still evident?

Also have you tried importing that non-ProBuilder object into a fresh scene and then importing SEGI? This would just be to rule out any 'mystery' residual data, as otherwise yes, you're simply dealing with geometry, so where is that info coming from?

 

Yes, that gets rid of it, but then a big part of what makes SEGI awesome is gone...

Yep.

I think this is just the way SEGI works. I just didn't realized it treated ProBuilder objects differently form actual meshes, since both are mesh data I'm not sure what the difference is?

I'm almost wondering if it's the fact the box is hollowed out and is getting double or maybe exponential reflection for both inside and outside of the box. It almost acts like a light source. I could test this by just making a non-hollow box mesh and seeing if it does the same thing.

 

Yeah just a solid cube mesh doesn't glow at all... It acts just like a ProBuilder object. So it has something to do with the fact that the mesh is concave/hollow.

 

I also tried putting a smaller cube inside of the hollow mesh object, and it stopped it from glowing. So it has something to do with the bounce occurring inside of a concave mesh causing some kind of exponential crazy reflection.

 

What a fun "feature" you've discovered.

 

If you want "point lights" before that feature is implemented, just make a concave mesh and use it as a light source. ;-)

 

Got a pretty good repro here:

It seems that the more concave the mesh, as well as the more of them you have, the worse the blow-out gets. I was able to dial this down a bit by playing with the occlusion settings;


Though to be fair the guide mentions this; "In the future, this parameter will be controlled per-object instead of globally to help with these problems."

That should help a lot because I like the way it looks all bright with a lot of reflections/bounces, I just don't want ONE piece to ruin all that.

 

There a problem with SEGI and Lux skin shader ( also Pre-Integerted skin shader looks same), when I use SEGI skins looks like this.
Also same problem with "HBAO" asset when I enable G-buffer.

 

Hello @ksam2

I also had the same problems with multiples material's shaders I made with shaderforge. A temporary fix for me was to turn off reflections, have you tried it? But indeed it would be cool if it was fixed, however I think there are some higher priorities for Sonic right now (mainly optimization)...

 

Hey guys, I just submitted version 0.81 to the Asset Store, not sure how long that'll take to be approved. There's now a changelog section of the SEGI Page so you can keep track of what changes for each version. If any of you guys have the time, I'd love to hear how performance improves between v0.8 and v0.81!

Also, I just ordered a Vive, so I'll be able to do VR development soon!

As far as multiple camera setups, yeah, that's definitely something that goes deeper than SEGI or SENBDL. I'd like to investigate more on this matter.

Try reducing the Secondary Bounce Gain property. That should solve your problem. I need to look into "normalizing" overlapping voxel data so bright areas don't occur with overlapping geometry. Also, it seems like perhaps you haven't disabled Unity's ambient lighting and reflections, disabling those should give you a more correct result lighting-wise. I'll look into a non-invasive way to have SEGI do this automatically by default (but obviously have it be optional).

Oh, and @eskovas, yep, your information is pretty much spot-on. Thanks for helping!

 

for just an update, should be out in a 4-5 days
Just a question Sonic... what part of the SEGI system is currently considered as the most time consuming one... Voxelization, Cone-tracing etc...