Graphics HXGI Realtime Dynamic GI

It would mean you'd have to place a script on every game object you want to be voxelized. Also I've written a faster octree culling system that I could use if i wanted to go the route of a culling system. But id rather this was a drop in system. having to add a script to every game object is a little too much to ask IMO. Although it offers the best speed/control.

A method that is simple to intergrate is having a layer/s for static voxelized object and layers for dynamic voxelized objects. but that can be pretty restrictive.

another one is having shaders for static objects and shaders for dynamic voxelized objects so I can use the shader replacement tags to seperate them using unity's inbuilt culling system. But this would make it a lot harder to intergrate with custom shaders.

If i can get the voxelization process to be fast then its not really an issue and voxelizing everything over X frames would be the easiest for users to integrate into their game.

If anyone has any other ideas id love to hear them.

 

Have you considered froxel (frustrum voxel, ie basically a depth map at lower rez)? I don't know, I have just seen media molecule use it, but I know nothing about it. There was also this talk at unite 2017 I have yet to parse or wrap my mind around.

Spoiler: Unite Europe 2017 - Global Illumination on an unprecedented scale

 

In Archviz you allready fake this sky-light behavior with the method of placing illuminating planes in the window. Some RenderEngines recommend to use a kind of "portals" you place into the window space to reduce calculating time. So its a common technique

 

I agree that it's super important that this be easy to add to an existing project. Having to add a script to every object is too much.

I definitely don't think anything that makes integrating it with custom shaders harder is a good idea. That'd be a pain in the ass forever.

I don't particularly like layers. It seems like everything in a project that uses them makes everything else that uses them harder to work with. They'd certainly work in a pinch, though.

Adding scripts to everything wouldn't be so bad if I could set a default that would be added to every other renderer at run time. That way you could set it up to either
- Just re-voxelize everything as if it were dynamic, trading some performance for very easy setup (probably the default setting)
- Voxelize everything as if it were static, and then you have to add a script to your dynamic objects and anything you don't want voxelized at all. (Or the opposite, if it means doing less by hand.)
- Not voxelize anything except the things that you've added a script to, for total control over what gets voxelized and what doesn't

If the performance gains would be very minor it might not be worth the complexity, but in general I feel like even small performance gains can make a big difference in a system like this because they mean a user can push the limits a little farther somewhere else. If (for example) 10% faster voxelization means someone can turn up the max view distance 10%, that will make a difference to somebody.

 

ah yeah, good point. That would not user friendly adding script manually

 

Didn't seen any froxel use in that video. Froxels are generally used for calculating onscreen effects/data. My GI is all calculated independently of the camera. So froxels arn't useful for my use case.

 

No that video and the froxel are two independent idea lol, but they are just on the nose suggestion, not deeply thought out.

So I guess this video was no use either lol.

The mediamolecule video is there, he use voxels and then switch to froxel at 19:20, he use also distance field. He spend time talking about voxel strategy.

Spoiler: Alex Evans at Umbra Ignite 2015: Learning From Failure

In case it gives you idea

 

Thanks for the video, the ambient lighting is pretty similar to what i intend on doing. But ill try to do it in voxel space rather then screen space so you dont get temporal artifacts. Some cool ideas in here.

 

Wow, SEGI's got a contender. This looks great. Any estimate release date, beta, something to play with?

 

Well I'd buy it for sure. Alternatively I'd like to hire you to do a custom version. Unity lighting sucks so much Im always tempted to move to Unreal, so no matter if this costs real money, it should still be cheaper than redoing the game from scratch elsewhere. Im sure Im not the only one with this problem.

 

I would get a copy. even with no support.

 

Me, too.

 

I hope you do sell this Asset even if it's expensive many of us would still buy it.

 

I hope I don't get hit for it, but I created a Google Form. It can be found here:
» https://goo.gl/forms/HyzeVWZvwTMAhErh1

No personal data will be collected. Answers can be found here.

 

This is looking really fantastic. The attention to detail for reflections is really great to see. This is an intstant buy for me as soon as its out (even though I also have segi).

How is this with lots of moving geometry? Ive been working on a procedural(ish) music visualizer that uses GI to light everything- but lots of the stuff is moving.

 

Cascade Voxelization is close to finished. Right now each cascade is twice the scale as the previous. With 4 cascade it increases the view distance by 8x. The different colors in the middle frame shows what cascade it's pulling from.

It needs a little more clean up and then I can move onto adding cascades to the GI calculations. The system will support 1, 2 or 4 cascades.

Moving GI geometry creates ripples of light and shadow depending on your settings. increasing the calculation speed can alleviate that effect. SEGI is more suited for fast moving GI contributing geometry.

 

Random thought: could this be used as a performance friendly solution for medium/large scale ambient occlusion e.g. darkness in occluded outdoor areas canyons, forests etc. (performance friendly meaning having a negligible performance hit by using very slow calculation speed and not caring about moving objects)?

 

Assuming this is similar tech as in CE SVOTI, indirect occlusion should be included already.
@Lexie let me know if i'm wrong

 

Hey, I'm also looking for a runtime lighting solution for procedurally generated levels! Following!

What a Frankenstein with the asset bundle trickery. Both genius and horrible

 

Cascades seem to be coming along nicely. I can't see any sign of a border between them in this screenshot, which is great.

How does faraway stuff lit by emissive surfaces look?

 

It's going to be a while before i can show any results from the cascade GI, The voxelization was just the first step.

Right now I don't have a working solution for skybox contribution, the majority of the occlusion your talking about comes from the shadows skybox lighting would contribute. I have a few ideas on how to solve this but I'm not sure how performance friendly they would be.

 

I got the rendering of the GI data figured out today. on the left is the UVW position used to sample the GI data, Middle is the cascade number. There is some blending of data between the boarders on higher settings.

Hopefully i'll have defuse cascade GI calculating by the end of the week.

 

This is looking really promising, and its great to see such regular updates. I'm an avid SEGI user, but once cascades are wrapped up this looks like it'd be a much more performant solution for any project not requiring fast changes to GI-affecting geo. Skybox contribution would be fab, and if support for forward rendered objects is viable I think you'd have the best contender on the market. The specular / reflections testing looks great so far, though I'd be interested in seeing some shots from a non-static camera. SEGI's reflections are pretty good from static views, but tend to flicker a fair bit when the camera's in motion so I tend not to use them. This wouldn't be an issue for our current project however. How straight forward is it to get custom shaders playing right with this?

Anyways, long way of just chiming in to say, even as a SEGI user, I'd happily still pay good money for this. Moreover, if compatibility with custom shaders is reasonably straightforward, I don't think most people would need to make much use of support either. We all appreciate the awesome work, please keep it up

 

Could you use a demo scene to ship with it? I've got this Dark-Forces level sorta just...hanging around, and it could benefit from not having 2hrs of baking every time I want to change something. http://polycount.com/discussion/151900/starwars-dark-forces-inspired-game-art/p1

 

Above is a distant bright emissive object in sky. It's light comes from the last cascade(yellow) and casts all the way into the first cascade(red). Still got a lot of work to do but it's looking promising!



Here is one with a larger volume to fit the scene.

 

This looks awesome, very impressive, I'm excited to see the next steps! Just wondering, how are realtime shadows going to work with this system? Is the voxel resolution high enough to render them or will you use PCF or something?

 

You would still use unity's directional light if you want a directional light in the scene. If you want any unity light to contribute to the GI then you just place a script on it and it handles the rest.

The light in the below video is a unity light with a script attached to inject the direct lighting into the GI calculation.

 

I suspect this asset + ngss is going to be amazing.

 

This asset + NGSS + HX Volumetric Lighting would be amazing.

 

dude. . . make a public repo already (in case you doesn't want to sell it). Would like to test your system man!!!

 

Is it weird that I check back here like 3 times a day?
In other words, well done man. Your new screenshots look really amazing.

 

Does this supports webgl?

 

I'm not really familiar with WebGL's limitations so I'm not sure. It uses compute shaders and some shader model 4.5 stuff.

 

I wonder if it would be possible to pack all lights under an empty GameObject and placing the script onto that - would that work, too? Imagine having +/-100 lights in your scene and you'd have to place the same script on each of them by hand

 

..If they're all named some variation of "Light" then you can just search for that term, multi-select, and add the component to all of them in one go! ...this also means that the lights can maintain any scene hierarchy that they're already got...

 

Tested this, you're right. Damn... where was my brain when I posted this?

 

One thing to note is that GI contributing unity lights cost extra to process, it would be best to limit it to only the directional light and maybe 1-3 point/spots.

The power of the system comes from using emissive surfaces instead of a unity light to fill your spaces with light.
The cost of 1 emissive surface is the same as 1000s, where as each unity light that you want to contribute costs extra.

If you don't need high detailed shadows on a light source then switching it out for an emissive sphere saves you the cost of rendering a shadow light.

 

Good to know. Thanks for explaining.

 

You're a wizard.

 

Would your GI solution work together with, for example, Next Gen Soft Shadows from @tatoforever ?

 

Yes, absolutely. Though, as Lexie's said repeatedly, you don't want to be injecting too many point lights into the GI solution - placing invisible emissive objects instead is far faster. Luckily you can just use normal lights *without* injection - I suspect that it would look just fine, and if the lights are moving/fast animating, then you also avoid the issues with the voxel volumes propagating too slowly. In all likelihood, your average player won't even notice - especially if the GI is still working strongly on all the more static lights.

 

Cascade support is coming along. I've got the sampling of the cascade data when rendering the GI data to the screen done. The transition between cascades isn't too noticeable, there are some blending ranges you can set. I need to optimize the propagation shaders as they seem to be 3x slower then my old ones. I should be able to get it running close to the same efficiency as the old one even with the added complexity of cascades. Once that's done ill move onto adding unity light support.

I need to add multiple taps when sampling the GI per pixel, That will smooth out shadows and make it less "blocky" looking.

Here is the cascade blending data. Right now the position of all the GI volumes is the center of the full volume. once i make it so each volume can move independently it will let me move the cascdes forward a bit to give better quality GI (red area) a bit more space in front of the camera. Also when moving the camera around there wont be as much of a massive jump in the blend data so it will hide the pop-in you might be seeing in the video.

I have to render out my own shadow maps for the GI injections as unity does not render the full shadow map for a light. For efficency reasons unity only renders the objects that will cast a shadows into the current view frustum.

This means i have to render out my own low res shadow maps for the GI injection step. So yes it will work with custom shadow sampling solutions like NGSS, But for the GI injection it uses my custom shadow maps.

 

Needs 'Love' button...

 

It's looking pretty nice man. The demo video is very promising. What performance are you seeing with this version? Or prefer not to give numbers until you've made those optimisations?
Also, is it making closed off areas nice and dark? Gotta love some caves with glowing things inside!
Many high 5's to you!

 

Ill give some numbers once its optimized. it's too slow right now. Yes, caves will be dark.

 

Now that the GI is calculating for a large distance its possible to inject the skybox lighting into the GI calculations.
Basically the edge of the final GI volume pulls from the skybox cubemap resulting in the below image.

This is probably the cheapest way to simulate skybox contribution. I have other ideas that involve voxel cone tracing that would give better results but they will probably be a bit too expensive.


This looks a lot better then using unity's ambient term. Cant wait to see how good this looks with the directional light added.

 

Is the sky ambient contribution a global term, or is it able to determine when the sky contribution should be blocked? For example going into an enclosed building or cave environment? If it's a global setting, then it would be important to have a way to manually occlude sky contribution when necessary... perhaps by adding your own occlusion primitives or meshes to the scene.

 

All 6 sides of the skybox contribute?

 

The skybox is occluded by geo. The inside of a room with no windows would be black. If it had a window then only light would flood in through the window, same goes for a cave. As long as the Geo that would block the light is with in the volume then the skybox contribution is blocked.

There will be a scale value as well, so if for some reason you wanted to lower the skybox contribution. you could set the value, or turn off the functionality etc.

yes, the skybox I used was fairly flat, but if you had a sunset then red would flood in from 1 side for example.