SEGI (Fully Dynamic Global Illumination)

We really need some info, many of people would pay a lot of money for blazing fast lightmapping!

 

I'm glad to see that so many people are interested in what SEGI has turned into after two months of development. However, the work is not yet complete, but my dream of next-gen global illumination for Unity is closer than ever.

No, it's impossible. My solution is absolutely different and the baked data is stored in its own optimized format.

In the near future I will create a new thread with video, screenshots and all the information.

I have not tried Octane, so I can't compare the baking time, unfortunately...

If everything goes smoothly, it will be released at the end of this year or at the beginning of next year. It will be a new, separate product offering game-ready global illumination solution with realtime/baking options, continuous updates and support.

Right here, right now!
Do you know that song?

 

Thanks a lot, that's all I needed

 

@nxrighthere put the sale price around $180 in order to have a sustainable business and enable us to have a working solution for years...

 

Just wanted to share some stuff i'm working on, discovered SEGI recently and i'm trying to put it to good use I threw away all my unity dynamic lights (it's a random-generated game, so i can't bake), and focusing on just lighting with emissive maps.

Thanks so much for this incredible tech!

 

Oh, you mean that you are releasing it on the asset store? I thought that the community was finally taking off but I guess I was a bit too optimist on this matter... That said I understand it perfectly, it's fair for you.

@homeworld4 Great job! THAT is a proper integration of SEGI, your game looks really great, it reminds me of Wolfenstein.

 

I wonder if it will provide a descend frame rate on 1080p and old GTX970 or a GTX 1050 for example with performance similar to CryEngine SVOGI.
Will it work for terrain, vegetation and large landscape, letting us adjust the distance GI should cover ?

 

@nxrighthere Will the realtime solution support point and spot lights? Also, will the baking solution support point / spot? I instantiate my entire game world dynamically using room prefabs that have lights and models, I'm unable to use Unity's default lightmapper since it can't store the data in the prefab - would it be possible to store the data for each prefab in the prefab in your solution?

 

I bought a new pc with a decent cpu and the gpu was cuda wo I thought it couldn't be worse than the old one ... it's a gt705, the dream is over for me LMAO and now I'm in debt for a bit longer, no new card for at least 4 month.

Still can't wait what @nxrighthere as in store

 

fantastic news ... one cannot have enough GI solution!

 

It looks like Godot 3 already do real time GI and able to light using emissive only objects
https://twitter.com/twitter/statuses/932510224623198208
I wonder if someone would do a performance compare with SEGI ?

 

I have GTX 950 and in scene that contains 10x1000m terrain pieces, many trees and other objects with baked GI and occlusion culling, I get ~95 fps @ 1080p. In the current version, the baking process took 50 seconds to calculate all the data. So yes, performance is not a question with the baked GI. In the same scene, but with the realtime GI using optimal settings, I get ~50 fps.

Point and spot lights is still doesn't contribute to GI, but it's possible with using emissive materials.

I want to provide a good discount for people who bought the original SEGI, but I'm not sure how can I do this.

 

What exactly will baking do? Will it just result in no voxelization at runtime?
Can stuff near the camera still use dynamic GI (maybe when doors get opened or something)?

 

Current solution is baking voxel and other data of the objects in the scene that never moves to reduce calculations at runtime and you can still have the moving objects that will be lit by the GI. You can call it semi-realtime GI if you want.

 

yeah , this is me getting ready for your GI

 

Looks great performance for both baked and real time GI (with some pre prebaked baked voxels) considering the 3D card.

 

Dumb question but can't it already be done by switching off the "update GI" bool in the current SEGI?

What is the voxel density you are using in you method, and what is its vram usage? Did you manage to store the baking in the standard ram in order to stream it in the VRAM when needed?

Also, I was wondering about the rendering of the GI itself. Currently SEGI is doing it in postprocess. Is it really faster than rendering it on the mesh shader itself? (by creating some custom shaders that would read the 3D GI texture in world position accordingly and display it in the emission?).

 

1) SEGI only calculates GI for an area, not for the whole map.
2) Even without updating, it pulls quite a bit of performance.

 

*You are doing God's work*

Please, if at all possible, provide a demo version when / if your implementation becomes available.

 

1 there's always a limit to the calculated area, the reason it's currently so limited is because the calculated area is stored in the VRAM, which is pretty limited. That's why I asked if he stored the bake in a 3D texture on the RAM, which would then be used to quickly create a 3D texture to feed to the VRAM according to the current camera position . No matter how you do it, there will always be a limit to the actually displayed GI from baking.

2 The performance he talked about (around 100fps on a GT950 without additional heavy effects) is already easily achievable with the current SEGI if you disable the "update", and if you set the parameters correctly (half resolution on, efficient TemporalBlendWeight). Plus it is screen based (not geometry dependent), so the performance will stay the same no matter the geometry displayed (I'm talking about the rendering here, not the baking of course).

 

Hey bud, I really appreciate your effort and contribution...I really do, but let's not make haste judgement of Sonic over this. I totally understand where you are coming from, but I also understand the life of a dev on a tight budget and time. I think, at least in my case, Sonic's passion and love for SEGI is beyond our imagination - he probably spent 400+ hours of work on SEGI and to let it go as FREE open source material due to financial issues. I've been there...it hurts...like parting with your baby...so let's not just dump a line that makes Sonic look like a dude who just abandoned something...I mean who else would understand something like this other than us devs? Sonic probably feels bad enough already...let's just be supportive...

Other than that I am super excited to get my hands on on your latest work...any download links or screenies?

 

↓

 

Just awesome

Maybe nx should start a new thread for the upcoming product - and provide more details as things get ready.

 

He planned to do this:

(That are enough Quotes for today )

 

Darn, sounds like my search for the perfect GI solution goes on - sounds like it'll be a nice solution for outdoor scenes though!

 

If only it was so easy... It's not the same as if you just disable update GI and skip the whole voxelization part and other things.

You're thinking in the right direction and you are really close to the idea that came to me a month ago, but it's not that simple... To use the baked data, I had to change a lot in the SEGI source code.

It might be even better, but I need time to change some things in the original code.

Thank you. The demo will be available as soon as possible.

I just gave you the answer to the same question that I asked myself some time ago and nothing else.

 

I have mixed feelings about this, to be honest. I, along others, bought SEGI Beta when it came out with the hope that we see continuous updates. Things, however, didn't turned out the way for imo legit and understandable reasons and so Cody throwed it onto GitHub (for which we all should be thankful) as Open Source software - free. Now, someone else picked it up, improved it further (which is good) and decides to release it on the Asset Store and provide "existing customers a good discount". Not sure how to feel about that...

From time to time, I feel like giving up on realtime GI completely is the best solution. Too much trouble going on for such a "simple" feature...

But that's just my thinkering. Please don't be offended.

 

I know your feelings. I'll think about other ways to make it available or I just will not release it at all. Time will tell...

 

SEGI, while being somewhat heavy, already is stable enough to be used in games IMO. If that can give you a little hope back, know that I personally will stick to it and try to improve it a bit (I am mainly a modeler, not a coder, but I spent a big amount of time trying to learn about shaders this pas year. And while I am not a pro yet, I think I understood how it worked under the hood, and what is possible to be improved in it, if only I knew how to actually code...).

By the way, just out of curiosity, could the people around here that are willing to participate to the COMMUNITY SEGI (available for all for free in a Github) manifest themselves?

I will try to create my own Github, a copy of the original from Sonic, in order to be able to add new improvements from the community and from myself without having to need that Sonic approves it (I think he pretty much went silent about it because of his personal life events, and the reason he putted on it Github was really that he wanted us to fully take the relay).


Also @nxrighthere, I know that you are planning to do your own asset now, and that you probably see the development of a community SEGI as some kind of a business competition, which is perfectly understandable. That said, I think that what you do (a fully static baking) would be pretty different than what we are trying to achieve here (an optimized real time baking, in the fashion of the original SEGI). So, I don't know what is your feeling about it, but I personally would be glad to hear what are the changements you did in order to achieve better performances. Again, I fully understand if you are not at ease with giving this kind of informations.


On my side, I think that what would be a great improvement, without going too deep in a modification of the current asset, would be to find a way to tell to the code over how many frame we want the the next baking to occur. This way the impact would be far less important, especially if like me you want to make a new bake only when the player has moved over X meters (it is already achievable by switching on/off the "updateGI", but result in a short noticeable lag each time, delaying it would ease it a lot).

Anyway, if people know how to do that or have other simple ideas to improve the asset, just let me know, I will upload the Github ASAP on my side!

 

I'm pretty sure that nxrighthere's solution would be a lot better than merely spreading out the computation.
What he's doing is additional steps for improved performance.
I don't see how baking static light sources (while maintaining local recomputation for dynamic sources) would make SEGI any less powerful or make it somehow less useful in some scenarios.

The only thing that modification does it basically calculating stuff for the static parts once instead of every frame.
And since they are by definition not changing at runtime (which is what static means), its basically just a performance optimization.

@nxrighthere
Does this optimization help with memory consumption at all?
Also what about the voxel size, is there a way we can increase that a little? Even the high-res voxels are a little too blocky for some of my scenarios.

Do you combine the saved, static data with the realtime lights and occluders?
Or is this "static gi for far away; realtime gi for close range" ?

I'd like 2x the resolution.
I know that is a lot since we're working with volumes here (so ^3), that'd mean a cubic(!) increase in memory.
So doubling the resolution takes 8x the memory.

 

Fantastic work!

 

OK yes this is a second post. This is primarily to the dev.
I am wondering, while segi may not have any features added, will it still be updated to be able to run reliably in future unity versions?

 

It's an abandonned product , now fully open source , like many other open source stuff, anyone can improve it and sell it, there is no restrictions.

Yep, i don't see some absolute need for it, good post process and lighting settings can be great , what matters is art, level design and gameplay first.

 

I just checked out sonic ether's page. They were viewing this thread in the past day. @sonicether if you see this, I hope you're doing well, and look forward see to whatever you're doing in the future.

 

I'm aware of that. It just feels kind of wrong. I'd rather love to see the current Open Source version to be updated/improved in the long run than seeing a new paid asset. I can quite understand @nxrighthere reason to go this way, but still...

 

Without some funds you won't get people working in it or in the long term. Some open source stuff take up while other just don't take up or very slowly.

I agreeabout people won't pay once again for a work in progress plugin far from finished
It should be available for purchase only when it's considered in a first usable version with good performance enought.
That's ok as a paid plugin considering the amount of work put in it, and it looks it will be different from Segi in many ways for better performance.

 

I get that, but nxrightthere is doing us a favor...sure I paid for SEGI and will for nxrightthere's solution. Why? Because I make games, and realtime GI solution on Unity is virtually non-existent outside of SEGI (There is HXGI but no ETA). Couple hundred bucks to simply venture into the possibility of realtime GI is still very much worth it. Because once the game's blueprints are up and ready for production, couple hundred bucks really doesn't matter. What matters is that the solution is production ready. Having someone like Sonic to begin the work and then nxrightthere and the community to improve it further is just a blessing. I honestly think it would take me minimum of 3 months to develop a case specific SEGI if I did it myself - and that is going to cost me way more than couple hundred bucks...

I think what we should all remember is that Asset Store is not just "end-user's" marketplace. It is a marketplace for devs and that means that products sold and maintained on the store should be seen with a unique perspective. I am not suggesting that we should just be nice all the time, but think of the immense man-power we are saving for our propective projects...

I've seen the author of HXGI hesitating to release his solution because of maintainance/profitability issue. People on Asset Store don't want to pay too much but expecting lasting support. Sonic had to cut the cord for the same reason. And NxRightThere is already hesistant for similar reasons...and we are waging price war against these authors who are providing solutions that literally save us money in the realm of $10k or more (I am just eyeballing 3 months of work with $3k monthly payment). I just don't think it is the right direction to go as a community when it comes to money and author profits - we should openly encourage them to keep at it.

 

Maybe consider setting a bounty amount on you releasing your version as open-source, and we see if we can raise that amount? I haven't thought this idea through much, just throwing it out there.

 

So, this is marked as deprecated now in the unity asset store, and is no longer available?

edit: Oh, this went open source: https://github.com/sonicether/SEGI

Missed that in the thread history.

 

It is available on git as open source now.

 

Meanwhile some not so bad demo for some open source software :

"Lit with emissive objects and voxel gi. 2200 meshes and 7.5 million points in scene. Can get full HD 60fps 8x MSAA on my gtx78ti without SSAO in debug mode"

https://twitter.com/twitter/statuses/932510224623198208

With it's poor performance i am not sure SEGI is the way to go, until someone make some huge modification about how it works.

 

@zenGarden
One limitation that has been pointed out: "the gi is semi realtime. emissive objects must be stationary".

 

Yep this is a specific usage but there is lot of possibilities to use stationnary emissive and i prefer that if performance is so great ( and he said he was extending it to use dynamic lights also ).

Anyway SEGI si too performance heavy compared to that or svogi for example.

 

Right, but this is in Godot Engine, not Unity-ready(?)

 

It's open source, some Unity shader guru could use it as some base to improve on.
Anyway perhaps some good lighting solution will be available for Unity some day.

 

Another nice article

 

This has been posted already (see link below), even on the HXGI thread. Conclusion: not good, because it needs a really long pre-compute pass (up to an hour).
https://forum.unity.com/threads/segi-fully-dynamic-global-illumination.410310/page-35#post-3277538

 

Anyone can make SEGI performance better for large scenes? Performance is really awful on my 960 nvidia card.

 

What is your setup for large scenes? Do you update gi all the time? Are you using a dedicated geommetry for the SEGI pass?

 

For better performance, you'll need a heavy modified Segi version or something different like Svogi.