SEGI (Fully Dynamic Global Illumination)

SEGI 2 ? lol

 

That's exclusively for Minecraft, I think?

 

Yeah, SEUS is a shader pack for Minecraft (see).

 

Can you tell us what company you sold it to? Are their plans to sell it as an asset or use exclusively in their product?

 

At the moment they plan to use it exclusively in several of their games. I can't give you more details, sorry.

 

Ok may not be totally realtime but looks brutally fast. I asume there is no precompute.

 

There is precompute as in every standard lightmapper but is really fast. And note that here are only 4 lightmaps which means that not that much texels are calculated !

But yeah i guess would be much nicer to use the GPU lightmapper if you have a good enough GPU of course !

 

Awesome tx for the info I was finding none. Sadly I dont see it in the 2018.2 features list so will have to wait. I've a 1080 waiting for some computing abuse. Cant wait.

 

The new GPU lightmapper still can't be used at runtime though, right?

 

No, its purpose if you allow you to faster bake your lightmaps !

 

I get it. Just that this thread and others about realtime GI have been about procedural, runtime scene geometry (even scenes that are mostly static after initial generation as part of the scene load). So even if the new lightmapper is super fast, it doesn't address the need here.

 

Plus it is editor only feature - at least i haven't seen information about runtime support ( i guess it would not be possible )

 

Will this going to get implemented in Unity 2018 ?

 

Well, if you manage to get it working in 2018.X somehow, feel free to share (or be a d*ck like nxrighthere)

I think it's safe to say that this is dead (for now). Sonic gave up on it completely and no one contributes to it. One of the drawbacks of going open source, but we all were aware of that potential risk.

 

Sky Master Ultimate released on Tuesday an update with a beta "optimized SEGI" version. I wonder what's been changed. Anyone with that asset want to take a look?

https://assetstore.unity.com/packages/tools/particles-effects/sky-master-ultimate-25357

 

I think Nasos did improve the performance a good amount. He provided some comparison screenshots in his asset's thread a few weeks ago.

 

How semi-realtime voxel-based GI was made in recent Unigine 2.7 update:

This GI solution feels well balanced for practical use with millions polygons in the frame.

 

it's basically baked SEGI (no recompute of the voxel lighting while moving) supported by cubemap and ssr to cover limitations

 

Yeah, but this is very smart implementation - voxel volumes can be placed inside each other, voxels that are not connected to any surface can be removed, etc, etc. Sum of those tricks makes it work in the end, at least at first glance.

 

But it has the old problem: Not suitable for procedural levels.

 

I hate the whole baking stuff, because moving a camera through a

- static model that has been
- baked for hours

is simply not "realtime" to me....

Hopefully a true realtime-gi solution similar to segi will come one day.

 

Baked is the only way to have real time juice and the amazing visual.

SEGI gave us near real time with some limitation, I don't understand anything in teh code, if only someone could do a walkthrough for baby and heavy commented the code, more people like me who don't have enough time would jump on it.

 

Am I correct in understanding that SEGI doesn't have cascades and won't any time soon? Is there a workaround for hybrid indoor/outdoor scenes, for example use SEGI for indoor only? That should make the voxel size workable.

 

I think cascade were implemented just before abandonment.

 

So I spoke to the Sky Master Ultimate developer on Reddit. This is what he had to say on his SEGI branch:

"I have done some extra optimizations in the SEGI main script and will be working more on optimizing further the system and integration with the upcoming customized soft shadows system and other parts of the sky system. This will be ongoing WIP for some time, though the current optimization even though simple can increase the performance a lot."

I also followed up and asked him if he was working on some of the weak points of SEGI like limited draw distance and light leakage. He said:

"The SEGI will be an ongoing process of improving upon any point possible, so sure i will check all possibilities in future versions. Currently i have also done the optimization in the cascade version and seems to also work great, so this will be another option in the next update."

 

Does anyone know how SEGI works?

1. I'm not clear on how it gets the voxels... does it take the meshes at render time and voxelize? Does that mean that it is only aware of geometry within the frustrum that isn't occluded? What if you have a bright blue wall behind you?
2. I've seen samples with ground reflections. I gather this is based on the voxel data. Is there a way to turn this off if you want to use SSRR or some other reflection solution?
3. If we can figure out how the reflections work (and depending on the answer to question 1) could it be combined with SSRR to fill in the gaps in SSRR with lower quality voxel reflections? Combining SEGI with kode80's SSRR might be fun.

 

as I remember (according to my knowledge):
1. SEGI voxelize entire scene that is inside specified region regardless of camera frustum
2. " I gather this is based on the voxel data"
yes,you are right.you can disable reflection at the lowest part of the SEGI Component parameters.

3. Test it yourself and share the result with us here

 

I've done some preliminary investigation. The trick will be getting the various phases in the right order. Currently the SSRR doesn't pick up the GI lighting. We also don't want SSRR affecting GI or GI reflections being reflected again by SSRR. As little as I want a deep integration I'm considering copying SEGI's reflection code into the SSRR, solving the chicken and egg problem.

 

By the way I'm experiencing a weird effect with my SSRR test scene. SEGI seems to be failing to converge with Stochastic Sampling on. That shifting static look. I haven't experienced that with any other scene that I've put SEGI in. Any thoughts? Some wrong setting? Could another shader be flushing the buffer that SEGI uses? It happens even when I turn off "Update GI".

 

Meanwhile OTOY has releases free GPU lightmapping for Unity. Welcome for the discussion.
https://forum.unity.com/threads/octane-gpu-lightmapping.536029

 

I've already asked this question before, but can SEGI run on Nintendo Switch ? SEGI is DirectX 11from what I understand and the Switch is compatible with Vulkan, Open GL 4.5 and ES.

I'm still searching for the best lighting system for my game with some procedural levels and I have 3 options :
- Basic out of the box components from Unity (Lights w/ cookies, Ambient Color, Intensity Multiplier) : Convenient but devoided of flexibility and realism.
- Lightmapping : The most realistic option but exhausting considering the amount of assets I have to make (several thousands). Plus, dynamic objects are not affected by lightmaps, unless reflection Probes are used.
- Realtime GI : Like SEGI which I don't really know about in terms of performances, but looks like a potential solution if it can work on average configurations + Lights if really needed.

So I would like to know in depth how SEGI affects performance on the Lowest setting (I see no difference between Low and High settings). Is it really a performance killer ? Otherwise I think it would be a great option for a "background" lighting system in interior levels, or scenes that may not exceed 200.000k Tris for example.

Here's an example of an interior scene with SEGI in Low and Cones + Cones lenght at 8. I also use a x2 Anti Aliasing (MadGoat SSAA) and some Screen Space Reflections. The scene is far to be optimised (200.000k Tris) because there is distant geometry beyond the room I show - also Unity seem to uselessly multiply the polycount for some reason, I have to figure out that issue later on (Unity Chan takes 100.000 Tris... what ???)

Edit : Acccording to the Profiler, it looks like SEGI takes 4ms on this scene.

 

You can use proxy mesh to feed segi, which mean you can either procedurally generate them or if you use module assembly, have them ready when you spawn the module.

Unity lighting use multipass, which mean the same triangle get rendered multiple time for each pass, which increase the counter. If you use a shader with no lighting pass and the triangle count decrease.

However segi is expensive, I got 11fps on the procedural demo with a machine roughly equivalent of the wii U in early released.

Just make a test scene and import it to switch, you have no choice

 

I think the demo level SEGI setting is set to High but with Half-resolution active. I use Low with a wide Voxel box (1000) and Cones set at 8. I want to use Realtime GI just for general illumination, so it's okay if the light is not so accurate.

Do you have the 11 FPS in the Editor or in Standalone ? Editor takes half of your system ressources, if not much more. I just figured this out yesterday.

I dont understand your first paragraph with Proxy meshes and module assembly. Is it different than putting SEGI on a camera ?

About the Switch, i don't think it's comparable to the Wii U. I read here and there it's closer to a stock Xbox One. The problem is, I would have to get a Dev kit from Nintendo to test everything at some point, or a new PC with a similar configuration (Tegra X1, 8 cores at 1Ghz CPU, 4Go RAM).

Here's a Split-screen test with 4 Players / Cameras. It takes about 25% of power in total (less than 10 with one Camera). By the way, you can see SEGI causes a weird reflection on meshes when the camera gets close to anything. Why is that ?

 

as developer for switch and wii u SEGI doesn't run with them , i can't even compile

 

So, should it be because SEGI is DirectX 11 compatible only ?

Mh... So I would have to take a look at Hxgi instead, unless there's another way around for SEGI in Vulkan or Open GL.

I see some people already achieved Realtime GI on Open GL - this thread looks interesting :

https://www.reddit.com/r/GraphicsProgramming/comments/5hdbg8/i_made_a_realtime_global_illumination/

In Unity, I'll switch to Vulkan API so that I can see what can work on Switch.

 

This is neither realtime GI, nor an Enlighten alternative. And OctaneRenderer for Unity (2017) got released months ago - old news.

Even if it compiles, I wouldn't expect a good performance.

 

Godot 3 runs very well with cone tracing on such scenes on global illumination low setting instead of max settings.
Unfortunately it's baked voxels while it looks great, and Godot 3 is not an approved 3D engine for consoles.

Your scene is mainly static lighting and some emissive materials , why not staying with Enlighten lightmaps when level lights are not dynamic?

 

I have to say I've never used Enligthen or tried anything with the Global Illumination techniques offered with Unity. I'm just concerned it would not work on procedural levels.

I just attempted to make a Vulkan API Build, but it Crashes at launch and I get this error :

amdvlk64.dll caused an Access Violation (0xc0000005)
in module amdvlk64.dll at 0033:d4d6a1a1.

Tested with DirectX 11 : It runs like butter on a frying pan (200 Mo of RAM used in my scene).

 

proxy mesh are mesh that are rendered to segi instead of your game mesh, by being lower rez and low poly it can save a few cycle, they just have to match roughly the material environment for the light you want, which mean they don't have to match the actual environment and can be totally different if this what you wishes for effect.

BTW global illumination is basically a occlusion/visibility problem, that is which pixel see which other, which is exactly what enlighten do, they create surfaces (which are basically big pixel collection with a min size of 4²) and store inside each surfaces what other surfaces it see, to what amount, then cull the list by order of contribution by a defined amount size (like the 10 most contributors). For rendering, it process the global average color of a surface, then compute direct light percent falling on all surfaces, then use the list of contributor to query that light and color information to add to its surface before rendering to actual mesh. Because the visibility occlusion is baked, it's rather fast, as it is a low resolution query of a few data.

SEGI does the same at the voxel level instead of the surface and each frame instead of baking time, which is expensive.

Depending on the structure of your pcg generation maybe you can take advantage that you control it to create visibility/occlusion to create your own solution?

 

SEGI will never work well on switch, just forget that, even if it did work, there aren't any optimisations you can do to save it.

 

I have no idea what I am doing but I try to convert this code for Unity :

https://github.com/Friduric/voxel-cone-tracing/tree/master/Shaders/Voxel Cone Tracing

It's the first time I take a look at something related to rendering in Unity. At least it gets me interested to how things work a little by comparing to SEGI's code.

Obviously this code doesn't have Unity's Directional Light and Emissive Materials, and shadows should not work in Unity.

Anyway, I certainly can't achieve what other guys just try to achieve since many years, unless I become... intelligent.

 

What is your real problem? achieving a GI look that's static? if so (while being procedural) then there are better ways to skin this cat!

 

I think what I like about Voxels Realtime GI is that all meshes are directly affected, the result is good enough in Low settings and it takes no memory space.

Considering the amount of rooms I have to make, Lightmaps would take a lot of space I think, unless I make them very low-res just to achieve what I did with SEGI.

I would consider using a Lightprobes generator it I happen to switch to Lightmaps. Does this look like a good solution ? https://assetstore.unity.com/packages/tools/level-design/lightprobe-generator-96395

 

It's a terrible "solution" that has nothing to do with your problem. That is just adding probes - something anyone can do with a couple of clicks. It also won't affect static geometry, and won't really work like you think it might.

• Do you need to generate levels at runtime? If not then enlighten (with realtime gi, not baked) is likely all you'll ever need and has no baking time to speak of
• Do you change lighting once the game is running?
• How many dynamic objects are there and what are they?

 

- I have an asset called Q Maze for generating levels. I just need to generate levels when a scene is loaded.
- I don't need to change lighting.
- Players + Any small / medium sized items.

 

I think that many games could benefit from GI just a tiny bit more dynamic than Enlighten allows. Most people aren't making Minecraft, they just want to create/alter the level layout at level load time, or perhaps they have a handful of meshes that need to move (e.g. doors than open and close). I wonder whether one of these solutions could be modified to provide lazy runtime baking.

 

I might be wrong, but it looks like SEGI is less consuming than Post Processing Stack's SSR. I have MadGoat SSAA (x2 and x4 Anti-Aliasing), and it runs hardly with SSR On (+ SEGI). With SEGI alone, it runs very fluently. Unless it's a compatibility issue, how can SSR be more demanding than SEGI ?

I figured out the issue with weird reflections : Temporal Blend Weight have to be set to 1.

Also, can you explain me how SEGI can work with Cones set to only 1 ?

 

What do you think about this little technique for filling rooms with light when your main material doesn't reach the whole scene ?

 

It looks strange, not as good as global illumination.
But it's a good trick, does it run faster than global illumination ?

 

Uh, well, it's SEGI...

I mean, I don't know how to use GI with Enlighten or progressive lightmapper, so I can't say. But here, SEGI goes from 1ms to 4ms max. It looks slow when I Play because I forgot to disable x4 AA and Editor Overhead is expensive.

It looks strange because the Voxels are very large due to the wide 1000 distance which cancels Cones efficiency, I guess, and you can see them when I tweak SEGI's Occlusion parameters.

Still, I think it's nice and the lighting looks natural enough. Now I wish we had some (cheaper / optimized) Vulkan / Open GL Voxel RGI for Unity.