Fully Dynamic Diffuse Global Illumination

A man needs to cross a lake to see whats on the other side, he knows the lake is notorious for thin Ice... he knows every step he takes could be an eventual dunker, and he wont know it is until he takes that steep... Sometimes he falls through the ice and has to pull himself out and try a different path which could lead him across or to other potential dangers.

Some tell him it's impossible, others tell him it's too dangerous, but the man steps out on the ice anyway...

Will he make it...

It's as if you feel compelled to watch...

 

a man agrees.

 

Exactly, He hasn't taken any of your money or promised anything to you, he's just showing work in progress of something he's developing.

 

They have that, it's called Patreon. And while people are waiting on his support from last month for his other products on their respective threads, there's nothing wrong with "calling the cards" after this long has passed to see what the guy is really holding. If you think that's an insult, then you have led a sheltered life.

 

I've watched every promised dynamic GI "solution" come and go and I'm just as sceptical as every one else, but if anyone's going to get this done, it's sonicether. His existing products are a testament to the quality of his work. Some people need to chill and be grateful this is being worked on at all instead of acting like entitled children.

Keep up the good work sonic, it's looking great!

-- "It's better to create something that others criticise than to create nothing and criticise others."

 

It would be a real shame if this doesn't come out. I'd be willing to buy it right now despite it's known bugs. For my project (levels generated at runtime) GI with bugs >>> Unity's standard lighting without precomputed GI. As long as you properly disclose the bugs and limitations there shouldn't be a problem.

 

Yea +1 to that Misciagno.

Unless I'm misunderstanding just what state this asset is in, I'd pony up to have an 'early access' simply from what I've seen and read.

 

The thing is, a GI system isn't that simple. I'm not familiar at all with Sonic Ether's project, but I'm very familiar with all the techniques behind it. I would be willing to wager money that there are severe edge cases which prevent it from being useful at all in the current state. Anything from unacceptable light leaking to no support for transparent objects to artifacts. People with no experience of graphics development tend to underestimate the insane number of edge cases that can completely ruin a technology, unless it is in a controlled environment designed around all the edge cases. It's the reason I've shelved the 2 different GI system I've worked on, a general case solution that's usable without developer help is very hard to accomplish.
I'm curious how @sonicether deals with long draw distances, as that is generally the massive negative of voxel based solutions. IIRC you are experimenting with cascaded voxel volumes, but does that extend all the way up to 1000 meter draw distances or is it limited to a couple hundred? You can always trade resolution for further distances, but indoors that could cause leaking. Either way, keep up the good work. I'm curious to see what comes of it.

 

Yup, it's not extremely difficult to make your own based up your own specific requirements and acceptance limits, but trying to make a general system that works well across multiple types of hardware and is seamless / generically useable with little intervention is pretty much impossible.

Not trying to put Sonic Ether off or anything, but if Nvidia, CryTek, Epic, DICE and even to some extent Geomerics can't figure it out with teams containing some of the best lighting / rendering engineers this planet has to offer. Then I'm not particularly surprised.

The best implementations in a real time sense I've tried / seen so for has to be variations of voxel cone tracing, requires little in the way of artist intervention, looks great (especially Nvidia's VXGI in Unreal). But performance is pretty poor for decent results..

Anyone tried CryEngine's new implementation? AFAIK it's only diffuse based voxel GI with lightprobes required for specular.

 

I just know that, if we do not stop to spam the thread with questions we are going to see another GI thread locked just like SpectraGI and BG Light Engine. This is just a very hard task for a single person even though he seems to be professional. Yet groups of professionals are not able to find a good solution for a robust and fast GI solution. There are just a couple of High End engines which support real time GI. Even Epic haven't yet such system implemented suitable for all kind of projects. There is some more time to pass until some, well serving systems are starting to show. Just wait until Sonic has something to show. There is no point to rush.

 

As long as the @hippocoder is fed with polite on topic discussion and fancy screenshots there's no risk for locking

 

^ he knows how to herd me, he just shows me some renders and I wander off there, eyes filled with promises and broken dreams.

 

Epic has VXGI, unofficially implemented by NVIDIA (it's still WIP, though). Example Video here.
And Sonic showed much work recently, which all of it looked good already. I think his main issue is being perfectionistic like he said earlier. (Something most of us suffer from it, too). That's maybe also the reason why the hinted Beta is delayed.

 

I think Mauri and I are of the same mind here...

...between Sonic's images here, and moreso on his Twitter page (not to mention his Minecraft implementation), his solution seems quite ready, even if there are minor issues that can be addressed through iteration/updates.

 

First, development news.

I have created a workaround for the compatibility issue for Unity 5.1 and higher!

In Unity 5.1 and higher, mipmapping 3D textures isn't possible. So, instead of relying on native mipmapping, the workaround basically manually builds mipmaps and stores each level in a separate texture. The good thing is that this completely circumvents that compatibility issue; I've been testing the effect in Unity 5.2.3f1 and everything is fully functioning. Also, manually building mipmaps via a compute shader seems to be faster (by about 1.5 ms on my 980 TI) than building them natively. The downside is that, since traversal of voxel data is made more complicated (because each mip level is in a separate texture), tracing through the data is more expensive. With the same tracing settings as before, I saw between around 1.25x and 2x slowdown during tracing. Also, there are some radial banding artifacts because we don't get free quadrilinear filtering anymore (noticeable in the images below). The bright side is that once Unity provides a way to write to a specific mip level of a 3D texture, this workaround won't be needed anymore. That'll mean that we get the speedup for building mipmaps manually, but not the tracing slowdown because everything will be stored in one texture.

Another bit of good news! I've developed a way to almost completely eliminate the biggest cause of light leaking!

Before this fix, if a plane were illuminated, it would both scatter light in front of it and behind it, since there was no directionality stored in the voxel data, only color luminance.If a wall had two sides, the back side helped with this since it would block some light, but it only helped a bit. This problem compounded with infinite bounces enabled. With this fix, this problem is almost completely eliminated!

Here, the camera is inside a cube that is on a plane with two faces illuminated by a directional light. Here's a worst-case demonstration of the "backward light leaking".


And this is with the fix applied.


There's still a tiny bit of light leaking, but with a small tweak in the math, this can be reduced even more.


This works for any arbitrary orientation of a surface. Sweet!


This, of course, comes at a performance cost if I were to keep the same voxel resolution of 256x256x256. Reducing the voxel resolution to 128x128x128 makes up for this extra cost. I suspect that outdoor scenes wont' need this fix as much, though it may be crucial for indoor and semi-indoor scenes.

The compatibility workaround mentioned above makes the extra cost of this fix higher than it would be without the workaround. So, again, the future is looking really great once that fix comes around!



Okay, now I'd like to say a few things on what everyone has been saying. Honestly, it really encourages me to hear you guys say that you'd like to see a beta version on the Asset Store, even with the shortcomings that are still there. I've been afraid of doing that too soon and having people get discouraged with the project when they see the problems that are still there, but as long as you guys are understanding that this is an unfinished and ongoing project and there is a lot of improvement to be made, I'd feel pretty comfortable with that. Honestly, the last problem that I'm worried about as far as putting this on the Asset Store is the problem I mentioned with moving objects regarding temporal sampling (you'll see streaks on objects moving in world space). The proposed solution of building a velocity buffer seems like the best bet, and this buffer can be used for motion blur or temporal anti-aliasing.

I like this idea. As long as I clearly state the known issues and provide a roadmap for people to see what milestones I'm working towards, I think it'll work. Having beta testers will greatly help me with development as well.

And to clarify on what I've said previously, at this point I agree that it'd be a real shame if this didn't make it on the Asset Store at all. What I meant by the project "seeing completion" is that it is yet unknown whether this will mature to be a good solution in a wide variety of games/scenarios that a wide variety of hardware can handle. That's certainly my goal!

In any case, I'll start working on the front-end and start preparation for Asset Store submission. If you guys want to start using it, and I need the help with testing, I see no reason I should wait longer. I've tried to be honest and open, and I appreciate you guys doing the same with me, whether that's in the form of positive or negative feedback.

 

See that's just the thing isn't it.

Even people who are skeptical, or just plain impatient (or in my own person case, due to an impending deadline that cannot be changed, simply pressured), undoubtedly would be willing to give such a beta release a huge amount of latitude before considering complaining about the end quality.

Just throw it up on the asset store, slap a "beta" tag on it and any reasonable person on here will know what that means.

 

Great, that is the best solution, i dont think that anyone expects true GI to play on mobile anyway, the stronger PC requirement is a given and if a game wants to use such tech in the first place wont be shooting for lower end systems, but the higher end ones.

I think this is what the other engines wait for as well to use GI in a more wide way, stronger hardware that can support it. It is great that we will be able to test and deploy the true GI right away and see which cases it will make sense to be used in our games and be ready with the setup beforehand as well, than put it in the last minute as target PCs power shifts.

 

Nasos_333 if this GI works in real time for PC, we can use it on Mobile when we start the level .
It will be amazing.

 

I can think of a million uses as well, i will be using it depending on the case myself, based on scene extend and load.

 

Really appreciate for being transparent about your bold GI project. Can't wait to give you my support and purchase the beta/WIP version when it hits the Asset Store.

 

We just want to entrap you so you will be obliged to commit to the product. Hehehehe.

 

Great news about an asset store release!

I'm a big fan of dynamic scenes as I like to enable players to be content creators, so baked lighting is pretty much out of the question. Believe me when I say that this project, in whatever state it's in with any current shortcomings, is still infinitely better than any alternatives for me. I'd be willing to purchase this asset right now for that reason alone - being able to help support the future of this project is a nice bonus, too.

 

Since velocity buffers + temporal sampling go hand-in-hand with temporal anti-aliasing, I figured I'd mention here that I'm also working on temporal anti-aliasing. Temporal anti-aliasing has a cost of its own, but the costs can be shared with GI to completely fix the temporal sampling artifacts. I'll keep you guys updated on how that's going.

 

Kinda thought about it a few message back, if you're going to have velocity buffer better use it for TAA, (and motion blur, but well nobody likes motion blur)

 

I like motion blur!
(guess I'm nobody then...)

--IronDuke

 

I was hoping that Unity would actually implement a velocity buffer, so all filters can share, since it seems very likely that everyone will implement their own version and we'll have each post filter doing (almost) the same calculations again.

 

Yup nobody right here like's MBlur as well!

 

Sorry, correct me if I'm wrong here. But the last time I had a look into it there was a hefty overhead due to generating the velocity buffer in a vertex shader. Someone else mentioned it as well, I couldn't find an efficient way to do it screen space, the post was affecting the number of DC's quite dramatically.

As @AcidArrow says, it would be better if they could share a VB.

Although NVIDIA generated a proper motion blur post effect in screenspace using UNITY_MATRIX_PREV_M (which ain't in the Unity docs) for the previous model Matrix and something else for skinned objects..

I'll have a look and if I find anything, I'll mention it.. Might save you some time.

 

@sonicether: I have PM-ed you. Please feel free to read at your convenience!

Thank you always!
- S.

 

^That or just ask @Aras at that point.

But from what I know unity planned to add something like UNITY_MATRIX_PREV_M but last time I checked there was no ETA on that.

The thing with doing that in vertex shader is that you'll probably have to modify the unity standard shaders and you probably don't want to do that.

Amplify motion is doing that but it only register to write to the velocity buffer the object that have a specific script. Might be too heavy to do that to all the object on the scene. But maybe you can just select a few "best contributors" depending of the view occlusion, or try to sample it across multiple frames but that might creat gosthing-y effects if you move the view too fast. (which is already a pb with TXAA I think)


@IronDuke & @SteveB awwwwww but you're my nobodies

 

My characters are excited to see how your GI works in my game! Hope I can try it out soon! Looking great as always.

 

@sonicether,
here an Anxious buyer

 

You've been banned before. There's constructive criticism and there's borderline harassment.

Edited to remove several over the top comments I made.

 

Perhaps there is no need ?

As you can read this is non serious talk , he is making a game with a deadline that don't have real time GI and he would use real time GI with a non prooven and debugged plugin in a non commercial game?
I think all offensive talk was to avoid expressing himself in the simple way :
"Give me real time GI, i beg you please, i cannot make any game without it , this will make my game so much better, i cannot live without real time GI "

And i had also lot of doubts about Sonicether on the subject, i never take seriously WIPs without any demo and i still have heavy doubts until i see a real plugin or demo (but i still don't need and won't use real time GI).

 

Actually, this would be a great christmas gift

 

Release a demo

 

Please, don't make me beg...

 

I'm already begging XD
Please!!! D:

 

I figured I'd let you guys know how it's going. The whole project was an organized mess, so I spent a lot of time cleaning everything up and removing unnecessary vestiges of code. A fair amount of time was spent ensuring proper functionality with each of the adjustable parameters. As of now, I'm working on the UI, and I'll be moving on to putting together documentation very soon. Then, of course, I need to get screenshots, videos, demos, and performance data for the Asset Store page itself. Then I'll put together a development roadmap and list of known issues. That's what's ahead of me to put this on the Asset Store. So, there's still quite a bit to do, but it should be done soon. I'll update you guys as I go.

 

This is all rather exciting Sonic, and I and everyone here I'm sure loves the update!

 

@sonicether
Hey I figured since all the source code will be available in the asset anyway, why not putting everything on a private Github repo and grant access to the buyers (UE4 style)...

I'm pretty sure there would be plenty of CG enthusiasts (including myself) that would be happy to contribute to the project for free... just sayin

 

@sonicether
Also I dunno if thats new but Graphics.SetRenderTarget() already allows to specify the mip level to render into...
http://docs.unity3d.com/ScriptReference/Graphics.SetRenderTarget.html

 

Do you have any approximate price range in mind yet? I understand that it may still be too early to decide, but I figured I'd ask as I'd like to put aside some money for this asset when it's released.

 

I may consider that in the future. For now I prefer being the sole developer.

Yep, that's been around for a while. It's for writing to 2D textures. Graphics.SetRenderTarget doesn't work with 3D textures.

Right now I'm considering $80 for the beta version, and $100 when it comes out of beta. It'll include the simple non-voxel sunlight-only version (for situations where such a robust GI solution isn't necessary) and the voxel-based version.


Some screenshots for good measure. Note the "soft sunlight", a feature I haven't talked about yet but will be included in the first beta version.

 

Sounds good! People might want to see a before and after screenshot of a sample scene and the relevant profiler stats (also before and after to see the performance impact) before purchase, just so they have a rough idea on the bang/buck ratio in terms of quality vs performance. It would be great if you could provide something like that! Looking forward to try it.

 

I agree. I plan on providing something like that so people get a good idea of how it performs. I don't want anyone buying it expecting it not to take a chunk of their rendering budget.

 

Awesome, thanks! Also I have to say the screenshots you edited in look amazing! I would have thought they were rendered with something like blender's cycles render engine if I had seen them out of context. Fantastic work!

 

Does the GI plugin accept with Unity PBR shaders or does it uses it's own PBR shaders ?

Is a Web player planet on Asset Store to be able to really see how it goes on everyone own computer ?

Like many plugins on the Asset Store , a Webplayer is the best as you can test it directly on your computer and see how it runs and if it can be used on your game project. and it would need a more complex scene like a large terrain with trees and some houses and characters , i'm curious how it should GI behave in such game ?

 

My GI uses the deferred buffers (albedo, normal, specular data) to render indirect light on top of the scene. Any deferred-compatible shaders will work. Forward-rendered objects present a challenge currently that I haven't solved yet.

Yes, there will be multiple web player demos linked on the Asset Store page so people can check it out in a variety of scenes. I'm working on that right now. For now, the GI can't handle significantly large scenes very well because I haven't implemented cascades/clipmaps yet. That's on the development roadmap and will be coming in the future.

I'll probably post a web player demo here soon before this hits the Asset Store.

 

So we can't use Unity standard shader (rought and metallic instead of gloss specular) ?

That's good.