why I am posting this here is because when it comes to current SSAO implementations, I only found three blogs and one forum - this one. Because of LordHippo's implementation, obviously.
One resource I found linked in one of the blogs is this powerpoint for the UE4 demo at Siggraph (slide 38 is most relevant): http://advances.real... Demo 16x9.pptx
So as I am reading about various implementations and thinking about their pros/cons and about how to best combine them in my own SSAO algorithm, I though about the method in this presentation in the context of this method here.
And it made me wonder... am I overlooking something or is what they do in UE4 weirdly unwise?
I speak about the clamping against the per pixel normal. Because while it may end up visually pleasing, clamping corrupts the data (occlusion from an occluder behind the current fragment is included) and results in unnecessary performance use - does it not?
With John Chapman's approach, on the other hand, one does not even consider occluders that can't occlude the current fragment in the first place - faster and more accurate?
I am asking about this because it seems odd to me that the people at Epic wouldn't have come up with something like that. So they may have had a good reason to have done it the way they did.
Question regarding SSAO methods (UE4 in this case)
in Tech Talk
Posted
Hello,
why I am posting this here is because when it comes to current SSAO implementations, I only found three blogs and one forum - this one. Because of LordHippo's implementation, obviously.
One resource I found linked in one of the blogs is this powerpoint for the UE4 demo at Siggraph (slide 38 is most relevant): http://advances.real... Demo 16x9.pptx
So as I am reading about various implementations and thinking about their pros/cons and about how to best combine them in my own SSAO algorithm, I though about the method in this presentation in the context of this method here.
And it made me wonder... am I overlooking something or is what they do in UE4 weirdly unwise?
I speak about the clamping against the per pixel normal. Because while it may end up visually pleasing, clamping corrupts the data (occlusion from an occluder behind the current fragment is included) and results in unnecessary performance use - does it not?
With John Chapman's approach, on the other hand, one does not even consider occluders that can't occlude the current fragment in the first place - faster and more accurate?
I am asking about this because it seems odd to me that the people at Epic wouldn't have come up with something like that. So they may have had a good reason to have done it the way they did.