Graphics HXGI Realtime Dynamic GI

@Lexie just curious, for your next video could you add a character or at least a dynamic object as a camera child. Would like to see the GI contribution to dynamic object

 

Here is a video of the last version with a dynamic none GI contributing object. This object does not get voxelized but gets lit by all the GI in the scene. If you have fast moving objects like a player. it is recommended not to voxelize them. The light fall off was a little low in this video. With out GI he/it would be 100% black (except for his emissive surfaces)

 

Yep this is what i mean, sorry if my previous post are unclear. Dynamic object GI receiver. so we can totally replace lightprobes?

 

There is no need to place light probes. The lighting data is already stored in a giant voxel grid. each frament looks up the lighting data at its location to calculate the defuse lighting on it.

Edit: read your comment wrong. yes this completely replaces light probes

One of the big issues with enlighten is that dynamic objects are lit by a single interpolated light probe. this can make large dynamic objects look extremely out of place. The way my system works is each fragment (pixel) samples the GI data independently. this means large dynamic objects will be lit correctly.

 

Yes that is my main reason to ditch lightprobe atm, also they totally break batching apparently.

 

In Unity 5.4+ there is LPPV to fix that (light probes proxy volume - up to 32x32x32 grid around dynamic/LOD objects, that sample surrounding lightprobes (not directly lightmap data itself, unfortunately - tons of manually placed lightprobes needed to really make a difference on large objects lighting and a lot of performance wasted to update them in realtime)). In small amounts they working good and Enlighten become slightly less awful to work with, in large amount they become a bottleneck (CPU overload).

 

Wow that looks so promissing! @Lexie did you already try animated objects with your Voxel Gi solution? I have the problem with SEGI that moving objects are flickering...

 

Jeez unless I'm missing something, this looks ready?!

• Gorgeous GI
• Performant
• Cascades
• Skylight Contribution
• Single-Pass Stereo Rendering

...am I missing something?

 

Flickering or pulsing? i think i'm getting "mild" pulsing lighting when using LPPV also

Let's be patient, he did said on the last update of the sky occlusion that it's not performant

 

No of course but considering that I'm working with SEGI, this is clearly far and away further along so...

 

Yep. too expensive if you have more then a few large dynamic objects.

There are artifacts when voxelized objects move. it looks like ripples of light and shadow.

 

@Lexie - I'm curious about how the voxelization works in a dynamic environment. Do you group what should be voxelized by using layers?

Also, let's say you want something to look static till you move it. Like ten cars are parked on a shiny show room floor, but then the player decides to enter a car and drive off. You can have each car adding to voxelization while it is parked, but when it is going to move, switch the voxelization off on just that one car?

Or if you have a box, crate, whatever, and it is an inert object till it explodes. It could be part of voxelization till detonation, when that object disappears and is replaced with unvoxelized flying fragments?

Will this look okay, switching an object from voxelized to non-voxelized mode, or must objects that might move (doors, etc.) always be subtracted from voxelization?

 

I've optimize the propagation shaders to be close to the same speed as my none cascade version. I've also added in the functionality to set how many frames to voxelize the world over and how many frames it takes to advance the light propagation. if your game is mostly static then lowering theses can make the effect extremely cheap to calculate.

I've also made it that each cascade can move independently. this means there is a lot less popping when moving around, this also gives me the ability to push the cascades foward a bit giving the closer cascades a lot more coverage. The last cascade does not get pushed forward as it would create too much light popping when you do a quick 180.

I'm moving onto adding unity light support now.


(left side: forward offset set to 0. Right side: forward offset set to 0.8 giving a lot more range to red green and blue cascades)

 

The system uses unity's layer masks to determine what gets voxelized. You can do any combination of the examples you gave above but I'm not sure how good it would look switching a large object from being voxelized to not being voxelized, might look fine. The system can handle slow moving voxelized objects like a door. But things like a car that move pretty fast are best to not voxelize while moving at those speeds. Im sure some SSAO would ground the car in the scene pretty well even if its not voxelized.

 

Just a quick question - I assume that the plan is to just use skybox lighting beyond the last cascade so objects are not completely black? Also, what is the total distance all the cascades cover? Looks sick tho, hope you decide to throw it on the asset store!

 

it will fallback to unity's ambient term, its on the list of things to add. The total cascade coverage depends on how many cascades you use, the volume resolution and the starting voxel scale.
Right now it supports up to 4 cascades. So if you had a volume resolution of 128x64x128 at a starting scale of 0.25 it would give you 256m across(128m in front of you) changing the starting voxel scale to 0.5 would double that to 512m (256m in front of you)

Ill probably expand it to support more then 4, 6 would give a pretty large view distance while still having good detail up close.

 

Does the use of the forward offsets system imply the game must have the concept of a 'world up' ? If so, can the 'world up' change?

My project doesn't define a world orientation as easily as a typical landscape kind of game and wondering of this means I wouldn't be able to take advantage of that optimisation.

 

Forward on the cameras forward axis. what ever direction the camera is facing it offsets that way.

 

Yeah:
- real time progressive lightmaping (ie bake real time only what's necessary)
- baked voxelization to stream around, potentially reconstructed by code (to assemble modular piece)
- voxel lighting data for baked voxelization, to allow quick switching of lighting condition (maybe noot compatible wit modular reconstruction)

All your procedural base are belong to us

 

probably not
maybe
If you mean bake out the GI 3D lighting volume then probably not, would take up way too much space.

 

How much is too much?

 

192MB for a single 256x256x256 volume.

Edit: you probably don't need that height, so maybe a 256x64x256, so 46MB. I might be able to compress the data down after its been calculated to 23mb... might be feasible. Thats just for the lighting data. If you want the voxel traced reflections then it would be around 39mb for all the data. not too big, but if you want to bake it at a resolution of 0.25 units per voxel, it only gives you a bounds of 64x16x64 units. So you would need a lot of these volumes for a level.

 

I didn't expect it to be practicable for an entire level, but think about key moment, especially cinematic or setpieces happening from a single place or POV, being able to shift lighting in an instant by essentially "rebooting" without the artifact or have momentarily "hi quality lighting", can help achieve the illusion of great quality and bleed to the overall game perception. Like having a hi poly model that show round curve in one room easily unloadable (used in dead space 2 for example). There is all sorts of small hacks and tricks you could do with this. Also why 192MB? 256^3 x RGB = 48MB, did I miss something?

Most problem in production aren't necessarily for the generic case, but dealing with some edge cases, like your AI will be competent 99% of the time but will forever be remembered for the 1% where it breaks, being able to recognize and override those 1% is key. This is true for lighting too. A good recent example of this was mass effect andromeda, it wasn't bad just unremarkable, but when it failed, that's only what people could see (that's why it's always the same handful gif shared).

It's obvious you can't solve all specific cases, but having some hooks, people can build around to deal with them, you don't have to fully support it to cull the novice, just have a "stealth hook" that pro can extend to achieve that Which I may be not pro enough to use, oups


It's not necessary though, just cherry on top of sugar, if it prove to be too much of an hassle, that was just a footnote, feature creep and all lol. I just shared my rational, please don't interpret this as a request.

 

I'm not sure what @neoshaman is aiming for, but I can see how wanting to turn it off / on, or down / up in quality during play without a ton of blurring would be helpful in managing frame rate in games.

 

Light data is stored in 3 RGBAHalf textures. It's stored using 2nd order Spherical harmonics. This way a single cell has the lighting data coming in from each face.
Voxel data is stored in 1 RGBA32 texture.
Emission data is stored in 1 RGB111110 texture.

 

Directional light is working with cascades now. I need to clean up the code so i can support more light types but its a start.

 

Oh wow, fantastic effort man. Thanks for screeny, looking good

 

This is sick...

(Hello by the way, someone pointed this out on the SEGI thread. So I guess now I would have to decide which one of these GI solutions to pick when I need. It's for a PC and Current-gen consoles production.)

 

I have SEGI but if this becomes available (hopefully soon )
then I definitely pick this one

With SEGI you can currently not be sure if there will be another update or if development has stopped (completely or ast least for some time)

 

wow!

I hope this happens and I hope there is a Mac version.

 

Set a release date. Im trying to send you money.

 

I noticed there were several voices indicating that it would be sufficient to release this asset even if it came with no support. I think that is a sound opinion for teams that have the capacity to re-author tools if necessary, but when a plug-and-play solution is possible, that is valuable to everyone; if the asset does command a >=$100 price tag, then this really should be the case, especially if support cannot be expected.

In fact, a lot of the traffic that is migrating here from SEGI is probably because of the lack of support for that asset; if HxGI were released, but unsupported, it would really just be the same story all over again. I hope there is a steward who is capable of taking up the mantle for HxGI when / if it is released.

One of the features that inevitably comes up with GI plugins concerns baking. I appreciate that baked lighting is literally the opposite of realtime GI, but being able to bake out lightmaps (or some derivative) can be an immensely desirable feature in so many situations.

Also, iirc, Hx Volumetric Lighting doesn't support MSAA in Forward for SPSR(?) Is there any reason why this might be the case for HxGI?

 

Nice photograph.

 

I agree, the plug-in needs to be close to done before I can release it. That way the community wont be waiting on crucial updates for it to be usable. It might be fun to play around with a realtime GI system but if it cant do the job then there isn't much point getting it early.

Unity is generally really closed off, things like baking are a black box. To be able to bake to the lightmaps, light probes and reflection probes successfully id need engine access. I might be able to compress the data enough to bake out the 3D light data but that's probably the best this system will ever be able to do, honestly its not worth it. A Baked lighting solution if used correctly will look a lot better then any runtime GI system can calculate. Ill try and get the system working with the editor so you could have it turned on while editing your levels to get a better idea of how the lighting might look once baked.

The cost for looking up the lighting in the fragment shader is pretty cheap. So forward support will just need some custom shaders that sample the GI data in the first pass. Volumetric rendering is capturing all the lighting data between the eye and the fragment. a lot harder to do in forward rendering. I'd need to store the accumulated volumetric lighting data in a Froxel and then have the forward pass sample that to enable MSAA and volumetric rendering. Although that has some big downsides as well.

I'm actually curious why people use MSAA when unity's directional light doesn't even support it. How do you all get around that limitation?

 

There's obviously differences in opinion in what constitutes acceptable aliasing, but for VR, 4x-8x MSAA is really cutting it close - anything less and it's too much staircasing for me.

EDIT: I've tried Playdead's TAA, and it was good

 

I asked why they use MSAA but still use unity's directional light. Unity's directional light does not support MSAA. If aliasing is an issue (I agree) then the horrible aliasing from unity's directional shadows is reason enough not to use it. Do you roll your own directional light or use another SSAA solution to limit the aliased shadows?

EDIT: For my game a made a custom directional light so I could use MSAA. I also do all the screen space effects before i render the the image so i can do a nearest neighbor search and look up the most correct UV data for that fragment. It allows me to do all the lighting and effects in a single pass while still working with MSAA.

I just see so many VR games that use MSAA but still use unity's directional light.

 

Right, I've been using NGSS lately, which has a robust set of customizable options for PCSS and PCF shadow filtering for point, spot, and directional lights (!)

 

So that doesn't apply the directional light as a screen space effect? I figured it would just overridden unity's shadow sampling code. I'm not talking about the shadow quality here. im talking about how the shadows are applied to the screen. It's the same issue with every SSAO effect and MSAA

 

Oh I see, I misunderstood. NGSS does support contact shadows, which is a screen space effect, but as you said, the filtering is occurring through a shader which interfaces with an enhanced version of Unity's default shadow library.

 

Not what I'm talking about, If you look at the render stack and how unity actually applies the directional lighting to the scene it renders out a gray scale image of the sunlight contribution. Then all the fragments sample that none MSAA texture to get the suns lighting data. this method means you don't do any overdrawing of shadow samples but means the light does not get effected by MSAA. Here is a link back from 2013, the unity light is still applied this same way. Basically the directional lighting is applied in a deferred-ish way meaning it doesn't work with MSAA

I just don't understand how people that want MSAA support still use unity's directional light. doesn't make sense to me.

 

^Good link. Fortunately NGSS is satisfying my shadows needs at the moment, but my main issue with AA in VR really isn't the shadows that get aliased, it's everything else.

 

A not on baking, procedural level don't have much the luxuries to have hi quality lightmap, so an intermediate quality with real time lighting "caching" is important in this case.

Also Yeah I don't need "yet"

Still


I'm waiting for the screen pay implementation

 

If the realtime GI is fast enough, then you don't need to cache it.

 

^This.

 

I think a lot of people are just using TAA and calling it a day. Apparently Livenda's CTAA works pretty well (for all types of aliasing from what I've heard) – that was our plan at least. Also, there was actually a shader posted online recently that does antialiasing in the fragment shader for the shadows, so there are ways around it.

 

Hello Lexie,

Just wondering if translucent surfaces will be taken care of?
As in light passing through them will cast colored shadows, possibly also taking into account refractive caustics effects?
Which brings to mind the importance of order-independent translucency....
Any comments on these?

Cheers!

 

OIT issues have been kicking my ass in my voxel based game. I eventually got in an imperfect weighted blended OIT. This question interests me too.

 

This looks extremely interesting.

My question is how well does this interact with HX Volumetric Lighting (or any volumetric light system)? Since most of the lighting is done with emissives instead of Unity lights, it seems to make getting volumetric lighting effects impossible, at least at the moment.

 

Take a look at the first post. The roadmap has:
Integration with HXVolumetricLighting.
Therefore, it seems it's indeed not impossible.

If it is indeed integrated, it will likely make both assets a buy for me...

 

Yeah, I suppose my question would have been better in the Hx Volumetric asset thread, since it's more about Hx supporting emissive surfaces. Hx already works perfectly fine with SEGI, you just have to use Unity lights to get the volumetrics. But reading this thread, that would be an expensive overhead with HXGI, and unnecessary if Hx Volumetric would support emissives.