Fully Dynamic Diffuse Global Illumination

@Haagndaaz I desire it, at least.

 

Also, for lightbaking a room 100x100 with walls and furniture inside, at runtime, I got it down to about 5 seconds for bake time

 

Cool, I'll add that to my list of things to get done, and then I'll release it for free as a package

 

If you start your own thread on your implementation, I'm sure you'll get a lot of spillover followers/customers from folks here.

EDIT: Oops, replied at the same time. Great! Looking forward to seeing it. This and SE's fully dynamic GI are both very exciting developments for procedurally-generated scenes at runtime.

 

Ideally, I'd like to set up the system for runtime baking, then anyone else (SE) can take it and modify it to match their lighting calculations

 

Perhaps you could help @sonicether for people interest on a baking possibility for the plugin (very usefull for old PC hardware and mobile).

 

+1 here for baking. I'd say 95% of my work requires realtime GI, but I'd love to have the option to quickly generate lightmaps for mobile and not have to either wait for Enlighten to bake or lose my maps on loading...

 

That's the idea @zenGarden, I'll get it set up again (previous version was made at work) and then SonicEther can either use it and adapt it or not

 

Perhaps. I actually wanted to talk about this issue (light leaking) in-depth.

The whole premise of voxel cone tracing is that for each traced "ray", instead of simply sampling a point of information, you get to sample an area of combined information. This keeps rays tracing in different directions more coherent and you get to trace a lot fewer to get a smooth result. To put it simply, cone tracing samples blurred data. This ugly diagram I whipped up attempts to show what I mean.


Now, what happens when I put a one-voxel-wide occluder in front of that light data?


As you can see, with naive "brute-force" sampling, each ray encounters full black before it reaches the illuminated voxels, so none of that light gets through. With cone tracing, however, data is blurred in all directions which smears the occluder and the light information such that rays do not encounter full opaque black before reaching the illuminated voxels.

You might be thinking, "Just don't blur the data as much!" The less "blurred" the data is, the more steps-per-ray and more rays there needs to be for a smooth coherent result, which obviously increases the cost of tracing drastically.

One way to combat this problem is to increase occlusion strength. The downside to this is that increasing occlusion strength causes over-occlusion, which in some cases can be just as bad for image quality as light leaking. Having directional voxel data will decrease the over-occlusion caused by increasing occlusion strength, so perhaps there's a sweet-spot to be had once that's implemented. Again, I have to wait for 3D texture mipmap support in Unity.

Oops, yeah, I forgot to enable reflections in the Ultra preset for the demo!

Technically, the only thing that has to be done twice for VR is the final cone tracing and reflection tracing. If I improve my experimental test of computing GI result in another voxel texture instead of for each pixel in screen-space, the additional cost of having to render two views for each eye will be almost none. Furthermore, perhaps some fancy tricks can be done once the GI result from one eye is done rendering (re-project and reuse data from the first eye and only calculate missing data in the second eye).

I haven't explored solutions for forward shaders, vegetation, or semi-transparent objects yet. Certainly that's on the roadmap, but the core GI system needs work before I move on to things like that. I'm not saying those things aren't important, but if the GI looks and runs like crap, having those things supported isn't going to make a difference.

The problems with changing views, the problem you showed in the screenshots, and problems caused by moving objects can be solved by disabling temporal sampling. The temporal sampling itself will hopefully become more robust in the future to minimize those problems, but you have the choice whether or not you want to use it as an optimization technique, depending on how it suits your scene/game.

Any shaders that correctly use/write to the deferred gbuffers are compatible right now(I know Alloy does). Compatibility will be expanded in the future, of course.

As I've stated before, one of the things on the roadmap is implementing cascades. This will allow for using GI in large outdoor scenes.

IES lights aren't really relevant to this project, other than regarding supporting bounced light from an IES lights system. Right now point and spot lights don't contribute to GI, there's a lot of complicated stuff I need to do to get that working, but again, it's planned for the future.

 

I think I blew my eyes out feasting on that gorgeousness...

I have a few questions:
1. It seems the camera rotation speed slows with framerate. Maybe the code for rotating the camera is in Update instead of FixedUpdate? Might need a look.
2. When you say large outdoor scenes... what comes to my mind is the scenes in the space sim I'm working on. 1:1 scale and everything. Will it work there? (I think I can fake GI using Unity's normal lights beyond about 1000km, but I don't know for sure as I haven't tried your stuff yet.)
3. More of a suggestion, actually. Could you enable a night-time mode, and give the braziers hanging around little fires? With the flames being emissive materials, not using Unity's normal lights? I want to see how that would work.

Keep up the magic, man!

--IronDuke

 

@sonicether hi sonic ether. Quick question. My voxel based game uses geometry shaders to generate the geometry. I don't have standard meshes. Will your GI be compatible?

I'm hoping so...

 

YAAAAS! Look forward to it.

@sonicether: with your GI... how much will it be on asset store? And dat GI, speaking of which.

 

@sonicether Thanks for the explanations and your nice sketches
I don't know much about cone tracing but couldn't you control the blurring according to the occluder ?

 

The new sponza demo run great on my machine (nvidia gtx 750 ti + i7 ) !!! Excelent job Sonic !

 

where is the link for the demo please

 

Cool man, the guys who created Unity GI should be shameful! you did a big favor to unity
I have 1 question

Can I change "Infinite bounces" intensity as much as I need? cause my camera had a heavy contrast effect and I need more Infinite bounces

 

So 'Infinity+1'?

 

I need more

 

1. Oops, yeah, the rotation code is in Update instead of FixedUpdate.
2. I'm not sure. It depends on the scale of objects relative to the distances between them. If distant objects appear small on-screen, it should be acceptable that GI doesn't "kick in" until you get closer. If you've got some very large very distant objects mixed with small close objects, that might be a challenge, not to mention all the wasted memory of voxelizing such a sparse scene. Cascades might be enough to handle your scenes.
3. Yeah, that might be cool!

That might have to be something that I'll need your help getting to work. Send me a PM if you've got the time.

$80 for the beta version, and $100 when it comes out of beta. I haven't settled 100% on those numbers, however.

You can adjust the intensity of secondary bounces, yes. So increase the intensity over 1.0 to get a more "infinite bouncy" look. You have to be careful, though. Sometimes values over 1 will cause a positive feedback loop and cause GI to exponentially get brighter and brighter (and I mean SUPER bright) if you've got complex areas with high albedo.

 

Would pre voxelization option be possible ? Would that mean real time GI would run faster ?

 

Dependent on scale of objects relative to distance between them? Should work perfectly then. If something is barely ten pixels wide it makes sense that GI wouldn't show; whereas, with the Juggernaut I'm planning, since it's >10km, it would need GI at pretty big distances. Same for planet surfaces and death star type things. But they would be BIG so distance wouldn't matter, as you said.
Sounds like that'll all work perfectly! (Of course, I won't know for sure until I try it.)
I guess it's kinda like how light bloom always works no matter how big the scene is? Cause I think I saw somewhere you said this was an image effect thingy applied to the camera.

Also, I forgot to ask. How are you doing the auto-exposure thing? It is seriously cool, but I don't know how I would do that.
Also is the light bloom in the demo your custom solution, or Unity's normal bloom?

--IronDuke

 

Are you implying having pre-voxelized objects and then injecting those already voxelized objects into the voxel volume? I'm not sure, it might be. I would have to decouple voxelization and lighting injection, as I mentioned before. That will definitely increase the memory requirement since more data would have to be handled.

The auto-exposure is using Unity's Tonemapping image effect set to "Auto Reinhard", although I've changed the shader to not use the luminance reinhard operator (I'm not a big fan of that) and instead use an operator more similar to Photographic.

The bloom is a slightly modified version of my asset SE Natural Bloom & Dirty Lens. I'd love to update that asset with more features, but I'm just too busy working on GI at the moment.

It's pretty cool, though, you don't have to pile on the post process effects for a nice high-quality result when you've got good lighting. Just a bit of bloom and some tonemapping, along with the GI, is all you really need; maybe some color grading if you're going for a filmic look. Maybe I'm wrong in speculating this, but a lot of the fancy and unnecessary post-process effects are like, "Oh, it doesn't look good... uh... more post effects!" If I were designing a game, I'd much rather sacrifice some of those more fanciful effects in order to make room for GI in terms of performance cost, and if I had to choose between SSAO + Motion Blur + SSR + DOF + Fancy Lens Effects or real-time GI (with reflections), I'd choose the GI.

 

How is doing CryEngine an SVOGI ? It is not pre baked voxelisation ?

 

@sonicether could you supply a link to download Sponza scene without your GI please?

 

If you're wanting to download the crytek sponza model itself, check out this link: http://graphics.cs.williams.edu/data/meshes.xml

If you just want to see the scene with my GI disabled, press G in the demo.

 

Another incredibly, incredibly ridiculously good-looking demo that just makes the wound of "still not having access" deeper and worse.

 

I think you should be more optimistic and say this:
Another incredibly, incredibly ridiculously good-looking demo that balms the wound of "still not having access" by the knowledge that one day, quite soon, this will be MINE.

--IronDuke

 

Shall we try to let Unity people aware on that critical missing feature ? Somebody like @Aras maybe ?

I mean, it will definitely be profitable for them if such lighting mode would become available for Unity right ?

 

LOL!! Trust me he knows, they all know of this.

If unity had released this feature themselves then you wouldn't of heard the end of "why does this GI affect my performance so badly, I expect more from you Unity, I mean crytek doesn't perform so poorly, so why does yours.. why why why why why why"

This is a beautiful GI, but it comes with a big performance hit.. You have to understand that a lot of your users wont be able to run this.

I have a GTX 970.
1080
GI OFF = 258 fps
GI ON = 88 fps

But still I think it's a great option to have for those that do have the power to run it.
it's pretty amazing what he's pulled off here.

 

Thanks for the link. I wanted to bake that scene with unity's realtime GI but it crashed lol
I dont' know why...

 

You don't have to use maximum quality settings, for some small games or procedural generated with a short view range, quality settings 1 should run on older hardware perhaps ?
Cryteck are experimented in real time GI since years, Unity would need to hire Cryteck engineers to get something good.

Whatever you choose Unity baked lightmapping or this real time GI plugin, you can still work on your game.

 

Unity lightmapping isn't possible in our game because it's entirely dynamic. There are no possible GI solutions (with unity) which is why i've been watching SEGI for over a year since he first announced it.
http://store.steampowered.com/app/422940

 

Forgot to post my stats.
1440p.
gtx 970.

Without moving from the starting position:
1 - 74fps
2 - 53fps
3 - 37fps
4 - 30fps

 

Will you keep real time GI as some game option ? Or will your game ask a minimum configuration to run real time GI ?
If i had a game complete like yours and i wanted fast real time GI i would have tried CryEngine. Well about SonicEther plugin you will have to wait some more time.

 

NVIDIA GeForce GTX 980

At starting position and rotation.

@2560x1440 (1440p)

1. 83 fps
   
2. 62 fps
   
3. 42 fps
   
4. 34 fps

@1920 x 1080 (1080p)

1. 118 fps
   
2. 92 fps
   
3. 58 fps
   
4. 52 fps

Presets 1 and 2 absolutely playable at either resolution. Settings 3 and 4 playable at 1080p.

Be well.
- S.

 

If you optimise it, it will be running as smooth as butter looks soo nice. Does the cryengine use a similar method ??

 

Thank you for answer!
Of course you right! It's jast a curiosity, because I remember, that you say you have issues with forward shaders.

 

It'll be a togglable option but the game is already extremely (graphically) optimized to "make room" for SEGI, so it'll be on by default.
I profile in MS and not FPS for professional reasons, but sponza scenes and tiny demos give virtually no indication whatsoever how well SEGI will perform in our actual game, or anyone elses for that matter.
Sonic Ether is in no way obligated or required to beta-test his system before he releases it on real-life games and in no way do we feel entitled to partake in anything. We simply wish he would.

My concern is based in reality, and that reality is that we first heard about SEGI at the end of 2014 when Unity 5 was "something that was coming out", and my concern about "it's taking a long time" is 100% because Unity, not him:

We can't stand Unity 5.3 and have no plans to upgrade to any version of Unity post 5.2.2 (5.3, 5.4, or any others) until the new versions start to do things that improve games, such as actually addressing the fact that to this day Speedtree is only 40% implemented. My concern is that since it's taken this long, that the likelyhood keeps getting higher that when he does finally release it, it'll "requires unity 5.3 or later" and there will have been no point in waiting all this time in the first place.

It would be nice if it were confirmed to be 5.2 capable, but everything he's been writing these last several months enforces our fears that he's literally "waiting on new stuff from Unity", which will mean "5.6 or whatever only".

Any before any purists say "just upgrade to the latest unity", please don't. Yes, I'm sure the process is quite easy in the size of game Unity is known for (smaller), but for this project it's a huge undertaking and time is money that i'm sure anyone who follows the game knows we need to be devoting to real game features.

 

@DivergenceOnline Congratulations on your game. could you explain in detail for me what is missing from speedtree?

 

I don't think thats a purist thing. There are indeed many sensible reasons why a particular project may need to stick with a particular version of Unity.

Where I consider there to be a slight contradiction is that when you decide you have to stick with a particular version, that also tends to include a general acceptance that you'll inevitably miss out on some 'shiny new things' - and thats true not just of things built into new Unity versions, but also some third party stuff. And assets that do something interesting in regards to lighting, GI etc are somewhat inevitably going to end up on that list at times.

The question of what counts as 'new versions start to do things that improve games' is also deeply connected to the requirements of a particular project. Its perfectly reasonable for you to have reasons not to be impressed with what has come after 5.2.2 so far, but peoples mileage varies. For example there are things in 5.3 and 5.4 (e.g. instancing, including hopefully speedier instancing) that are very useful to me, but I don't make the mistake of thinking that this is a universal truth that I will incorrectly try to foist on everyone else.

I really like the looks of this GI. But it is hard for me to place my hopes on assets that do so much clever stuff but are made and supported by extremely small teams or a single individual, really becoming a viable solution for the long run. Let alone the fact that most GI attempts don't get beyond the experimental stage, often due to practical limitations that reduce the number of scenarios the solution really works for. I hope to be wrong in this case but I've no particular reason to be optimistic and thats not supposed to be any reflection on the author of this great stuff.

 

I think it will work for many usage cases.

There is other plugins supported from years in Unity, if you have a game right now where the GI plugin would feet well, than buy it and make your game.

 

I'm guessing something like this:

 

Sounds good for Sonic then.

 

Can't see the first beta version on asset store! I think it's good enough already as the first beta version

 

Essentially I'm writing to 3D render textures with enableRandomWrite = true (in pixel and compute shaders). In Unity 5.0 I was able to set generateMips = true and have mipmaps be generated for those 3D textures, which can't be done anymore last I checked. Ideally, though, I'd like to be able to write to a specific mip level of a 3D texture in a compute shader (for custom/gaussian filtering of mip levels). I spoke with someone at Unity about it and they said that adding the functionality of being able to bind a specific mip level of a 3D texture as a render or random write target would be possible.

Right now I've resorted to storing each mip level as a separate texture, which is limiting because of the need to lookup many textures instead of one when tracing (which is more expensive), as well as the loss of hardware filtering between mip levels.

If 3D render textures can indeed have mipmaps be generated in Unity 5.4, that'll definitely help, but ideally I'd like to generate the mips myself. I'll grab Unity 5.4 and check it out.

 

The fact that your demos already have SEGI in them proves that it works with current versions of Unity. Regardless of what performance optimizations you deem absolutely essential (and again, nobody is saying you don't have the right to do so), there will be those such as myself who don't care about the concept of dropping from 130 to a mere 100fps in their game with a "totally unoptimized" version such as the one you're using in your demos, and thus I'm requesting to know if you will make a version available to 5.2.2 users.

Thanks.

 

Although what you have seen in the demos looks good and might run ok on your machine. the distance at which it works is really small. you said your game was a large game. for GI to work with the method this plugin uses, it needs mipmap support to run on anything larger then the size of the test scenes we have seen so far.

Its hard enough making a plugin that has multiple branches for supporting different version as is. don't hold your breath. If you want the latest tech, then upgrade your version of unity. I have updated my game that is a large game through every version of unity since 3. im sure you can handle it consider nothing has become deprecated from 5.2.2 to 5.4.