Enligthen is using very similar technique to DRT and it is integrated into Frostbite. I would say that makes used in quite a few games already ;).
And still, calculating radiance transfer can’t be any slower than calculating lightmaps. The difference is I have to recalculate lightmaps every time while, radiance transfer only when I change geometry.
The interesting part about DRT (if done to the paper) is the fact that baking in that case is matter of seconds, because it reuse a lot of data, and cages are generated while baking. It of course lowers quality for anything that is not 90 degree angle wall or cylinder. But it still might be usefull, for small props, which could be contained in simple box, and calculations for that box could be reused all over.
Anyway. I don’t like geometry cages as well. But as I said, there is possibility of reusing work you have to do anyway. Like collision geometry or LOD geometry or just buy yourself Simplygon. It’s certainly far less work than creating unwrap for UV maps.
Btw If you want large terrain I would focus on Landscape Demo. That is large terrain ;).
Would it be possible to merge Voxels and spherical haromonics used in PRT techniques ?
Looking at this slide:
The most expensive operation is cone tracing.
But most of the time, cone tracing is wasted operation since most of the geometry is static, and only thing which is going to change is lighting information.
What if instead of tracing every so often, we would calculcate SH for every voxel and store it for further use (just as probes are used). In that case there would be much more information to store, than with probes.
Would it be possible to pre calculcate SH for voxel shapes, and then use those shapes at runtime to dynamically voxelize scene in radius, wrap voxels around geometry and then use precomputed SH for voxels, to calculate indirect lighting ?
It would be similar to MRT/DRT but instead of using primitive shapes, with precomputed SH, we would use voxels, to attach them around geometry.
Saw that and talked with the guy, he had a lot of problems with the screenspace reflections and making sure everything was set up right, but the end results do look pretty good.
A new rendering card has been added “Raytraced directional light soft shadows using distance fields”. What does it even mean? lol Either way I’m happy we are seeing more dynamic lighting stuff being worked on(assuming its dynamic).
Fascinating idea, recalculted distance fields for skinned characters I hope. Was thinking about how to do this in realtime, most interio lights have results too soft for PCF, and sampling problems are introduced with naive shadow mapping. Was thinking of edge importance sampled depth peeling stored in an MSAA target, but distanced fields would be an interesting idea, even if only for static geometry.
Nice! Is this going to have the same requirements as DFAO for meshes or is it going to work regardless of the scale, open faces, etc. of meshes? And i hope this wont crash like DFAO does, otherwise it will be another sad update for me. :\
Wow that’s beautiful! I’d always wanted that type of shadow!Are they dynamic?! With that said I would love to use DFAO but it has some limitation(i.e. building has to be same size). Will those limitation be addressed in the future?
sorry for such a late reply! Man, thats one of the most “epic” (höhö^^) answers I ever got! Thank you a lot. That helped me quite abit and threw up some interesting ideas which I already passed over into our coder dungeon^^ Sadly, I dont see us implementing any custom stuff (at least at this complexity level) anymore, since we dont have that much time left. So we will probably stick to what we have and make small improvements to just make it work better for our specific needs. But still, very inspiring for future stuff!
Thanks again for this detailed answer and cheers!
Edit: Is there a way to exclude meshes from the DFAO calculation? Would be very neat to tell all the grass meshes for example to just not use it/affect it. That would also help with the performance I guess
One last random thought, probably blog this elsewhere, in fact I’ll do that now! For each cubemap, store albedo depth and normal (compacted to two channels for normal and albedo, quality not that important) then with originating camera position you’ve got all you need to relight say, one 256x256 cubemap face each frame, resulting in however many (in this case 5) newly lit cubemaps a second.
Keep the the relighting to say, the sun/primary light and whatever changes to the skybox, and you’ve got a relatively cheap dynamically relightable image based lighting system, for relatively little coding effort. It shouldn’t even be that GPU intensive, you’re just re-shading a fixed screenbuffer with a shadow map applied, no draw calls or anything else needed. Heck do 3 faces a frame and you could do 150 cubemaps over ten seconds, assuming your primary environment lighting doesn’t change that quickly it would all be fine.
This is the interesting part that is actually relevant to GI: “[FONT=Segoe UI]Finally, high-end maxwell cards will be able to take advantage of games that use Voxel Global Illumination, a new dynamic lighting technology that promises to promises to enable destructive environments with active, realistic lighting. How realistic is it? Realistic enough to debunk moon-landing conspiracy theories[FONT=Segoe UI], actually. NVIDIA says the new lighting solution will be available for UE4[FONT=Segoe UI] and other major engines later this year.”
Not sure if that means Epic is working on implementing the solution and it will be available to us as part of the engine within a year or if that means Epic will be able to implement it in a year. Would be nice to know if Epic has any plans with this or if this is news to them too.
At the very least that means that Nvidia will have the UE4 integration available and you could contact them about getting it integrated in your game. I’d love for Epic to add it in to the engine though.
Though I must admit that it looks like a interesting idea 