SEGI (Fully Dynamic Global Illumination)

I'm having good times with this asset. The 200m working distance is working fine with me pretty normal game with inside bits and outside bits and by not using it to transform my trash into gold and rather it make my great assets (thank you asset store) really shine I can heartily recommend people start experimenting with the technology

Also, doesn't work in single pass mode but still operates in vr too! For the large number of you working with stylised art, short view ranges or know how to create boxes and pyramids in Blender, this is neat for VR already

 

Please show imagery of it "working with a 200m distance", because at that range the voxels will be larger than a city bus and unusable.

 

Occulus made a forward+ rendering for VR and it looks as good as deferred, but it performs a lot faster.
https://developer.oculus.com/blog/introducing-the-oculus-unreal-renderer/

Forward is what is used for mobile or VR, forward allows a great performance boost. I think SEGI with forward could be awesome for many games and that still will look great and stylish or low poly graphics ones.

 

I am not sure if I agree with deferred being slower for VR than forward. Deferred and Forward has its own adventage and disadventage, but I don't think either is necessary is good or better for VR. And I don't think performance wise, different rendering path is SEGI's bottleneck for VR. I think for VR, it's a bit more to do with full screen post processing processing as it needs to render higher resolution than the usual non VR games, plus all other necessary calculation for the double camera rendering.

 

I've heard complaints about Anti-Aliasing being a necessity for VR, and hardware MSAA is only available in Forward rendering. I'm not sure I personally agree with this, as there are a number of alternative (better?!) AA variants that can be used with deferred now. But for some this is just another reason to use Forward rendering with VR.

 

Humm... Yes, I have been using the other screen space based AA , which can lead to some better results than traditional AA. Having said all that, I am actually curious as to why SEGI needs to be deferred path. Since it just "works" with standard shaders in Unity, perhaps it has got something to do with that. I think there is way to feed in the lighting information segi calculates to deferred path so that standard Unity shader can pick it up, but for forward path, Unity shader needs actual lights to calculate its lighting during pixel shader calculation so it may be why. I am just guessing.

 

For me, a very compelling use case for SEGI is as a realtime GI preview render while assembling the level without having to fuss with time consuming enlighten bakes. Just like with offline renderers, having realtime feedback during previz is essential. So for that reason, I hope that SEGI stays somewhat in sync with the lighting values of a final Enlighten bake. For me, just for previz alone, SEGI is worth the price.

 

...or for SEGI to incorporate a bake. Honestly I love the look of Cody's lighting

 

+1
I agree having SEGI to previsualize the level lightening almost real time is an outstanding time saver while Enlighten final baking will ensure the faster frame rate possible for the game.

 

I don't own SEGI (yet?) but from what I've seen, the results are quite different from what comes out of enlighten. So I'm not sure it's useful in previewing Enlighten results.

Enlighten is a lighting engine that you really have to play to its strengths to get good results (more than any other GI engine I have used), so planning your lighting using a different engine might get your scene lighting off track.

I'd rather, as @SteveB said, wait for SEGI to incorporate some sort of baking.

 

Global GI remains GI, for previsualisation only SEGI will do the job as you'll have a preview of where are the shadows and what lights or materials reflects on surfaces.

 

I doubt SEGI will sync with Enlighten. But I do also like the baking option. What I mean by baking , is that the baking process is done in game - in realtime. So segi can utilize Unity's lightmap uv or come up with its own data storage system to store static lighting values and actually generate them in realtime. IE during level loading. And then, only do realtime moving object voxel calculation on top of baked one to speed up the performance. I think crossing SEGI with Enlighten any further is just going to complicate things. SEGI is meant to be realtime GI so its development should stay with in-game realtime stuff.

It just beats me why Unity has introduced Enlighten but not allow realtime baking , the same goes to the occlusion culling.
It is just a semi - usable functionality. When I use occlusion baking in Editor , it only takes split seconds most of the time which I think is perfectly valid for in-game usage especially, when you notify user that there is world generation going on.

 

Super fast Lightmaping have already been discussed as an option for SEGI.
Also some future improvments could happen, like why not Voxelization of the scene or any fast precomputing that would result in faster GI rendering.
This is like Enlighten that does real time GI , it need the very long baking phase but once it is done realt ime GI is incredibly fast.

 

There is an asset called Pre-Integrated skin shader on the asset store that is one of best skin shader for unity, but it doesn't work with SEGI! I think it's because SEGI doesn't support forward. and this shader using G-buffer.

 

If a particular shader asset doesn't support deferred rendering path, I think we have to be fair to SEGI about it too. I mean, why does that particular shader asset doesn't support deferred path? I know there may be more forward rendering path users than deferred path, but as far as the tech goes, I think they are both valid and should get equal credit chance of being supported. So there should be the same question asked to that particular shader asset why it isn't supporting deferred path. I am not saying SEGI not supporting forward is great thing. It's definitely a short fall. But it should go the same way for the other assets which doesn't support the deferred path.

 

While I agree with you on this topic, I think the main reason a lot of us want the Forward support is mainly for the sky Illumination. Maybe I'm wrong, but I think skies are 100% forward rendering, as they don't use depth buffer at all.

 

I think some shaders like skin should be on the forward to work correctly.

 

For the life of me I cannot understand why you people (the ones who are doing it) are continually petitioning for support of things that are both borderline impossible and so utterly niche as to be considered a complete waste of time when there are serious fundamental issues that need the attention way more than "working on forward rendering". He pointed out that it can't work with forward from the beginning. Stop wasting our time asking for it. He said it wasn't aimed at mobile. Stop wasting our time asking for it. Are you even aware, or do you just not care that there are already issues preventing it from being used on the actual implementations that it's designed to? Have you ever tried putting an actual modern building in the zone and watched as every crevass bleeds like an open vein of light? Have you tried using any terrain with trees and grass? Are you aware of the scene size limitations? Debating about nonsense that the asset wasn't designed to work with from the beginning is driving movement in the opposite direction and you need to give it a rest.

 

Here is a crazy thought, have you considered making this or as part of an additional lightmap baker tool to offer the option to bake this GI into the model itself especially for areas which are static?

This looks absolutely phenomenal, the most important goal is FPS but wow....this almost wants me to go to Unity 5 but it's GI is a rude finger to all Unity users.

While this asset may have it's limitations a little bit of imagination could go along way until it is ready.

 

I don't understand why you don't just use Enlighten, you'll got real time GI once you have successfully baked your scene.
Forward rendering is usefull for keeping performance good on specific shaders like vegetation transluency for example.

This is an option that have been discussed and that should appear later, using SEGI to bake lightmaps at full speed.

 

Dear sonicether i need your help！SEGI is amazing! I run the sample Project in unity3d v5.2 editor but I lose my shadows when i turn on GI. So I test with unity3d v5.4 on orther pc , shadows also disappear. I dowload and run SEGI-Beta-v0.8-Low-Poly-Demo its ok . So why shadows disappear .

 

orther TEST

 

It seems you have enlighten on as well? Maybe turn that off first.

 

IS THER STH WRONG ?

 

THKS JUST FOR compare
SEGI sample Project shadows disappear also. i change nothing

 

Could you be running out of graphic card memory when you enable SEGI? Unity will remove shadows then.

Lennart

 

I had the exact same problem when I started using SEGI, and it was indeed due to a Vram problem. One of the post process I was using, when combined with SEGI, would use endlesselly more vram untill the shadows where removed, and then unity crashed. So check you Vram @my5800mkk!

 

I agree with this. I think we need to give room to dev to focus develop segi for what it is meant to do. Everything else can come after that. Making it to work on forward path isn't the priority. Making it work well (quality) and fast (performance) is important. The things I was asking are all related to the performance side of thing, such as optimizing for VR, or flexible voxel volume for performance boost at higher quality.

 

thanks I dowload and run SEGI-Beta-v0.8-Low-Poly-Demo everything is ok ,i think my video card is ok. maybe something other went wrong

 

How much ram do you have on your video card?

Lennart

 

Heya SEGI's working really well with exterior environments or giant cube worlds, it's truly beautiful. However I'm trying to use it with realistically sized buildings and the light leaking though the walls is preventing good results.

Thin wall: loads of leakage


Very thick wall: realistic results


I can't make the walls of the building 10m thick (especially not the internal ones) so...

1) Are there any currently available approaches that will help here?
2) Will the fixes to light leaking planned in the road map address this or is this likely to always be a problem?
3)If they will help, what kind of time scale are we looking at to delivery of that feature: 1 month/6 months/1 year etc? ie where is it's priority in the list of things to do?

Many thanks for any help

 

At the moment you can only use GI blockers (geom that's not visible). I haven't used them yet. For indoor scenes you could change the size of the the voxelization box at runtime (trigger when entering indoor region)

 

You have to read the SEGI dev website to understand why "leak" happens first. Once you have understood that, then it comes down to :

1. Either reduce the size of the voxel volume to increase density of the voxels.
2. Increase number of voxels to force higher density.
3. Use GI blocker
4. Thinker wall.

When dev comes up with more ways to make cascaded voxel volume, it may help also.

 

If you'd used them you'd realize that this doesn't work.

1. There is no amount of resizing of the voxel range that will make realistically sized walls not leak light. Even with a pathetically short range of just 20m the voxels are still larger than 20cm and thus will produce this same effect reliably.
2. There is no amount of voxel density that will eliminate this either, because of the same issue.
3. GI Blockers will not fix the issue because, again, the problem is the system is based on the voxel size and cannot comprehend any unit of measurement smaller than that of a voxel. If your wall isn't at least 1m thick, it doesn't exist, so unless you're making your GI blockers 1m thick and shadowing the entire wall, no dice. Additionally another problem with GI blockers is that you pretty much have to enclose the entire thing you're wanting to block, which for a scene like his, means blockers for the walls, floor, ceiling, even the exterior of the building. For every building and every object.
   
4. Cascaded volumes will not make a difference either. Because, again, the problem is the minimum size of the voxels and the fact the whole thing is based on that core.

Trust me when I say that I really truly am sorry to say it, but this just isn't going to work for anything but games made of large blocky primitives.

 

You're jumping to conclusions. It's early beta. Cascaded voxelisation might allow of smaller voxels. Smarter placement of the voxels might help.

 

No, not really. I'm forming opinions based on tangible evidence and more than a month of experience working with the thing in question. What you're doing is wishful thinking and that advances nothing.

1. As already stated, light leaking is a direct result of the minimum obtainable voxel size being much greater than the thickness of common objects, such as doors, windows, floors, and walls.
   
2. As already stated, voxel cascading has nothing to do with the core constraint of the minimum obtainable size of voxels in this system.
3. This is the fundamental method in which SEGI functions and there's no way he's going to re-write SEGI from scratch, so the "it's beta" argument is invalidated. SEGI will improve in bother rendering performance and usability, but its core system is now what it will almost certainly always be; Take it or leave it.

Conclusion: SEGI both works and looks amazingly well on objects more than 1sqm in volume. The core system it's designed around however prohibits it from functioning properly on anything smaller than that, which unless you're making a minecraft/polyworld style game, represents the vast majority of games today.

Refute the images people are putting up that support this conclusion if you like, but only if you can provide your own visuals to back up "the right way to make it work" as you inferred.

 

The current product is not production ready and no one ever said it was and the light leaking problem was mentioned in the first post of this very thread.

The light leak problem is a problem with a lot of voxel based solutions. But others have solved it, with a variety of ways. Why are you proposing that solving it in SEGI is impossible?

I mean even on the first post Sonicether mentions this:

 

SEGI is Beta, so this is a work in progress , it was never been marked ready to use in game when it was available on Asset store. It will get better and it will get more features, more optimisation.
You should use CryEngine for your game if your concern is vast outdoors and real time GI and you can't wait for SEGI future updates instead of saying it is limited to Minecraft games that is non sense.

 

Okay, I will time travel into the future, at a time where SEGI has fixed the light leak issue and bring you pictures.

(No one is saying that SEGI does not light leak right now, no one is refuting that, so how can there be pictures?)

 

Because from what I keep hearing from your corner, "people" are solving it apparently. Perhaps because they're being "smarter about placing their voxels" as you said. So if you think the people who are having bad results are doing it wrong, could you show us a better "smarter" way of "doing it right", rather than making 10m thick walls?

 

Smarter placement of voxels by SEGI.

And others -> other voxel based GI solutions.

 

Ah, ok then. It seemed that you were saying "the problem is you aren't being smart enough about how you set up SEGI" I've spent weeks upon weeks with my head in the guts of this thing and would love nothing more in the world than to be wrong because I want SEGI in my games, both the ones i've already launched and the new one in development; It's just not possible until the light leaking and range are fixed, not to mention the "self bleed" issue of walls multiplying their light back and forth more times than should be possible. That requires normalization.

 

Thank you all very much for your replies, I have indeed read the documentation and tried GI blockers. Thanks Divergence for outlining the problems presented by the specific case of realistically dimensioned houses. Is there a simple way to experiment with higher voxel resolutions? It's possible that we could set our range to about 20m and have slightly thicker than normal interior walls, but the only resolution settings are low and high, I've tried upping the values for these in the code but I crash out Unity.

 

You can lower "Voxel Space Size" and "Shadow Space Size" to increase voxel density in indoor scenes

 

They're not better AA for VR in the sense that most post-processing AA is not dealing with every possible form of temporal aliasing due to missing samples. MSAA guarantees that edge cases are dealt with, SSAA guarantees that everything is dealt with. SMAA, CSAA, FXAA and even Temporal AA don't solve the cases that can cause nausea. They also don't fix the cases where someone with average vision might be satisfied in a 24-27' monitor, like material or texture aliasing, because when you're staring at the VR lens your brain won't be fooled and will notice the missing samples and the current flaws of our Temporal AA technology.

Since SSAA is heavy it's better to design the game around having as little material aliasing as possible (as neither MSAA nor any other AA will actually deal with it well in VR) and sticking to MSAA to ensure that you'll be eliminating as many cases of nausea as possible.

 

Thanks scheichs, I've already done that to the lowest I can to encompass a room. I want to experiment with higher values for the Voxel Resolution setting which are clamped at low (128) and high (256)?

 

if you did change the voxel resolution to 512 the memory used would be 2x2x2 times more. almost 4 GB just for the voxel data...

 

Ahh okay thanks LennartJohansen

 

Sort of tedious to see pages of bickering about the performance expectations for SEGI. I assumed that anyone who bought this asset knew what they were getting into and more or less agreed with what @elbows posted a couple months ago (^). Roadmap or not, SEGI really isn't a competitor for Enlighten.