Hmm, that sounds interesting, will give it some thought
You have a good point. I always assumed the reason that sparse voxel octrees gave bad performance was because the data structure itself is so non-contiguous, not because of the octree traversal algorithm itself. Like you said, the only to know for sure is to implement it and see. But I can say for sure that using distance fields will not have the same problem as it avoids the octree traversal altogether.
Another way to accelerate the raymarching would be to use a cascaded voxel representation and read from lower-resolution cascades as the rays get further apart, like I mentioned above (obviously, it would be for diffuse and blurry specular only). That way you could increase the ray step size as the rays get further away, but you avoid the octree traversal altogether. I’m quite certain that would give a speedup. If you aren’t sold, though, then I’d be willing take a crack at it, after you implement cascades. It should just be a matter of changing the shader code, which I’m quite good at (messing with the internals of UE4, not so much ;)).
Voxel cascades will have the stack problem though. Oh, wait, unless you mean using a lower res as you get away from the starting point. I’m in the middle of a change on the way I store the voxels, will use 3d textures, and that will surely make it easier to implement cascades. Will keep you updated. I do do trace against a packed binary voxels grid, so I need to sample less, but that have some implementation issues. Now ill move that binary grid to a r8_uint 3d Tex where I pack 8 voxels, so that it’s effectively at half res for the trace, but full res when sampling.
Yep, that’s exactly what I mean.
The obvious approach would be to choose the LOD where the texel size most closely matches the current “cone size” (if we pretend for a second that the rays are closely packed cones). But that wouldn’t work well, because features will need to be thickened in the coarser LOD’s (otherwise thin walls will disappear), and therefore small gaps like windows would close up. could be solved by subtracting a constant from the LOD level and clamping to 0. way the “closing up” would still happen, but it would only happen at distances far enough away from the starting point that it won’t matter
another trick to avoid tracing over large distances is recycling nearby raytraces that go in a similar diection as the current one an storing them in a buffer , so each voxel or pixel needs a dedicated trace of a very short distance a la tomorrow children , but i think you have already implemented it and because of that you think that using distance fields is not worth being implemented?
Sounds like a plan! Will tell you when I’ve finished converting to 3d textures and we can try that.
Recycling prev rays for pixels that hadn’t moved a lot is something i am going to do, been thinking on that for a while.
About distance fields, epic is already doing a lot of job on that area, so think is better to leave them work with DFGI and similar, like I said before, distance field have their own plus and cons, so it’s cool to have different options to choose.
I think that you are confusing resusing traces from previous frame with what i mean
Guess i am :S what did you mean then?
I am sorry for not being able to answer earlier , didnt have my computer avaible.
what im talking about is on page 96.
http://fumufumu.q-games.com/archives/TheTechnologyOfTomorrowsChildrenFinal.pdf
Oh I see. Hmm, maybe, not really sure how to add it to raymarching though, seems like a good fit for conetracing, but strange for rays. Will give it some thought.
I do need to finish the changes I’m currently doing and evaluate performance to get some up to date numbers, see how fast AHR really is (on million of rays/second)
EDIT: Maybe a buffer on shared memory? Not completely sure, you need to be really careful with stuff, as you might spend a lot of time on a that on paper it reduces the access count, but on the end it’s slower cause the access pattern is worse, or warp divergence, or occupation, or just you realize what you wrote is the same that the cache does. Been there, GPUs can be ******* D:
Will give it some more thought anyway.
actually when i first read that part i thought that it was talking about tracing the far part first over number of voxels then trace a “far” for those voxels too ,all the way to your desired ray lenght , instead tc just traces the “far” once per cascade
Sorry I’ve been slow with the updates, but have some really interesting stuff on the pipeline. Toying with an idea to spread the tracing over say, 4 frames, so that you get a x4 speedup (as it’s like you are rendering at 1/4 res instead of 1/2 res). You have to take into account how much it has moved, and it has some subelties, but from what little I’ve tested it seems to still look good (a big thanks here to the normal interpolation trick) and run much smoother.
Will have some more updates later. Also, want to finish the conversion to 3D textures, and test what you guys said a few post back, about using a few lower res mips for the samples that are far away.
Hope to have some more free time. University is a bi**h right ? D:
So kinda like interlacing for old CRT screens but for dynamic GI? Sacrifice a bit of quality for a huge speedup. Why not. 
Yeah! Something like that. On the worst case, when the image moves a lot, it’ll be like rendering at 1/4 res but a) you are moving fast, so you don’t see much detail, and b) the normal interpolation trick fills in the gaps nicely.
I bet is one of those scenarios where people will only be able to notice the difference in either a screenshot or if they are told to look for the errors. You know, like video / study. Ah the limits of the human mind, easily open to be tampered with. 
Still alive here ;D
2 exams down, 3 more to go. Will have more news after the 10th
I see a lot here about GI, but what exactly is it doing for reflctions and emissive materials?
Hi everybody;
The **AHR **had been released on the 14 of April 2015… Today is 03 of July 2015…
For about 75 days… all What I saw was discussion without implementing accept 2 OR 3 tries (if I’m not mistaken)…
Seems to me most of us has no time and are busy with examinations…!!
Best wishes for all…
@Cadviz, please explain yourself using clearer language, I can’t tell if you’re discontent with the situation or you’re just stating facts.
In any case, being an open source project, everyone who is able to complain could also be able to modify the source to fit his needs… Or at least use that time to start learning c++.
is doing work for free so I don’t think anyone has any room to complain, so let’s keep the discussion on the positive side, shall we?
Just my 2c.
Emissive objects illuminate the scene, just like a light(but don’t cast GI for now), and for reflections it allows you to have dynamic reflections for on screen and off screen objects (but just the ones that either emit light, or are hit by direct light