Results 1 to 8 of 8

Thread: Possibility to write message to Daniel RŠkos.

  1. #1
    Member Contributor
    Join Date
    Nov 2017
    Posts
    93

    Talking Possibility to write message to Daniel RŠkos.

    Hi guys!

    Does anybody know a way to write message to Daniel RŠkos, the author of many good articles on http://rastergrid.com ?

    The fact is his posts did help me a lot.
    It seems I have found a bug in his HiZ algorithm, and I need to notice him about that.

    But I can see the http://rastergrid.com is not live enough.

    Could you answer the question or let me know if my action doesn't matter?

    Thank you!

  2. #2
    Senior Member OpenGL Guru
    Join Date
    Oct 2004
    Posts
    4,650
    Try:

    Doesn't look like he's posted here for ~5 years, so I linked to his Twitter page as well.
    Last edited by Dark Photon; 02-09-2019 at 06:42 PM.

  3. #3
    Senior Member Frequent Contributor
    Join Date
    Dec 2007
    Location
    Hungary
    Posts
    992
    Hi,

    I was just informed that people are looking for me here

    Indeed it's quite possible the HiZ demo has a bug as I recall executing it a while back and noticed some popping artifacts. Maybe it's the bug you've found, not sure as I didn't look into the issue.

    Feel free to post the info on the bug here (assuming moderators don't get mad about hijacking the forum for such purpose), or send me a PM here, on twitter or wherever else you find me.
    I don't promise that I'll post a fixed version of the demo on the blog right away, but I'll try to do so when I get a chance to clean it all up (indeed it has been sleeping for a long time, just as my forum account). Probably I should also just grab all the source and executables and post it on github instead.

    Cheers,
    Daniel
    Disclaimer: This is my personal profile. Whatever I write here is my personal opinion and none of my statements or speculations are anyhow related to my employer and as such should not be treated as accurate or valid and in no case should those be considered to represent the opinions of my employer.
    Technical Blog: http://www.rastergrid.com/blog/

  4. #4
    Member Contributor
    Join Date
    Nov 2017
    Posts
    93

    Smile

    Hi, guys!

    Photon, thank you for help!

    Daniel, glad to see you here!


    In HiZ demo You are culling objects using bounding boxes.
    If no one of vertices located inside the frustum, then object be rejected.

    So, if You have huge flat object, there is interesting case appeared.
    See picture (sorry for format of that, but it most easy way to make it):
    photo_2019-02-11_22-33-01.jpg

    As show my picture, such object definitely must be drawn.


    There was one point.


    There is the second:

    You are perform frustum filter and if the object pass it, then You are perform Occlusion filter.
    Even if disable frustum filter and try to use just 'Occlusion filter', the huge flat object make renderer do z-fighting.
    The object been drawn each odd frame, and it been occluded by himself each even frame.
    I feel my english not correct. I'm not native speaker, sorry for that. I hope you will understand what I mean.

    I can't localize the reason of second point yet.
    I'm going to implement tests on GPU side with compute shader to be able to catch reasons of such problems easy.
    But it long story, because I'm a beginner and OpenGl isn't my basic activity, just hobby.

    May be, You can realize the reason immediately using whole your opengl experience according the first point with BB and frustum.
    Also, I'm not sure if it is not my own bug.


    I hope it will be useful for You.

    Best, regards.

    PS: thank you for yours articles!
    Last edited by nimelord; 02-11-2019 at 12:42 PM.

  5. #5
    Senior Member Frequent Contributor
    Join Date
    Dec 2007
    Location
    Hungary
    Posts
    992
    Quote Originally Posted by nimelord View Post
    In HiZ demo You are culling objects using bounding boxes.
    If no one of vertices located inside the frustum, then object be rejected.

    So, if You have huge flat object, there is interesting case appeared.
    That's not exactly how it works. It actually doesn't just determine whether each vertex is located inside the frustum, but rather does something similar to the Cohen-Sutherland algorithm.

    It counts in the elements of `outOfBounds` whether any of the vertices are outside a particular clip plane. 6 elements for the 6 planes of the frustum.
    It only actually culls the object if all 8 corner points of the bounding box fall outside of a particular clip plane (one of the elements of the `outOfBounds` array is .

    Thus your example in the picture should not get culled because there's not a single clip plane for which all 8 points are outside, there will be only 4 points outside of the left, right, bottom, and top clip planes, and 0 points outside of the front and rear clip planes.

    Now I'm not saying there isn't a bug somewhere in the shader, but looking at its source the logic is as described above.

    Quote Originally Posted by nimelord View Post
    You are perform frustum filter and if the object pass it, then You are perform Occlusion filter.
    Even if disable frustum filter and try to use just 'Occlusion filter', the huge flat object make renderer do z-fighting.
    The object been drawn each odd frame, and it been occluded by himself each even frame.
    I feel my english not correct. I'm not native speaker, sorry for that. I hope you will understand what I mean.

    I can't localize the reason of second point yet.
    I'm going to implement tests on GPU side with compute shader to be able to catch reasons of such problems easy.
    But it long story, because I'm a beginner and OpenGl isn't my basic activity, just hobby.
    IIRC I was simply using the previous frame's depth buffer which is the traditional and simple way to do Hi-Z culling, but also inaccurate, as obviously due to camera movement testing against the previous frame's depth buffer can result in false positives and false negatives. Better alternatives are doing a depth-reprojection according to the new camera location, etc.

    Not sure that's the root cause why you see a flickering effect if that's what you mean by z-fighting, but it's possible. Though the term z-fighting is actually what is used to describe the phenomenon when two pieces of geometry are almost at the same location in space and partially overlap each other on the screen due to precision limitations, which I can't seem to see how could happen due to Hi-Z if you don't actually have overlapping objects.

    I know this doesn't help a whole lot, but it's been a very long time since I wrote that code.
    Disclaimer: This is my personal profile. Whatever I write here is my personal opinion and none of my statements or speculations are anyhow related to my employer and as such should not be treated as accurate or valid and in no case should those be considered to represent the opinions of my employer.
    Technical Blog: http://www.rastergrid.com/blog/

  6. #6
    Member Contributor
    Join Date
    Nov 2017
    Posts
    93
    Quote Originally Posted by aqnuep View Post
    That's not exactly how it works. It actually doesn't just determine whether each vertex is located inside the frustum, but rather does something similar to the Cohen-Sutherland algorithm.

    It counts in the elements of `outOfBounds` whether any of the vertices are outside a particular clip plane. 6 elements for the 6 planes of the frustum.
    It only actually culls the object if all 8 corner points of the bounding box fall outside of a particular clip plane (one of the elements of the `outOfBounds` array is .

    Thus your example in the picture should not get culled because there's not a single clip plane for which all 8 points are outside, there will be only 4 points outside of the left, right, bottom, and top clip planes, and 0 points outside of the front and rear clip planes.
    I looked at shader more carefully, and of course You are right.
    There is no problem in frustum culligh path.


    Quote Originally Posted by aqnuep View Post
    IIRC I was simply using the previous frame's depth buffer which is the traditional and simple way to do Hi-Z culling, but also inaccurate, as obviously due to camera movement testing against the previous frame's depth buffer can result in false positives and false negatives. Better alternatives are doing a depth-reprojection according to the new camera location, etc.
    Yes, I'm using reprojected depth buffer from previous frame.
    Also I can say that movement is not reason, because the problem can be reproduced without any movements between frames.

    Quote Originally Posted by aqnuep View Post
    Not sure that's the root cause why you see a flickering effect if that's what you mean by z-fighting, but it's possible. Though the term z-fighting is actually what is used to describe the phenomenon when two pieces of geometry are almost at the same location in space and partially overlap each other on the screen due to precision limitations, which I can't seem to see how could happen due to Hi-Z if you don't actually have overlapping objects.
    The flickering effect is not related with 'z-fighting'. I was wrong using that term.

    The problem definitely located in the 'occlusion culling' pass.
    Actually I can reproduce the flickering with only cube.
    When the camera is very close to it's face I'm making some precessions and in the some orientation I can catch the flickering state.

    It may be problem is when some of vertices (A, B, C) of 'bounding box' is behind the frustum, and any of others is located farter than the fartest pixel of a intersection area (colored in the blue: current HiZ layer)?

    see picture:
    frustum.jpg

    What is happening with vertices behind the frustum in such case?
    Last edited by nimelord; 02-12-2019 at 05:59 AM.

  7. #7
    Senior Member Frequent Contributor
    Join Date
    Dec 2007
    Location
    Hungary
    Posts
    992
    My guess is that due to precision issues or the wrong use of comparison operations your object occludes itself every even frame.

    The solution is to make sure you use > vs >= as the culling criteria (as in my sample) and potentially apply a small bias (e.g. BoundingBoxDepth - EPSILON > HiZDepth) to account for any precision issues you might have in your pipe (e.g. due to using a lower precision depth buffer). Also make sure you correctly calculate the max for both the bounding box and the 4 samples from the Hi-Z image.

    In addition, you might want to look into your use (or lack of use) of depth clamping and its effect on your algorithm if you're having problems when the object intersects the near or far plane.
    Disclaimer: This is my personal profile. Whatever I write here is my personal opinion and none of my statements or speculations are anyhow related to my employer and as such should not be treated as accurate or valid and in no case should those be considered to represent the opinions of my employer.
    Technical Blog: http://www.rastergrid.com/blog/

  8. #8
    Member Contributor
    Join Date
    Nov 2017
    Posts
    93
    I'm pretty sure that case is the nearest BB vertices located behind the frustum , but other vertices (with positive w components) behind the farthest pixel of HiZ.
    I mean the case is when the camera inside the bounding box.

    For example see a stump:
    430464885535334.jpg


    When the camera is located to close the stump and stump surface covers whole frame, then camera located inside the BB.
    And in such position every pixel of stump surface located more close to camera then all other pixels of BB which located in front of near z pane of camera frustum.

    I'm using exact your vertex shader (excluding some names).

    When whole BB located in front of camera, then HiZ Occlusion Culling is working well.

    I'll use this case to implement auto tests on the GPU side.
    I think it is enough not to be like a blind kitten.
    Every time I do not know that is happening of GPU side.

    Daniel, thank you very much for the consultations.

    PS: If I will localize the bug on your side, I'll send you PM on this forum.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Proudly hosted by Digital Ocean