Feedback I'd like this GI solution in Unity, thanks a lot :)

It's available as a shading node so you'd plug your indirect texture into it or something like that, for baked GI. That texture could be realtime updated for example.

 

Downloading latest 2019.1 now, can you sample from the lightmaps directly in Shadergraph yet?

 

Yes according to blog. I'm not sure what I'm supposed to do with it

 

Just had a play with it in LWRP and using an unlit shader was able to replicate this effect:
https://twitter.com/Svarlingo/status/1009834620408483840

Unfortunately it seems that the ability to override the GI for a material is limited to HDRP at the moment. Would be a very useful feature to have in LWRP.

edit: It's going a little off topic from the scope of this thread so I'm not making a new reply for this, but I'm surprised just how well the lightmap masking method works to create different lighting conditions using the same baked lightmap.

 

Also on built in you can change lightlevel and color of mixed mode lights. We use this to simulate flickering light to great effect

 

Anyone know if its a documented feature to change mixed mode lights at runtime?

It looks pretty good atleast

edit: If you ignore that indirect light is not affected

 

For fun tried above flicker effect with real time pre computed GI, and there is a huge delay in the indirect lighting, didn't look good at all. So that's another problem with GI

 

Sounds like it makes it so you can write a shader meta pass in the shader graph. So nothing new when writing shaders by hand. (From what I gather)

 

Perhaps I am barking up entirely the wrong tree, but do you think there are some clues in this github branch and its recent commits?

https://github.com/Unity-Technologies/ScriptableRenderPipeline/commits/rtpv

Some examples of possible clues:

'Initial support for probe volumes.'

'include "Assets/DDGI/IrradianceField.hlsl"

'#ifdef USE_RTPV_RASTER_ON
# include "Packages/com.unity.ddgi/IrradianceField.hlsl" '

 

Hmm...

https://morgan3d.github.io/articles/2019-04-01-ddgi/

It seems to be based on HDRP, which would fit with this.

 

So for raytrace-capable cards / next gen consoles?

 

The Nvidia GDC video about it is available: https://twitter.com/CasualEffects/status/1118818116551806978

 

1ms on a 2080ti is so much more than 1.6ms on an XBox One though.

 

hmmm....

...and it's a 2080 running @ 1080p not an xbox one refresh running at 4k.

 

It's seems like (without whatching teh video) using old gi technique to cache raytracing data, and since old card can do raytracing but slowly rather than accelerated, that make a lot of sense.

Now actually documenting myself on what's going on.

 

Ideally I'd get some approximation of GI that updates around 24 mins for a day cycle at fastest rate for existing console hardware in around 1ms, so the the time of day change is really forgiving in my scenario...

That seems doable, surely? Leaving it to the mad scientists at Unity's lighting dept.

 

Everything depend on the rate of FULL update:
- does the environement change
- does dynamic contribute or only receive
- is there big dynamic occluder
- is it open world so you have to initialize a new tile while moving?

Because for TOD, a slow update time is probably enough since there wouldn't be major change in the scale of seconds, moving around would be the major cost.

24 minute a day is this also night time included? Well assuming a very bright moon too lol: that's 1440 secondes, at 60fps that's 86 400 updates a days with every frames. So the scale of update in "arcs" is 2pi / updates, if you figure out what is the minimum arc where update artifact are visible (ie in term of high frequency texels coverage), you can know what is the actual update rate you need for your game (assuming no movement), and right away you can see that grazing angle might an issue, ie dawn and twilight lights. But only for high frequency details, probably smooth blending between two state (like a delayed update rate would do) is probably fine.

 

I find updating once every few seconds is sufficient, so 24 mins for a full cycle would probably easily be enough, especially since I can actually get away with only having GI for objects smaller than say 100 units square, locally up to 500 units. Anything further can just take whatever the sky probe says...

Really, it's for tackling a high number of small openings locally, such as buildings, caves, huts etc. that sort of thing that will go to lods before long anyway...

I tried GI with 2019.1 f2 but it's still suffering awful runtime spikes and I'm clueless why (with HDRP / procedural sky, no lights).

 

isnt 1 minute per hour way too fast? depends on the game offcourse. But for example in DayZ a fight can go on for hours.

 

The delay in precomputed realtime GI can really be a problem. For example with firearm discharges or other fast changing lights. Here example with my florescent flicker

 

Rather common and logically depends on the type of game!

I have been debating 48 mins but first I will be seeing how much the player can achieve since it's not just visual in my game but alters the gameplay.

 

Unity's streaming stuff like graphine is also an option, just stream in lightmaps as the day progresses I guess! just beyond what a feeble mortal like me has time and space to make :O

 

The maps on disk will take huge amount of space though Our largest map is 512x512 meters, default resolution of 40 and you cant go lower than that. Its a tad low but ok with current VR headsets. That map takes 500 megs on disk. I imagine you need atleast 4 sets that you can blend between as a minimum. Thats 2 gig just for a 512x512 stretch of land.

 

How did you manage to have the directional light bake into the red channel and the GI into the Green channel?

 

Do those things really need to impact your GI, though? They're fast enough and contrast enough that I bet you wouldn't notice unless you already knew and were looking for it.

 

(we are getting off topic, so we might as well open a new topic on this technique if you want, I implemented it yesterday, feel free to tag me if you do open a new thread, but basically you make the directional light pure red and the sky pure blue (or green, or whatever channel you want)

 

Its probably not a problem for slow changes like someone open a door (Is even Enlighten precomputed accurate enough to take subtile changes like open a door into account) or the changes over a day night cycle. But it is a problem for one frame changes like my fluorescent flicker or when a firearm is discharged. I notice it, but I guess it depends on how sensitive you are.

Another problem is reflection probes. In PBR they account for super mutch of final ammunt of light a object receive. (Look at the light object on the right side)



Easily fixed with a runtime reflection probe that is triggered by the flicker using RenderProbe. But now you need a system that lets the flicker sync between all active light flicker so that not multiple probes are rendered in same frame, it could potentially mean the game misses a frame.

Come to think about it, this also effects firearm discharge but in the reversed order, a probe in the dark will not contribute correctly to lightlevel changes of firearms. I do not think it will be as noticble as above picture though. Will see if I can get a shot of that.

 

Just tried the other way around with a dark probe and scene being lit by a firearm, this is the precondition (Ignore the green line its debug for my ballistics system (Thats how far a bullet travel one frame if interested), I have discharged the firearm here but hid the firearm)


Here is the firearm unlit by discharge



And here lit by firearm


Specular lighting to the rescue I would say the specularity of the light hides the wring reflection information.

Same for the surrounding items, specularity etc hides the facts that the reflection info is completely wrong

 

Sounds like a thread you should make anyway, count me interested

 

Aside from you knowing because you made it, who is going to notice if firearm discharges are ignored by your GI solution?

Sure, it'd be nice if we could have true real-time GI that accounted for this stuff, sign me up. But until then, I'm not going to make complex systems for my game to work around a one frame, subtle inconsistency.

 

And flashes like this, nobody does it. AAA doesn't. It's just a light. In fact in overwatch it isn't even a light, but bloom instead. Short lived stuff, you don't have time to notice.

 

How to do this? These are only lightmaps?

 

Today Digital Foundry did a showcase of the ray Traced Minecraft build with Sonic Ethers GI shader solution. As ever they do a really nice video that truly showcases not just how good this looks in Minecraft but how realtime dynamic GI can be a gamer changer.

Sadly performance isn't there yet, though with proper access to Minecraft code it could be improved a fair bit.

 

I guess eventually all GE's will go the cryengine route.

Spoiler: spoiler

 

Will it be free and for SRP too?

 

Hi. Last 2 years in Unity i ended with similar stuff because it simply works.

Target: photorealism for driveable car interior, car exterior and environment with different weather (overcast, sun)and day/night (no full dynamic day night cycle but close).
Min framerates. Stabil 60fps ,2560 x1440 on midrange gpu like gtx 1080 because multiplayer and physics.
90fps for vive on highend gpu like titan v


Find outs.
6 different indirect lighting bakes with 6sky IBL s
+ Bakery Lightprobes + Distance Shadowmask
interpolate between these sets. everything needs own UID
based on
https://github.com/guiglass/Lighting-Scenario-Switcher/blob/master/README.md

1. working prototype
Bake
Blender Cycles FullGI 2000 samples
preview 9 days 90 2k maps on 4GPU
production 24 days 70 8k maps on 12 GPU

combine these in 6 granite virtual texture set for streaming.

2. test
Bake
Unity Enlighten and Progressive
gave up after 1 year.
far away from production ready.
No control because blackboxed lighting asset .
Bake times would go up to 200 days when it wouldn t crash.

3. unfinished prototype with Bakery

Bake
Bakery BuitIn and HDRP 4.6
preview 3 days 90 2k maps on 4GPU
production 6days 70 4k maps on 12 GPU

combine these in 6 to 8 granite virtual texture sets for streaming.

additional alpha tests for 1. and 3.
adding DXR reflections and DXR shadows improves quality further. loosing 30% framerate. But ok for absolut photorealism .

problem: granite for unity is deprected now
hopefully a good thing: unity aquired granite.

Every realtime GI approach i know cost far more than i can give .).
e.g enabling dxr indirect illumination results in low quality lighting and framerate loss is around 40fps by needing a gpu who costs min 2x as much.
Segi on my setup. low quality lighting and minus 30fps.

From my point of view.The problem in Unity is the blackboxed lighting asset and the horrible quality and slow progress of enlighten and progressive mixed together in an user unfriendly lighting window. Absolut no multi scene workflows who are ready for production since 2 years now.

So. My hope is.

Unity opens or integrates workflows for external baker solutions like blender cyles (no costs, unlimited cpu and gpu, open source) . Blackboxed lighting asset is something i think will never work. Say hello to an ScriptableBakingPipeline.
Same with trying to generate baking quality and performance like in blender with an small team will result in i never come out of preview.
I also tried Octane for some hours till the moment i realized the license costs resulting in an immediate delete from project.

Unity finally takes a look what one men can do in terms of stability, user care, support , documentaion, performance and quality. See Bakery. No leaks. No seams, DirectionalSH, Lightmaped Prefabs, Occlusion probes, Lightprobes, ... only crashing when hard drive is full. Simply needs good IBL and solid LightmapUV s and some GPU memory for highest bake settings and 4k maps.


Adressables could deliver simar workflow to something like UID workflow from the LightingScenarioSwitcher for multi scene easy. But no move for now.

 

Video description says

I doubt it'll be made free... He does have twitter (source), so maybe it's worth asking him questions there: https://twitter.com/ghostBUG6

Edit: Just found his Asset Store profile here.

 

Also bakery is open to create an api for specific baking need!

cons: only work on nvidia (for now?)

 

There a two more points on Bakerys Roadmap. All others he did in record time.

- Runtime switchable/blendable lightmaps support.
- Preview camera path tracer.

Once these are solved and complete source is open i would completly go with.
Up to this point its good to have an alternative.

 

in addition...
This one was very close to an perfect solution

An integration of Blender Cycles Standalone in Unity.
You see Units Standard Shader and overtime when enabled FullFeaturedGI in viewport based on Blenders Disneys principled.
He then started with tests for generate Lightmapping out of these integration using it as interactive realtime preview but stopped as Unity announced Octane integration.

 

Is it terrible that I'm more impressed with this than with RTX? NVIDIA developed specialized hardware and Microsoft made a specialized API, but this is just Java and OpenGL.

Spoiler: Vanilla vs SEUS PTGI E5 Comparison Video

 

No its not terrible, I almost feel the same way.

Point is though that RTX/DXR are in the early stages, as long as they continue to develop the tech it shouldn't be more than a few years before we get everything shown in the current realtime GI solutions, but without the hacky, tricks and low resolution for real. Along with nice clean integration into your 3D engine of choice.

 

Also RTX is probably more efficient, while the minecraft one is almost brute force. I mean look at the mean reaction I got when I suggest just use segi (which is an early implementation of that idea). People want performance on top. RTX would probably be along like 40% more performant.

 

https://www.reddit.com/r/nvidia/comments/badoyj/raytraced_irradiance_fields_dynamic_gi_by_nvidia/

emphasis:

 

Unity already have this AFAICT in the works but I'm hoping it won't be exclusive to DXR.

 

tldr you can get lumberyard here

https://aws.amazon.com/lumberyard/

 

Yeah, but then you have to use Lumberyard.

 

true dat. Oh the conflict.

Wouldn't it be great if unity could just port lumberyard's / CE GI solution into . . . well unity!!

 

Armory engine supports voxel based GI!

 

https://armory3d.org/manual/#/graphics/global_illumination