SEGI (Fully Dynamic Global Illumination)

Discovered the problem: I placed SEGI in the scene Main Camera, but not in the Main Camera of my FirstPerson...
Fealing a bit stupid, but I'm a real noob and it's wonderful not to wait every time I change an asset position!
Looking at the light region some noise is visible when in play mode, any way to clean it?

 

Yea it should be surrounding your scene, starting at one edge from the camera. I believe I've seen this bug though where the volume was off some distance even though my GI was correctly rendered around the camera.

That said, I'm also assuming that your scene is modeled 1 unit/1 meter. Perhaps it's very tiny as well?

Just to allay any fears, I get killer looking scenes with SEGI, so it'll come with a little more work an investigation on your part

 

...I guess nm what I wrote then!! Yay your scene works and looks great!

 

I feel you!
The way tiny little mistakes like that make me waste time in my projects will never cease to amaze me! XD

 

About Unity 5.5 b4 I should confirm SEGI doesn't work correctly with Unity 5.5, some futures doesn't work at all. Can you please check this out?
Unity 5.5 solved lots of old unity bugs like shadow issues, I'm using Unity 5.5 now and SEGI is now part of my project can you please fix it for Unity 5.5b4?
Thank you.

 

Oh that's a shame, I was really looking forward using 5.5 but I guess I'll have to wait...
There is no doubt SEGI will be updated for it, the only question being "when?" as sonic told us he's currently having personal issues...

Just a quick question though, have you tried any other deffered post process in 5.5? Are there any other asset that no longer properly work with it? (maybe SESSAO, SCION, Amplify Occlusion...)

 

Each release for the beta versions will destroy any in depth assets that worked in the previous. By the time the asset updates or a post is made on how to update the script to fix it Unity will release another beta that changes it again. So really Asset Store items are made for full releases and not beta releases. Just way too much to keep track of the changes. At the end it boils down to the dev having time to post a fix on the thread and/or a user figuring out a fix and posting it on the thread too.

 

@Crossway I've seen lots of asset developers say they are waiting for 5.5 to be more stable before updating their assets to support it. That's not any different from what I've seen in prior betas as well, so please be patient with all of the developers you are asking to update to 5.5 beta support. Posting repeatedly about wanting 5.5 beta support now will just cause a lot of people to be frustrated.

 

Indeed it's often a losing game trying to play catch-up with beta changes as they tend to break quite a bit between versions. It becomes a frustrating time-sink and just creates a lot of unnecessary work a lot of times. I wouldn't expect anyone to officially support 5.5 until it is actually released.

 

Having a weird issue with SEGI and SteamVR... Seems like you can put the SEGI script on the Camera (Head) and see the GI effects in VR just fine, when the game is launched from the editor, but as soon as I build a standalone executable the GI stops functioning. Have confirmed that the rendering path is still deferred, it's not being changed at runtime or anything weird like that. One of the first times I've had something go from working more or less fine in the editor to being completely broken when launched standalone; any ideas?

 

Yea this puzzled a bunch of us early. Make sure SEGI is on Camera[Eyes] not [Head], despite the fact [Head] also has a Camera attached.

 

My mistake, it is on Camera (eye). Camera (head) is the orthographic camera. Still having this issue.

Just to reiterate, everything works perfectly fine when playing the game inside of the Unity editor, but trying to build a Standalone Windows executable causes SEGI to apparently not function at all. Graphics API is forced to DX11. Not sure what the issue could be.

This isn't just happening in my project, the exact same problem happens with the SEGI low poly example scene.

 

Hmmm well I'm out of ideas. I've yet to do a VR+SEGI build, so yea for all I know mine wouldn't work either.

@sonicether ?

 

@rustinlee Alrighty, I'm not entirely sure why I didn't do this til today (probably because testing in the editor is fine for me, removing the need for actual builds), but alas...

...SEGI + VR do indeed work! I'm using Unity 5.4, the latest SEGI and yea, I'm not sure what else may be important to note, but it does indeed work.

On I side note, I'm really worried SEGI is going to fall by the wayside. Just seeing what results I'm already getting, in VR no less, I really want this to grow and be successful. In the interim I don't know if that means we at least keep a conversation going or what, but this will disappear without an active forum. We've all seen it far too many times with wonderful assets. When you peek in on the ones that do make it, a robust community, active developer and an updated product are at the heart of it and it breeds it's own success.

Cross your fingers guys...

-Steven

 

Interesting, I wonder if it's a local issue? I only tested the standalone build on my PC so could very well just be something with my setup... Also possibly notable, I wasn't on the latest 5.4, this was done in 5.4.0f3 so I'll try again with the latest version.

 

The only thing I want from SEGI is a better performance! it's good on editor but after building the game it reduce my frames rate from 60 to 48. anyway SEGI is awesome.

 

For me one of the most important parts is that is upgraded to support large scenes. But if you visit he's webpage the most important features are already on the works.

Unfortunatelly the dev is going trough serious family issues so the development is halted/slowed. The good part is that this guy is ultratalented so sooner or later SEGI will be a complete project.

 

NVidia GTX 1080
Windows 10
Mode Ultra: 102 FPS

 

not quite the average consumer card but above 100 in ultra is very nice )

are the fps much higher in the lower quality settings?
like low but with high voxel quality (forgot how the top quality setting is called)

 

I've found Ultra to be largely unnecessary for the performance loss (which is a great thing btw) when you manage the size of the voxel volume. You really only appreciate GI up-close, so that leaves us with the problem of matching the overall tone for geometry outside of the voxel volume.

 

Hey everyone. This last month or so has been really rough, but things are starting to get better. I can't possibly predict what's going to happen in the future, but for now I'll be able to start putting more time into SEGI again. Thanks for understanding.

So, now that you guys have had a chance to work with SEGI for a while, I'd like to check-in with everyone about how you're feeling. What have you found to be the biggest limitations? What are you most looking forward to seeing improved? Do you feel that there is some performance headroom available to improve visual robustness, or would you rather see improvements in performance instead?

 

Glad to hear it man.

Visually SEGI is damn near perfect. Again only my obsession with GI, since the very first GI renderers were available, as my otherwise unqualified opinion of SEGI's accuracy, but I'm left completely satsified if not simply in awe, standing in my worlds (VR) looking at the lighting (early morning light is my favorite) cast upon my geometry.

That said...performance! Since I'm focused on VR, any ounce of performance gain is going to be huge. Cascades would help to keep detail around the player (as per my last post above, you don't need Ultra settings if you have a smaller Voxel Space) but maintain reasonable lighting consistency at distances.

Also if you can get SEGI to only render once and reuse that data for the other eye that would probably the single most significant performance boost.

Forward Render support would be the second most significant performance boost to VR, as it would allow us to utilize Valves Adaptive Quality and MSAA, along with all the other lighting boosts it allows.

As for features, you already have Cubemap support in your pipe, so I'd prioritize that, along with perhaps point and spot lights to round out our lighting options.

Baking is one of those last-option features that would make SEGI the superior choice to Enlighten. Easy to sell your asset then to anyone that cares even a little about lighting their worlds, on any platform, of any performance level. Last-option in that ultimately if the developer wanted to use your system but their chosen platform couldn't support SEGI in realtime, they can at least get a bake, and I stand by saying that the quality is definitely worth it. Never mind being able to adjust your lighting ad nauseam before committing to bake. Ugh Enlighten makes me cringe...

Those I feel would be substantive additions to SEGI and make it entirely feasible for damn near everyone. All the other visual elements you have in your pipeline could be slowly added then over various iterations.

Cheers brother

-Steven

 

I do think reducing light bleeding issues, like with the spherical harmonics / directional voxel data approach @sonicether was testing previously, should be pretty high up on the list as well. Please and thank you. x1,000,000.

 

I think performance should be the focus. At least for now. As it is right now, you can't really base your game around SEGI because it will only be playable at the very high end.

 

^...yup.It already looks fantastic. I'd rather work around light artifacts (I really see very few) and have something that is fast, rather than great visual quality that no one can play...

 

*I updated my last large post above to be a little more clear*

 

Glad to hear from you Sonic!

Definitely agree with @SteveB and @AcidArrow . I am overjoyed with the quality of using SEGI. I know some have issues with light leaking and other things but think improvements in performance would be a much better path right now. Cascading would definitely be a major help.

Edit- Also another vote for Cubemap support

 

Performance would be slick, but not necessary for me as what I plan on using SEGI for can have the normal lighting as a lower graphics option. In addition, I'm gonna have some pretty darned thick walls, so the bleeding isn't important either. (Anti-flame disclaimer: I am fully aware of how important these are to others, and therefore am just fine with them getting priority. You asked for my opinion, ya gonna git it.)
What I would really like would be point and spot light support, and those cascades. That would perfect it in my opinion

Glad to hear things are going better!

--IronDuke

 

Hey Sonic, glad your'e here again
I would like to see these things improved, other than that all seems to be quite good for now:

1. Removing artifacts on moving objects - probably the most important thing...
2. Deal with Light leaking if possible
3. Improving performance in general is always a good thing if possible
4. I don't think we can tell SEGI to ignore particle system for shadow casting - is that possible ???

Oh and one thing (don't know if it's a bug) i noticed... Whenever i add SEGI to a camera and have a particle system... the particles are no more facing the camera but stay like in world space - have weird orientation!

 

Hi Sonic, it's good to see you here!

Well I don't have any particular request, aside from those already talked about :
Removing artifacts on moving objects using the movement buffer would be an imperative (I didn't even considered it until I tried to play my game with AIs and yes, it's really unavoidable even if update isn't enabled.

Otherwise, the basic system is pretty solid as of now if you set up some maps with SEGI in mind (as I showed in my previous posts). So the only thing I would need personnally would be the "vanilla" cascades you showed us (without the future improvements for light leaking etc...). Also to improve performance, just a dumb thing I think, but having the ability to select a wider range of voxel resolutions would be great (especially lower ones, maybe 32x32 could be useful with cascades enabled?).

Then Forward and cubemap support vould be awesome, but that's for the future, but that's for later I guess.

Anyway, whatever you do, keep up the good work and keep us updated!

Have a good day everybody!

 

The baking of SEGI rendering by one mean or another would be a good solution for people that need to use a platform not compatible with DX11.
When you work on mobile (even high-end), you don't have access to geometry shaders, so a pre-bake made on a Windows desktop, and used on mobile would be a great help !

 

What I would like to see is a fix for light leaking and support for point and spot lights

 

For me, top priority would be light leaking, performance and artifacts from moving objects. I think those are the most important problems at the moment.

 

Hi @sonicether nice to see you back and happy things are improving for you. Following that, being SEGI absolutely the first asset I ever purchased in Unity store, I was wondering if the stories about Unity being an inconsistent environment due to relying too much on his third-party developers was true, so I hope all is going well and you are not forced to abandon the project.
From my really naive POV I fully understand the majority, focused on game and VR development, is asking for performance. Being my goal only video creation my preference will be for increasing visual quality and compatibility, i.e. bigger environments, cubemap, point lights, Unity 5.4 etc.
Apart that just thanks, it's a dream pursued three years becoming true.

 

Hi!
I recently purchased SEGI and had a few questions/problems I hope you guys can help me with

The first one is that Particles using Billboard rendering don't seem to be working correctly with SEGI and end up facing the wrong direction. Is this a known issue and is there a work-around?

The second question is more tricky.

In my game you can paint the ground different colors.
And although the paint texture appears colored thanks to my shader, it's actually a black/white image.
Sadly SEGI is using the texture properties for bounce lighting, so no matter what color the paint is, it always produces black/white bounce lighting.

I could previously get around this using the "finalcolor" function in my shader while using Forward Rendering.
But as SEGI is only compatible with Deferred, I've yet to find a way to fix this and I'd appreciate any help.
Unity recently added the "finalgbuffer" & "finalprepass" functions for Deferred rendering shaders, but so far it only seems to alter the color of the material, not it's contributions to bounce lighting. So I'm at a loss.

 

Hey there Sonic Ether,

Surely not all the surfaces in the world are opaque...are we totally forgetting about translucent surfaces?
I'd say having SEGI work with translucent surfaces that allow light to pass through and get realistically filtered is pivotal.
Of course, this should be after performance(particularly for VR) gets sorted out first!

Cheers
Melvin Eng
Workshop Foundry

 

I make ArchViz and bought your Asset because it looks very promising. I wasn't able to achieve the same results (or better) as with Enlighten yet, but I think SEGI has a lot of potential.
For me visual fidelity would be the highest priority and not so much performance, but it can't hurt .

I'm currently on the Unity Beta Versions (mainly for the new Splash Screen), so unfortunately I can't experiment with SEGI currently. I guess due to the volatility of Betas it would be too much to aks if it would be possible for you to fix/adjust SEGI to work with the Beta?

 

In regards to backing, I recall someone created an script that allows the system to update each "n" seconds.

I understand that if you set all to Ultra and update, lets say every 600 secs you've de facto backed lighting, Is that right?

The only drawback would be that at the load of the scene would have a bit of delay computing lighting but pretty much unnoticeable.

 

But only baked for that position in space. Once you move then it needs to recalculate to keep the appearance correct. Our current script is based on space and environment changes. So if the player moves X meters or the lighting changes X amount it will recalculate. Until then it is ok to use current data.

 

BUt you mean wrong to by how non static object affect lighting right? If you "bake" a city with this method shouldnt get similar ressult as if backed with beast?

 

Look What I found:

 

This question is for anyone who knows.
My geometry is constructed in geometry shaders. The mesh objects in the MeshFilter are not representative of what's on screen. Does this SEGI will not work for me?
Thanks.

 

Another video using SEGI from the same artist

 

Must feel good when your asset is fueling the best looking scenes of an engine.

 

Thanks to this asset, I could switch back from the Unreal Engine 4 to Unity 5. SEGI makes to me a better impression than that Nvidia Gameworks integration UE4 is using which its extra hassle for nada.

I don't know what baking in this solution is going to look like. But last time a looked, so before I left UE4, there was no word from Nvidia that they even plan to implement baking.

I haven't bought SEGI just yet. I just hope that my cube / voxel art direction is not going to make problems around the mesh edges. My game's art direction was changed after I experimented with UE4's Nvidia VXGI that was done on that UE4 Reflection demo scene. I also created a computer display that showed a flickering Doom Beta (2016) poster in that very scene. So...

Uno question: Can I control the indirect lighting of emissive surfaces independent from the actual emission value? Is there some kind of boost option? Because I had that problem in UE4, that I wanted the flickering display to cast light on the ground. But in order to increase the intensity of the indirect light cast by the emissive surface. I had to increase the emission value. This over brighten the display by a horrible lot. The display was glowing as if it was reaching critical mass, if you know what I mean.

 

You should be able to achieve that by using a clever layer setup, by duplicating the mesh you want to emit light : one on the layer seen by the camera, and an other (the criticalmass one) not seen by the camera but used by segi.
Keep in mind however that only deferred shaders are used by SEGI for now.

 

Thanks for the tip, arnoob. I will keep this in mind.

 

Thanks for your feedback, guys!

I've just implemented Unity's new built-in motion vectors into the temporal sampling in SEGI. It was actually surprisingly simple, and the results are quite good! There is room for improvement, so it'll take some time for me to find solutions for the remaining issues, but it's still a vast improvement.

Regarding optimizing SEGI further, I do have an idea I've been meaning to try out for a while. Essentially, instead of doing all of the cone tracing in screen-space using gbuffer data, I'd like to do some of the tracing in 3D volumes and leave the fine-scale (close-proximity/high detail) tracing for screen-space. I have no idea how that will turn out, but I'll let you guys know when I end up trying it.

 

I'm still struggling with my issue.
I've sent you a direct message if you'd be able to take a look, Sonicether

 

Hey Cody, is there any way getting SEGI to work in 5.5b6?
Debugging is not showing any voxels generated, but only black color.
The list with presets is not loading as well for me!
Thanks!

PS. oh i forgot... great news about implementing Motion Vectors... You're great!