Global Illumination alternatives

[Daedalus51]

I think we should focus on techniques which allow for fully dynamic environments with fully dynamic lighting.

Hahaha...coming from this perspective I totally agree with you^^ I was mostly throwing in these ideas because not too many games require this complexity of GI solution. But I still have a gut feeling that things like cone tracing ala Tomorrow Children will stay the exception only for games that really require it (and those games will most probably suffer on some other parts to make the power available, not saying they will be bad here^^). For a lot of the standard stuff, something like Enlighten or the Division/AC stuff should be enough.

I know about the distance stuff with the raytraced shadows and it indeed is very cool....but man...SOFTSHADOWS!! xD

Yeah...I dont know^^ I am basically just hoping to get a scalable dynamic replacement for lightmass that provides maybe different approaches depending on what kind of game you are working on at some point (does that sound too demanding? )

Cheers!


EDIT: One last thing regarding "Epic is building stuff for Fortnite". I really dont want to sound angry or offensive (**** I am far away from it ), I am just being analytical and objective (and I really love working with the engine, otherwise I wouldnt do what I do ):
We are licensing the Unreal Engine 4, not the Fortnite Engine! It is good when the development of a certain game pushes the tech forward, but its not good if this might also hold the tech back because time and ressources are spent
on developing a game specific feature thats not the best gain for the Engine as a product overall

Just to mention this perspective as well

[iniside]

Hah I agree tthat solution for semi dynamic level would be cool (fully dynamic lighting, but for the most part static geometry),

Enligthen looks cool, but from what people around say, setting up assets for it is nightmare and precomputing can take as long as lightmass or longer (!). Dunno how true is that but...

The solution from ACU and The Division aside from what I have said earlier, is very game specific. For example to support time of day you need to interpolate between cubemaps, so you either support time of day by default (and then what if my day is 36h compressed to 1h instead of 24h compressed to 1h ?) or you left implementing rendering details of cubemap interpolation for end user... which is less than ideal.

We could only store spherical harmonics in probes (like it was in FarCry 3), then quality will be lower, but it will work for arbitrary lighting conditions.

[Frenetic Pony]

That was like month ago. In engine development it's equivalent of stone age .


@up yes. But, these dynamic lighting features like DFAO or similar are really high end features, which requre minimum precomputation. In case DFxx you pay cost of precomputing distance field on mesh, but everything else is dynamic.
All things considered, it's still cheaper than voxel based techniques where everything is dynamic (including voxelization).

To compare you them:
1. Distance field works on very thin geometry, since there is no leaking.
2. Distance fields are cheaper, since heavy step of creating alternate representation of geometry is precomputed.
3. They works on any geometry with distance field.
4. Voxels are much heavier, since they need to be computed on runtime (in theory you can precompute them, but it will take lots of space to store them).
5. Voxls are usually causing light leaking, since well, They can't be to small.
6. Voxels work on fully interacive environments (including deformation, destruction etc). Something which distance fields can't inherently support.
7. Both are high end features, since computing at runtime indirect lighting is very heavy on performance.

2. They aren't cheaper since you can't cone trace and must use multiple samples.
3. Which doesn't include skinned meshes, voxels work on anything.
4. Actually the voxel creation is incredibly cheap compared to tracing
5. They can be a lot smaller than Epic tried, sparse resources for fixed 3D textures are much cheaper in terms of memory
6. Yes.
7. And yes.

I'm rather sad Epic gave up so quickly. There's easily more to do for Voxel Cone Tracing, they just didn't get it right on their first try then moved on to something else. While cone tracing through a 3D Texture you can check the next mip level to see if its empty, then skip it if it is, which can produce performance and is in fact incredibly similar to sphere tracing/distance fields to begin with.

Will Voxel Cone Tracing GI just be the "one solution fits all" they wanted? Of course not, there's no way to get a triple bounce needed for minimum GI convergence on today's platforms. But its better than throwing out this hacky distance field stuff. Now I need to go back to doing Voxel GI myself instead of hoping Epic will do it.

[Alessiot89]

I can guess... Volume Tiled Resources \ Volume sparse textures are coming... See you soon at Q1/Q2 2015

[DanielW]

It's weird to have people snooping your changelists =)

[iniside]

Now I'm checking promoted build every day, to see when it will get here lol

[DanielW]

These aren't the droids you are looking for, move along

[JedTheKrampus]

We believe in you Daniel <3

[iniside]

So I tested the new GI in promoted build and it seems to be working. But it behaves like it would work in screen space. That's definetly bug not intended behaviour:



Also, don't mind dark blotches. They are obvious when you use, white surfaces to test.

Another thing, this GI doesn't work without SkyLight in level. I found it odd for first 1 min, thinking why it doesn't work, then placed SkyLight and whoop! Worked.

In anycase I like that it is here and it works. I guess it have the same set of limitations as DFAO (limited distances, etc ?).

edit:
Also when you uncheck cast shadows on SL, GI disappears, and It seems like GI doesn't work, when there is not enough objects to cause occlusion around (for example If I removed the wall opposite to red one, the white floor wall won't receive any bounced lighting, even if rotate it slightly in direction of floor.

[ambershee]

If you look at the screenshots, it's obvious that the red shading is only being applied where shadows are being cast, unshadowed areas aren't recieving any colour information.

If it's screen-space and only applying in shadowed areas, then it's pretty darn useless.

what if my day is 36h compressed to 1h instead of 24h compressed to 1h

I actually don't see what difference that makes - you're still progressing through the exact same day / night cycle, just at a different rate. 360 degrees is 360 degrees.

[Pjotr]

If you look at the screenshots, it's obvious that the red shading is only being applied where shadows are being cast, unshadowed areas aren't recieving any colour information.

On my monitor the unshadowed area also has a red tint only it's very faint. Probably because the sunlight is contributing a lot more to the color than the second bounce is which is to be expected.

[ambershee]

Are you sure that's not a trick of the eye? I can't see it at all - try putting the screenshot into an image editor and comparing the surface with pure white, when you cannot see any red area. I cannot see any red at all

[Errvald]

Are you sure that's not a trick of the eye? I can't see it at all - try putting the screenshot into an image editor and comparing the surface with pure white, when you cannot see any red area. I cannot see any red at all

The not shadowed area has a tint of red, which I guess makes sense.

[darthviper107]

I'd wait to test until it's in an official build

[DanielW]

To be clear - r.DistanceFieldGI (what iniside tested out) is not an actual feature yet and it's just gathering lighting from scene color. Aka the worst of both worlds - the overhead of DFAO + the screenspace artifacts of SSGI.

So far I am not getting good results leveraging the distance field cone trace data for GI. But something may still work out.