SEGI (Fully Dynamic Global Illumination)

AFAIK Unity only works with OpenES 3.0 on NVidia Shield. That will not be enough for SEGI.
As for emissive materials: Check the demos in the start post of this thread. They use emissive materials quite a lot.

 

@scheichs : I was talking about the downloadable demos, with emissive materials only. There is none.

 

Have you tried the low poly one? You can shoot glowing orbs and there's even a cave with glowing crystals in it... Both things are just emissive materials.

 

I know about the light spheres you can shoot. I was talking about a specific interior scene with only emission materials. It lacks a demo to show what it looks like.

What about some archviz type interior with switchable lights for the future ?

 

I think the archviz screenshot on SEGI website is using emissive materials on the windows. I remember asking about the lighting setup *way* back in this thread.

 

Update of my game using SEGI

 

Really nice colors

 

Anyone tried SEGI with 2017.1 yet? Does it work?

 

It does work, but it looks a bit broken to me at some points compared to older Unity versions. Could be just false imagination from my side, though... But yeah, it works.

 

ok , I know Cascades and performance were the two big things everyone wanted , you have shown improvements in those areas .....

now where is the release man? is that hard to package it up and send it to the store front?

can we pm with invoice and get the whatever you have now?

 

The hype has moved to HxGI now

 

I really want both... Just segi is a bit quiet lately. I have a bad feeling about SE's family health situation...

Hope he's ok.

But yeah I agree hxgi has some movement for sure. Man I'd love to get my hands on this cascades update though!

 

SEGI for Unity 2017.1 please !? Any chance ?

 

I think I am done being remorseful and apologetic when I complain on this thread.

More fool me for expecting better from an asset store dev who rarely updates his other assets either. Why did I think it would be different with his product that is still in beta and development? A couple of updates in over a year, the last of which was to fix 5.5 compatibility. No, not on, and I'm done with SEGI because even if a newer, better version appeared now I would not be able to trust that future updates to deal with unity version compatibility would arrive in a timely fashion.

He even posted in a thread for one of his other assets earlier this week, but nothing here. Goodbye bad buy.

edited to add: I mean I thought I had sensibly adjusted my general expectations to deal with the era we are living in now having widely misused the term beta. But no updates in the entire calendar year to date seems to me to rather stretch even the modern loose meaning of the word beta.

 

Just a few last thoughts before I likely fall silent on this thread.

I think it gets to me because of how much I appreciated the large amount of effort that sonicether put into explaining the current state of the beta SEGI when first released, some potential future risks, a roadmap that was very informative, etc. Because of that good stuff my expectations were certainly met when I first purchased SEGI, but tragically it has not been possible to sustain this stuff for reasons unknown.

For example:

Surely you should realise that you should only tell the world this stuff if you actually plan to then put the new version in the hands of your customers within a reasonable period of time? Because without a timely release following such positive and useful info, its a terrible tease and it turns sour.

To respond in the same way that that sonicether put it in the quote above: The change has been gradual from your perspective. It should have been gradual from your customers perspective too! Because you should have put way more effort into turning your continually evolving development version into fairly frequent releases for your numerous customers.

 

SEGI works just fine for Unity 2017.1.

I'd like to say right now that the next update with blue noise and cascades (and other optimizations) is nearly done now, but as you fellow developers know, the last 10% is really just another 90%, and even though I know this, it still takes me by surprise time and time again. I haven't been too vocal about this huge update's progression because I don't want you all to be so disappointed because I've been saying "soon" for so long. But, if I just leave it at, "I'm working on it," people still end up being upset. So, either I'm teasing releases, or I'm "disappearing". I feel like I'm being pulled in different directions here.

The nature of this project makes it difficult to make steady progress because so much trial and error and experimentation is required. Not to mention, refactoring the entire structure of the algorithm for cascades has been no easy task (once again, the last 10% is another 90%). It's been so long since the last update because even though this is a beta, I still have to treat it like a product in that I can't release any updates if they're unstable/buggy or otherwise unfinished in a way that makes it seem sloppy. I don't know, maybe people are more forgiving of things like that than I anticipate, but all you need to do is scroll through this thread to see how critical people have been of this project so far.

So is the update with cascades coming soon? I'd like to say so, but I've really grown to hate that word, and I get the feeling a lot of you have as well. So, I don't know what else to say other than I'm still working on it and I'll submit the update when it's done.

 

^you have been available via email to be sure, which most people probably forgot was even an option

 

Well said Sonic. Every release you've done so far has been very clean and I can appreciate wanting to keep it that way.

 

Believe it or not I do have some sympathy with some, but not all, of the dilemmas your describe.

Personally I expected lots of bugs and rough edges, and lots of updates. Thats what I assumed I was getting with the beta and what most other assets that I've bought 'in beta' have delivered over the years.

Even if I water down my own position slightly, I think the right balance has not been struck to date. I know how hard the last 10% can be and how hard it can be to release code without it having reached a level of polish and stability that the developer is really happy with. But I think once you start to sell something (and despite the fact I know you were pressured into releasing originally), you have to be more prepared to keep pushing updates into your customers hands rather than wait for stuff to feel more finished.

Since it is quite possible to put unity packages inside unity packages, it seems like it would be possible to have both the current release that also contained a package of more recent experimental version available via the asset store without having to offer the latest experimental version via an alternative download mechanism that would be much more work for you to maintain.

 

At the risk of me harping on too much like a broken record, I have a thought about this one. More communication and detail is always better than less, and I have no problem at all with a bunch of other assets where futuristic features are sometimes teased a long time before they are available. So its probably up to me to explain this contradiction. I havent quite come up with a full explanation I am happy with yet. But I think its probably got something to do with general update frequency and authors ability to granularise their development with frequent releases in mind, not getting stuck in the trap of having loads of refactored stuff earmarked for some huge new major version that never quite seems to boil over into a release.

 

Hey @sonicether, my team has purchased SEGI to try it out for our project and I was wondering if it was possible to optimize it's performance by only having it calculate GI at specific intervals (as opposed to each frame). We're doing an architectural modelling tool, so the actual geometry of the scene changes at fairly low frequencies.

Thanks for any help and great work on the tool!

 

This script already exists, read the forum

 

You can get a long way there already. I can't remember if you can get all the way there though. There are a couple of inspector exposed variables they prevent recalculation (or maybe just one). Turn it off and frame rate increases but the light stops updating. Use a script to toggle it when you like, such as when your geometry changes.

Not sure if there's more that can be done. Sonic will have to answer.

 

Found it in "Update GI", not sure how I missed it initially (played around with some of the internal variables in the class :S).

Thanks for the answers guys!

 

This script will only reduce voxelisation part (10-20% performance gain, though. Maybe with performance spikes...), main calc-heavy part is ray tracing light propagation - and it is done in screen space and this can't be stretched between frames by design...

 

Currently looking for other GI solutions. How good/bad does this work in VR (Oculus Rift) currently?

 

Well it needs Single-Pass Stereo implemented, so right now SEGI is being calculated for each eye.

I'm eager for this too...

 

I contacted Cody about this via email in mid-July. He indicated that the core algorithm for SEGI was his highest priority for right now and that he would start working on single-pass stereo rendering after he's happy with the functionality.

 

Hi, yes it works in the Editor only, but you couldn't build a scene as it throws some errors !

Assets/SEGI/SEGI.cs(384,22): error CS1061: Type `UnityEngine.RenderTexture' does not contain a definition for `generateMips' and no extension method `generateMips' of type `UnityEngine.RenderTexture' could be found. Are you missing an assembly reference?

Error appears at:
- SEGI.cs(384,18)
- SEGI.cs(401,18)
- SEGI.cs(417,18)
- SEGI.cs(668,18)

This happened with just created brand new project. This error shows when i just started to build the low poly scene!

Thanks !

UPDATE:
For all of you guys just to know the issue is related to the "generateMips" option of the RenderTexture which is actually deprecared now in 2017.1 As soon as these four lines are commented, you will be able to build a scene with SEGI working well !

 

One more thing...

if you put SEGI in another folder the presets are not loaded... If this could be addressed as well will be great !

Thank You!

 

That happens because the path to the presets is hard-coded. In SEGIEditor.cs, there's this line:

Code (CSharp):

1. const string presetPath = "Assets/SEGI/Resources/Presets";

 

Bad, unfortunately. I mean it looks very nice, but FPS around 50.

 

And... the update is coming... anytime

 

I afraid we will never see the production version. OTOY has added the path tracing plugin to Unity 2017. It works amazing and it fast but not in real time of cause. Next year OTOY promised the physically correct path tracing in REAL TIME! So, Sonic has just a year. I appreciate his hard work, by I don't think it will be completed in time.

P.S. Somebody was interested in the fast baking. OTOY has the "baking" camera (I didn't get how to use the baked texture though)
-Added texture and lighting baking by introducing a new baking camera.

 

link?

 

Well, there's still hope for HXGI... Not sure what to think of OTOY, to be honest. I mean, Path tracing always has noise (in the beginning)?

 

I'm not going to make any assumptions about what OTOY will achieve in the years ahead. There is potential with some of their stuff for sure but lots of devilish detail and I'm certainly not going to start thinking about it as an alternative realtime GI solution at this stage. And I certainly dont think its started a countdown to a time when all other solutions will surely be obsolete.

 

https://unity.otoy.com/guides/working-cameras-octane-unity/

• The Baking camera type is used to bake lighting into textures, this is a more advanced topic. For more information on baking cameras consult Octane Standalone documentation

https://docs.otoy.com/StandaloneH/StandaloneManual.htm#Standalone/Baking_Camera.htm#kanchor176

 

They are working on the AI denoiser, that will reduce the noise in hundreds time:
https://www.facebook.com/groups/OctaneRender/permalink/806910102819403/

 

OTOY will only be realtime in some very special/tuned/optimized cases. In general it is meant to produce high quality cinematic videos. You can see this in "OTOY Unity preview"-page where one image needs more than 5 mins to be generated.


SEGI and HXGI are in the 1-5ms ballpark for GI, without having to be demonstrated in artifical scenes.
So please stop the OTOY discussion.

 

Yeah there is realtime (editing) and real time (playable framerate)

 

Wow! Feels like something huge happened in realtime path-tracing - 1 sample per pixel per frame + set of temporal/edge detect filters = this:

Guess animated objects will have huuuuge trails of artifacts, though...

 

This is all about post processing a rendered texture with a lot of noise. VRay supports that feature as well as Blender...
Could be the key to real time path tracing in games.... it is interesting if such techniques can be applied to voxel based renderers like SEGI !

This shouldn't be happening imo

 

I wonder if retroprojection can help, as this is above my skill level

 

Hey guys,

It would definitely help to get an update with SEGI to help on performance and cascading on larger scenes. Though I did get pretty good performance with some optimizations on a scene for my tropical pack update. It is a smaller terrain but with pretty dense foliage. Using low voxel resolution with infinite bounces. Was getting 36-50 FPS in editor at 1080*910 resolution on my new Ryzen 1700, GTX 1050 Ti build. The 1050 is a good card but nothing compared to the 1070, which I would love to test in this scene. Here are a few shots-




(birds being used are from the Bird Flock Bundle by Unluck Software)





What I did to optimize the scene was I duplicated the terrain data and added the copy to the scene. Then I deleted all the tree prefabs from that copied GI terrain. Using the layers I set my base terrain to terrain and the GI copy to GI. So hid the GI copy from my camera of course and hid the base terrain from the SEGI layers. All the trees in this scene are gameobjects so are still being used by SEGI but the ground cover LOD trees using the terrain system are not being voxelized by SEGI. This helped a lot on perfromance. Also set all the gameobject cover on the rocks and ground to a layer not being voxelized by SEGI but seen by the camera.

Was very happy with the results from this. I tested the scene with Enlighten with just the rocks and terrain static. It looked pretty good but then there was the issue with the trees not contributing and the rocks LODs. Lightprobes and the new Proxy Volume just did not help with the popping. Also performance was not that much different. Could be even worse with Enlighten if the sun is moving.

So having dynamic real-time GI on a nature environment in Unity with usable framerates on a mid grade GPU is nice. With a few needed updates on SEGI do not see how it would not be production ready for most well optimized projects.

 

very nice scene you got there. what volumetric light solution do you use?

 

Thank you. It is using @Michal_ 's Open Soruce True Volumetric Lights. I know I can get more realistic settings with it but just like the classic sun rays going all the way to the ground.

 

Main problem with Otoy is that it can't use custom shaders (it supports only standard unity shader). So this is a great deal breaker ofr any future Otoy implementation.

 

is anyone having performance changes after updating unity?
i used to have 40-50 fps but now 12 fps on the lowest setting of SEGI