SEGI (Fully Dynamic Global Illumination)

If you can please answer my previous question too. thanks.

 

The problem is that SEGI doesn't support non-deferred shaders. Shaders that need their own custom BRDFs like the skin shaders you're using need to be rendered in a forward pass after all the deferred objects are rendered. SEGI needs the deferred gbuffer data to render indirect lighting properly, so non-deferred shaders won't work. Support for custom non-deferred shaders is planned for the future.

 

Bless you, if you can get this working with single pass rendering you will be a king

 

It depends on your settings, but generally voxelization is the most expensive part of the algorithm. Most of my optimization work is going to go into improving the speed of voxelization.

 

Nice! looking forward to the new update i'll be sure to make some performance comparisons between versions.

 

Glad to see the new patch coming. I still feel that the wording needs to be changed when you're saying things like "for handling large scenes". I'm sorry but "greater than 50m" is not a "large scene" and if you disagree, you're just wrong.

 

Currently in editor my builds are looking great, but my builds are completely different. The outdoor portions look fine in both build and editor but it seems that in the build the reflected light isn't really working in the open deck areas. I have it on Medium preset, I have removed all other image effects from the camera for testing with no change. The output log is clean with no messages.

In build:


In Editor:


The behavior I am seeing is the same in the build as the editor except in the editor it gets dark to begin, then the lighting catches up and brings the shadows up to the light shown in the screenshot. The build never goes that far, it stays at the dark level. Any idea what could cause such a drastic difference between the build and editor?

 

Have you tried profiling the build and see if there's anything that seems wrong in the stats? Maybe something doesn't get enabled somehow.

Your game is looking pretty nice btw

 

It seems like SEGI does not apply to Worldspace Lit UI. Is there any way for me to modify it or the Lit UI shader to get it to work? Using the SEGI doc's reccommendation of turning Ambient Intensity to 0 means that UI facing away from the directional light is almost completely black.

 

Is that a transparent shader? Wouldn't it be forward rendered? In which case SEGI won't affect it. If you can edit the shader you might want to add a value to the final color

Or add a light to the ui and set its culling mask

 

It might be transparent though in my particular case I'd be fine with all the UI being non-transparent. I don't know the specifics but using a regular shader like Standard Shader for Lit UI causes the fonts to get garbled, so maybe there is no built in way to get it working in Deferred.

I actually did already try your second idea; I found that using the "Vertex Lit Blended" particle shader works ok if I set the emissive color to match SEGI's sky color, buuuuuut it could be better.

 

YeeeeeeeeES!

 

Hey Lazy, making a reasonable assumption that the Rift and Vive are largely the same regarding implementation (I have both but I'm focusing on the Vive for now), but what did you do to get SEGI to work on the Oculus? Right now (again the Vive), I place SEGI on the [camera_rig] and the viewport immediately flips upside down, never mind that no GI is actually happening.

Thanks man!

-Steven

 

I've been testing with a DK2 and Oculus 1.5 in 5.3.5p7 with no issues at all, just a basic setup and it works fine.

 

Yea I mistakenly placed SEGI on the Camera (head) when it should be on Camera (eye). The mistake though is reasonable since both the head and the eye have cameras, and I just hit the first one I noticed.

This is a good note for all you SteamVR peeps

Thanks Cap'n!

-Steven

 

It's not only skin shaders! lots of Alloy shaders doesn't work with SEGI too! please put this on your first priority cause I can't use it anymore. performance is great for me but because of this issue SEGI becomes totally useless for me.

 

@ksam2 you should probably ask the Alloy devs to look into support or integration with SEGI as well. Alloy uses its own BRDF for most/all of their shaders, including the deferred ones.

 

Keep us posted on your multiple camera discoveries using SEGI and SENBDL @sonicether. I'm very curious of this outcome

 

@sonicether . As recomended i set ambient lighting to 0 when using SEGI. The areas on a distance outside the voxel area with no direct lighting will then be dark. Is it possible to add a feature to add a ambient light to all pixels outside SEGI area?

Lennart

 

just noticed SEGI 0.81 is available... !

 

Just updated - fps has jumped from 38 FPS wright away to 50 FPS compared to v0.8 !

 

@sonicether just tested the new update, I'm seeing a 15-20% increase in performance

 

Nice to see the new update. Here are the stats i took of SEGI and compared between versions:

(I'll put the stats inside a Spoiler tag so it doesn't clutter the thread)

Spoiler: SEGI new version stats

Hardware:
CPU - i7-4790K @ 4.00GHz
GPU - GTX 970
RAM - 16GB @ 1600MHz

Screen Resolution of the Game View used inside the editor : 1616x909

---

Scene not optimized for SEGI yet.
Scene Graphic Stats:
- Batches: 693
- Saved by batching: 2573
- Tris: 417k
- Verts: 546k

Image Effects used: SMAA, HBAO, SEGI, SCION


Preset - CPU - GPU - VRAM Usage by SEGI

No SEGI - 7.0 ms - 2.2 ms - 0 MB

V 0.8:
Low - 10.2 ms - 3 ms - 83.30 MB
Medium - 12.5 ms - 3.1 ms - 83.25 MB
High - 21 ms - 3.1 ms - 547.53 MB
Insane - 31 ms - 3.1 ms - 547.53 MB

V 0.81:
Low - 9.8 ms - 3.3 ms - 75.30 MB
Medium - 11.9 ms - 2.9 ms - 75.25 MB
High - 17.5 ms - 2.8 ms - 483.53 MB ( Infinite Bounces Off: 16.0 ms - 3.3 ms )
Insane - 27.5 ms - 3.0 ms - 483.53 MB ( Infinite Bounces Off: 26.0 ms - 3.4 ms )

Improvement SEGI ONLY (CPU (+CPU Differece), Video Memory): (stats with SEGI minus stats without SEGI)
Low - 12.5% ( minus 0.4ms ) - 10%
Medium - 11% ( minus 0.6ms ) - 10%
High - 25% ( minus 3.5ms ) - 12%
Insane - 15 % ( minus 3.5ms ) - 12%

Video memory was reduced by ~11% and performance improvements are more noticeable when voxel resolution is on High (makes sense because of what was worked on).
Also note the scene isn't optimized for SEGI yet, so the performance could be much better than what is now.

Edit:
Updated the stats with the hardware used.

Edit2:
Updated with fixed SEGI stats and CPU Difference between versions.

 

That improvement really is significant, well done

 

Hi , I have been following this a lot recently and I have few questions.

Is it possible to have GI contributing objects that are not actually rendered?

I mean say if I want to create a top down adventure / dungeon crawler game and have some light on the ceiling of the cave or something like that but I want to hide this object from the actual rendering because it will obstruct the view of the player. So I would like to separate the ceiling part of the "room" so that the GI is computed correctly as if it was closed , but the ceiling is not rendered so the player can see inside.

Is this possible?

 

I think the overall lightening will not differ a lot from having a ceilling or not.

 

Correct me if I'm wrong, but I think the notion of having meshes that contribute to voxelization but aren't rendered is how you use low-poly versions of meshes to help optimize performance, as per SE's recommendation. You essentially have your low-poly shapes to approximate the scene geometry for voxelizing, but you only render the more complex meshes (which do not contribute to GI).

 

Arhh.. So it is possible to have object contributing to GI but not rendered? Can anyone confirm this from their experience? I have tried to find doc about this, but nothing .. maybe doc is in the package only.

 

I think it certainly will if ceiling has a light on it ( emissive material ).

 

Thank you, reducing it to 1 made the scene look much more natural!

 

Damn...already a huge, noticeable boost

 

So far my biggest problem with SEGI is that now that I've seen it, I can never go back. I didn't think I'd be able to get this kind of quality with my game due to how dynamic it is (Minecraft-esque building and procedural world) but now that I've seen it's possible I'm hooked.

 

I had to go ahead and buy this , even if it was for development support sake.

It's great...

First obvious optimization that I can think of is to be able to configure the voxel calculation boundary a bit better. At the moment, there is only one size parameter, but I am wondering if it is possible to make no square sizes. If this is possible it may be a huge performance boost , depends on the kind of game you are making.

But I wonder if this is possible... perhaps not because of the nature of the tech used here.

I have not had this much fun working with lights in Unity , ever.

 

@sonicether is it possible to have a medium setting for voxel resolution? the VRAM difference between low(75MB) and high(485MB) is way too much. Having a medium setting would be much better for more customization.

I'm only guessing here, since it's weird there's no medium setting, but is the reason because it's an exponential increment? and after 75MB there's only 485MB?

 

Voxel cascades on the roadmap (bottom of the SEGI link) are what you and pretty much all of us are looking forward to, to optimize for larger scenes. Presumably, you'll be able to set size and other detail vs performance settings for each volume, once those are implemented.

 

with purchasing the beta, do i buy the release candidate too? what about updates after release?

 

Forward shaders support would be nice and necessary.

 

"The problem is that SEGI doesn't support non-deferred shaders. Shaders that need their own custom BRDFs like the skin shaders you're using need to be rendered in a forward pass after all the deferred objects are rendered. SEGI needs the deferred gbuffer data to render indirect lighting properly, so non-deferred shaders won't work. Support for custom non-deferred shaders is planned for the future."

That's what Sonic said, just a few posts ago. Not gonna happen.
EDIT: I stand corrected, my bad.

 

I don't see how "support for customer non-deferred shaders is planned for the future" is the same as "not gonna happen." Not gonna happen right now, obviously, and likely not for a long while, but I doubt Sonic thinks this asset will be considered complete without at least some sort of forward shader support.

 

Forward-rendered object support is also on the official roadmap, FYI.

 

@castor76 I've been on the road and a litter sow to reply, but yes, you can have meshes contribute to the GI but not be rendered in the view.

I've been doing that for small lighting details that are too small to be detected consis3ntetlt by SEGI. Basically add a larger volume mesh with emission and put it on layer that isn't rendered by your camera for example.

 

yeah. i bought the package anyway and having a blast with it.

it is exciting as it is now. but even more for the future updates. waiting is killing me.

 

I had a go with VR with this asset and it seems to me that with future optimization, this asset could work.

My only concern at this moment is the smoothness of the bounced lights especially when things are moving.

In VR, things gets worse over time, and more noticeable when there are artifacts happens.

I have tried to simulate some torch in closed chamber and it flickers a bit too much even with some good quality settings.

I hope improvements comes soon!

 

could you please answer my question!? i really consider ordering this asset

 

when you buy the beta you get all the future updates to this asset

 

Would it be possible for SEGI to only apply ambient occlusion? For instance the scene ambient light is coming from the sky and SEGI is only used to occlude it.

You would think this would be considerably faster and give good enough results for many applications.

 

for ao only, it will be better to use ssao instead.

 

First off SSAO can't compare to skylight occlusion by any great stretch, but it is a faster alternative true...

...that said, if you're only lighting by skylight, you could arguably drop the secondary cones, infinite bounces and lower the primary cone values and those should speed things up considerably. Couple that with the fact that without moving lights and static geometry, you could even use the script buried in this thread to essentially turn off updating.

 

@sonicether Just checked out your demo. This is very promising indeed.

Cool. Since you're looking at Vive support would it be possible to have it compatible with Valve's The Lab forward renderer? Not sure of the technical limitations but it seems a combo could be quite powerful. I apologize if this has been asked before.
https://www.assetstore.unity3d.com/en/#!/content/63141

 

Hmmm yea not until Forward Rendering is implemented, but the shaders should then otherwise work fine.