SEGI (Fully Dynamic Global Illumination)

What is this cascade gi you are talking about?

 

https://gdcvault.com/play/1026469/Scalable-Real-Time-Global-Illumination
in case anyone interested

 

Probably meant SEGI (Cascaded):

Image Effects/Sonic Ether/SEGI (Cascaded)

.

 

I have decided to throw caution to the wind. I'm going to try to use segi to cobble together a very simple and short. space ship based fps.

This should be interesting.

 

So... constructive criticism. I'm not sure how appropriate a space ship scenario is for SEGI. If you're in space, there's nothing for GI to bounce off. If you're in a confined space, I'd imagine you're travelling so fast you'd outrun your GI. I may be wrong, just don't want to see anyone use their time poorly.

 

Regardless of whether SEGI is appropriate for his spaceship game - they're some poor assumptions, and your first comment isn't really true.

The spaceship interior will bounce light. The intensity of bright star light through a window will display some very attractive bounce lighting around any incident surfaces. I would say this is one of the best ways to demonstrate the effect of GI. Spaceship corridors in games are also often dark / lit by few sources (particularly in thriller / horror games), so any bounce lighting is particularly pronounced. The team behind Alien Isolation developed their own GI solution designed specifically for this purpose:

If you're firing laser blasters down a low-lit spaceship corridor, you'd get some amazing benefits from a local GI solution.

It isn't uncommon for space games to simulate the ship as a static object / the "local world", and manipulate other things around that, in which case you can configure the GI volume around the ship and you won't "outrun" the GI. Either way- if you don't use some kind of local-space workaround here, you'd be more likely to run into bounds / volume issues as you move through the vast expanse of space.

Anyway, that's just to say, GI could be incredibly appopriate for a spaceship game.

 

I may have misread his post, I was imagining someone piloting a small ship, not wandering around in a large ship. Based on that I envisioned just seeing space and a small portion of the cockpit you're sitting in. I'm not going to dispute the other points because they all flow on from that.

 

IF it's a small cockpit, a single low rez reflection cubemap, retroprojected, and updated in real time, might do the trick good enough.

Even zelda BOTW basically just do a single cubemap, updated in real time, just above the player character, and that's an entire open world game!

 

Maybe it's too much to cover, but I am running a skin shader that is deferred but using forward cameras for depth. At least i think that's how that works. Anyway, how can i make it this shader works with SEGI? Reflections work but otherwise GI and emission have no effect on these objects.

 

How to do this in Unity ?

 

Depend on what receive the light, and if deferred or forward.
I don't know how to do it simply in unity, it's probably possible, but I tend to rewrite everything from scratch, I know someone (@flogel ) did it with unity (the same one who made a thread about BOTW terrain blending).
https://twitter.com/flogelz/status/1175053137712955392
https://twitter.com/flogelz/status/1175403260749996033
https://twitter.com/flogelz/status/1175456638062473218

 

It would be a game where you are in a spaceship trying to fight your way from one end to the other

 

Does anyone know, how I can change the quality of the reflection's rendertexture in Segi ? I took the last version on github. I saw that changing the voxel resolution change it, but I have mirror and the resolution is not really good enough. I was looking for the script's part that handle that, but I never really worked with render texture and couldn't find the answer :/

 

This is, unfortunately, a limitation of traditional path tracing.

 

Arff too bad :/
Thx for your fast answer Ninlilizi

 

When I added SEGI(Script) to my camera, I couldn't check the box, so it didn't work. Any solutions?

 

If you're on my fork. Then add it as a posteffect2 effect, not by dropping on the camera... Though it's pretty ugly and I moved to my own GI that has now become this because of a total rewrite being necessitated.

If your running SE's original code. Then you'll have to supply the error information in the console so we can advise.

 

I'm not sure if the "RenderTextures" errors are from SEGI.

 

I don't recognise those texture formats. What platform are you running on?

 

I didnt see your own GI till now! I have a few questions!

-Can be used in a comercial project? If I get profit I will make sure to donate, A dynamic GI solution is one of the things we need the most

-Does it require light probes or is it completely "free" like SEGI?

-How is light leaking/bouncing? We don't need some super fancy looking light system: Just be able to bounce light from sources so shadows arent completely black, and be able to isolate rooms so give the necesary conditions we can have pitch dark zones (for example a room with a shut door and lights off)

-Does it handle reflections? We have probes + SSR but would be nice to get rid of the probes too

-Is the update controllable? We don't need for it to update every frame or something, Just every few seconds for time of day/weather, when some door opens or light gets toggled or if we have any scenery that dynamically transforms or in which big elements move sometimes.

-How much distance does it support? We had major problems with SEGI, cascaded version didn't work at all and we had to choose between huge leaks or reasonable distance

-Which lights does it support? Can you for example get good interior lighting just trough emissive materials if dynamic shadows arent needed on moving objects instead of having to set up "real" unity lights?

Thanks a lot. I ask these questions because we have to finish first some other things and can't get to try this GI solution yet.

 

Unity 2018.3.11f1 Personal - [PREVIEW PACKAGES IN USE] - GameScene.unity - (Project name here) - PC, Mac & Linux Standalone (Personal) <OpenGL 4.1>

I am also working on a Mac.

 

Sorry. If it's a mac I really don't know where to even begin.
I don't have access to such exotic devices and have never known anyone else who does either.

Though, I notice the <OpenGL 4.1> ... So, I guess the thing that is missing is OpenGL compatibility. That SEGI fork is DirectX only. Nigiri is also DirectX only at this point. If you really need OpenGL compatibility adding to anything. Then we'd need to collaborate more closely than a forum provides and figure out some arrangement for that use of my time.

 

The short answer. If your willing to donate. Your welcome to request any exact features you desire. If I'm going to budget time anywhere, the place that allows me to eat or pay bills is going to be preferential.

The more detailed answers:
* No light-probes. It's 'free' in the same way SEGI provides vis emissions.
* Leaking is much less of a problem than SEGI when properly configured. But it's not perfect.
* Reflections. Not yet, though the regularity I'm asked for reflections, it won't ever be forgotten.
* Updates, will be controllable, with quite some granularity, including support for masking. So won't waist cycles on stuff hidden by HUDs or whatever. Though, the resolve time for major scene changes I aim to keep under 1/4 second. But work is spread across frames and it's designed to keep the data building as controllable as possible to avoid frame pacing issues.
* Distance, support for huge outdoor scenes is important to me. I need that in my own project. The design will always keep that in mind.
* Lights, pretty much limited to emissions at this point. Shadow masking is lifted from main directional lights generated shadow map. The reason for this choice was to avoid multiplication of draw-calls by having to perform an additional scene render to generate our own.

A lot of the design choices had one key principle in mind. Work with what we already have to absolutely minimise the need for additional scene renders. It's a major reason this is usable in VR and some people have had it specific builds running on even intel integrated graphics. SEGI performs I think it's +3 complete scene renders per frame to get what it needs, it's a major source of its weight.

I don't have a production-ready build yet. The repo is a checkpoint before moving onto the next stage of development. The goal is to have a usable in an actual project release by this summer. When that comes, I'll stop with the covert nerdiness and throw open a thread of its own to officially announce it to the world.

tl;dr I didn't abandon GI. Just evolved and shooting for something worth actually showing off before I waste anyone of anyone time.

 

Thanks for such a detailed reply!

 

Thank you very much!

 

Hello !
Does any of you already had a bug with a custom shader (deferred of course). The bug is that the mesh doesn't get calculated in the voxel GI (I can see it in the voxel gi debug view) a standard shader, at least shows me the color of the mesh in the calculation of the voxel but when I just plugged a new shader, similar to a standard (with ASE) it doesn't get calculated and I have many flickering due to that :/

If anyone had a similar case I'm all ears. Knowing that even a simple dithering shader made with ASE works fine, but if I change some name in the shader I obtain the same problem...

 

Yah that happens to me too when I made a custom shader and idk why either... in fact it doesn't like any kind of gi, voxel or ssgi.

 

I find the answer on page 39 @florianalexandru05
It's due to the name of our variable in the shader. Segi does a shader replacement and for the emissive and albedo. So we have to name it like unity so for my albedo I had to name it : _MainTex

 

Awesome, thanks for figuring that out!! It helps alot.

Anyway, still trying out different mixed real time lighting techniques. First is default Unity viewport, second SEGI and third SSRT. What one looks better? It's pretty hard to get something close to production quality as they have their weaknesses. I might try Unity's pre-computed and SSRT on top, I noticed it fixes the lighting and adds nice contact shadows. SEGI produces too blocky shadows!

 

That's how you are supposed to do, mix the various technique, of course segi will produce blacky shadows, it's using chunky voxel! That's how you get real time, ruthlessly approximating. Even actual hardware ray tracing will need some hacks.

 

I think I'm on to something with pre-computed and SSRT gives me pretty good contact shadows and GI. I made a path trace render test and it's pretty close to this kinda. I would rather have this instead of the Box shadows now. Voxels don't work very well in nature, if you want to get accurate shadows out of it but SEGI would be best in interiors instead.

 

Think more in term of image frequency, voxel are the low frequency, you need other technique to capture the high frequency.

 

Does anyone know how to get SEGI compatible with transparent materials, if possible?

I'm trying to create a depth mask right now for fake holes, and the only way to get the depth mask to work in deferred rendering is to put it on Geometry+502, which I believe is the transparency buffer. (Edit: I misspoke. It seems this is the AlphaClip buffer, according to Unity.)

SEGI lights are not lighting these objects, which is a bit of a problem. Also, any form of glass in the game does not light with SEGI either, due to its transparent nature.

I would just switch over to forward so I could use to stencil buffer properly without needing to transition the whole thing to Geometry+502, but deferred is needed so that SEGI will even work in the first place.

Been trying to solve this issue for months now, any help would be appreciated.

 

Does anyone have any recommendations for a supported and updated SEGI type system? Paid or free is fine.

 

Mine (Which has been in progress since SEGI), will be complete enough to show the world later this summer. GI is coming, and it's going to be in a class of it's own.

 

Hey! I found that through seeing your SEGI fork and going to you. Sounds great! Now sure if I can wait that long since we're looking to move now, but I'll certainly be following along

 

Actually... That is 2-year-old experimental code in that repo... It's really bad code. The current project is a completely new animal, based on progressive, sparse octrees, with reflections, shadows, actually real-time and physically accurate tracing. And written to professional coding standards. Anyway. Hang-tight. We're starting to get close to the end of a very long development tunnel. It'll be worth the wait.

 

Sweet! Looking forward to seeing it @Ninlilizi

If you post it outside of this thread please post a link here.

 

Raytracing or non raytracing?

 

raytracing.

 

Non hardware accelerated (probably later?)

 

Non-RTX . All (GPU) Computes. Thought I am playing with OptiX, somewhat experimentally. Managed to get it to fire up and talk to Unity, just need to solve a framebuffer format related weirdness before it'll do anything useful.

 

Sounds really cool! Will this be a good system for interiors, or more exterior focused? My game is set mostly indoors (for now)

 

Very curious now. Did not expect raytracing. Raytracing is definitely the future but have not seen any practical, performant method of it yet. Figured voxel tech like SEGI since that is going to be pretty common, even supposed to be used in Lumen for UE5.

 

That is VERY good news. Could you share a small preview? Any picture?

 

@Baldinoboy
SEGI is still raytracing through raymarching, with voxel approximation of the geometry, ie it send rays that hit the geometry.

Most technique are either a way to approximate the geometry (hierarchical query structure, spatial hashing, voxel representation, lightfield representation, proxy geometry, cubemap or lightmap, etc...) or have a better way to send rays (send them by cones, tracing structure, probability based sampling, signed distance function, denoising, etc ...).

Most modern technique do accumulation over frame to get pseudo infinite bounce.

Most techniques can also be combined together. I think Nigiri (if it hasn't changed) is still a (sparse) voxel based method (geometry approximation), but with ray accelerated by octree.

 

This sounds better and better at every bit of info I read about it!. Will it be able to be made "lighweight"? Like, our main need for our project is to be able to have interiors not be totally dark if there is daylight outside and no artificial interior lights on, let light pass trough open doors and have off-screen element reflrections without need of reflection probes. Not needed to update everyframe just every 5-10 seconds or in events of lights turning on-off or doors opening/closing.

Our desire for a realtime GI system is more about utility/versatility than fancy graphics.

 

You can probably just use a cubemap solution for that. If you feedback the cubemap rendering onto itself through box projection, you can probably get a decent enough result as interior tend to be boxy themselves. Roughly:
1- render scene to a cubemap
2- use box projected light, like the arm shadow example
3- goto 1 (with the box projecting light)

I'm trying to do something along this idea but a bit more sophisticated, where I use the cubemap as an indirection texture to a light accumulation map, it's not ready yet.

 

Yeah, we hace cubemaps right now for reflections and stuff, but we would like to be able to have the possibility of maps generated on the spot, or maps with huge moving parts (like a bug chunk of the map transforming).

SEGI worked "almost" perfectly until it started giving us serious freezing/crash bugs and it heavily limited the scale/scope of the maps because of the voxel size being dependant on range. so we ditched it and are with a provisional default ambientlight and ambientreflections driven by WeatherMaker asset.

 

Well "render" to cubemap IS real time i mean, it can provide you that to some capacity, that's why I was proposing it.

In fact while I was thinking of a custom mode, unity provide way to do that with its cubemap it seems ... but I only see it for reflection, not sure about lighting.