Page 8 of 10 FirstFirst ... 45678910 LastLast
Results 106 to 120 of 146

Click here to go to the first staff post in this thread.
Thread: Black Squares on planet surface

  1. Click here to go to the next staff post in this thread. #106
    Hey Cmdrs,

    Thank you very much for your efforts looking into this.

    These efforts are much appreciated and have been very helpful to making progress with this issue.

    I'll keep you updated when I hear more about this.

    We do anticipate that this will continue after the 3.0 update, but if you could please let me know when you do that would be helpful.

  2. #107
    Regarding latest drivers advice etc. etc. etc.

    I have had two operating system changes, three graphic card changes, now running with 4 Gb of VRAM and top, TOP spec PC... ALL with latest drivers kept religiously up-to-date,,,and...

    ...and STILL the curse of the black (and variations thereof) squares continues. PLEASE don't ask if my drivers are the latest.

    o7

  3. #108
    Originally Posted by QA-Mitch View Post (Source)
    We do anticipate that this will continue after the 3.0 update, but if you could please let me know when you do that would be helpful.
    My english is not perfect so I do struggle to understand what that exactly means.
    When I do what? Update my drivers perhaps? (I hate copy paste answers)

  4. #109
    Originally Posted by Baton View Post (Source)
    My english is not perfect so I do struggle to understand what that exactly means.
    When I do what? Update my drivers perhaps? (I hate copy paste answers)
    Basically "we doubt 3.0 will fix it, if you see black squares post 3.0 launch please report them" afaik.

  5. Click here to go to the next staff post in this thread. #110
    Sorry for the confusion Baton. This issue will most likely show up in 3.0, but there have been changes made that may have an impact of the bug so any additional information / screenshots about it would be helpful.

    hems303, while this specific issue isn't driver related, out of date drivers can have an impact of the performance which is why we advise everyone in general to ensure they're up to date to get the most out of the game.

  6. #111
    Originally Posted by QA-Mitch View Post (Source)
    Sorry for the confusion Baton. This issue will most likely show up in 3.0, but there have been changes made that may have an impact of the bug so any additional information / screenshots about it would be helpful.

    hems303, while this specific issue isn't driver related, out of date drivers can have an impact of the performance which is why we advise everyone in general to ensure they're up to date to get the most out of the game.
    Thank you for clarification. I will be happy to help in any way you need. My game became unplayable since last week on high and ultra settings over the surface, I am getting lots of squares everywhere. On medium is fine but it looks quite rough and with 1080 GTX I should be able to play on ultra.


  7. #112
    Setting terrain detail to low worked for me for over an hour (no squares), but sadly it did not last. Next day I logged in and got squares right away.




  8. This is the last staff post in this thread. #113
    Hi everyone,

    Thank you very much for all the effort you put into reporting this bug and the details you have provided. There is what I hope to be a solution for the issue lined up for testing and release not too long after 3.0. Thank you for your patience over this issue.
    Seeing as though you went to a lot of trouble in your investigations and helping to rule out possibilities for me, I wanted to tell you a little bit about what I found out. It was an awkward one to track down, the biggest problem being that it didn't reproduce at all on my team's computers.
    Render programmers have looked into some similar issues over the last few years and found some edge cases to fix up, but we never saw anything on the scale seen in these screenshots. I even have hardware similar to some of the reporters in this thread, but still saw nothing!

    We have mutliple types of builds to test and analyse. Each have different compiler optimisation settings, altering the balance between running speed and the amount of data we can get out of the game for debugging purposes.
    "Final" build is the one you get, with highest optimisation settings and no timing or profiling tags. There is also "Profile" build, which nearly identical to "Final", but with minimal profiling and debugging functionality so that we can still hunt down bugs.
    It turns out that this issue reproduces in "Final" only. It meant that getting any useful information out of the system to help guide our effects was problematic.

    The area of code this effect came from was the "patch lighting" system. Patches of landable terrain need to generate a lot of information before they're complete. There's the renderable patches which you see, physics patches that you collide with and then the patch lighting.
    This is the way of knowing which areas of the terrain should be shadowed according to the star light direction and the mountainous features. It needs to process a lot of neighbour patches to work, as the light may be coming in at a grazing angle, so very distant terrain features might be important.
    It also needs to know the results of its parent patch (it's a quadtree, each patch has four sub-patches, which each have four sub-sub-patches etc), and the neighbouring parent patches. An error in one of the upper level patches would trickle down to all the child patches, grand-child patches, and so on.
    After crowbaring some debugging aids into the Final build, and jury-rigging a debugging texture system into the patch lighting, I could start analysing values in the compute shader which runs on your GPU to figure out what was going on.

    It turned out to be related to which way the neighbouring parent patches occasionally thought they were rotated in space relative to the star light. It was occasionally mis-rotated due to a timing issue in the multi-threaded nature of the lighting data request system.
    In Profile builds, a previously unnoticed edge case could happen where the rotation would be used before it was ready, acting as if it was set to NAN (not a number). This would create a parent patch with no usable information, and so child patches would look normal.
    In Final builds for the same edge case, the same value would pass through to the GPU as zero. This would create valid lighting results for that parent patch, but from the wrong point of view. This would be seen as a dark square, whose results are passed down across the children. This meant that the dark square would persist from orbit to ground.
    This one difference in an uninitialised variable between two build types caused the headache you see above.

  9. #114
    great you sorted it out and thx for details, prost to the team

  10. #115
    Originally Posted by Anthony Ross View Post (Source)
    Hi everyone,

    Thank you very much for all the effort you put into reporting this bug and the details you have provided. There is what I hope to be a solution for the issue lined up for testing and release not too long after 3.0. Thank you for your patience over this issue.
    Seeing as though you went to a lot of trouble in your investigations and helping to rule out possibilities for me, I wanted to tell you a little bit about what I found out. It was an awkward one to track down, the biggest problem being that it didn't reproduce at all on my team's computers.
    Render programmers have looked into some similar issues over the last few years and found some edge cases to fix up, but we never saw anything on the scale seen in these screenshots. I even have hardware similar to some of the reporters in this thread, but still saw nothing!

    We have mutliple types of builds to test and analyse. Each have different compiler optimisation settings, altering the balance between running speed and the amount of data we can get out of the game for debugging purposes.
    "Final" build is the one you get, with highest optimisation settings and no timing or profiling tags. There is also "Profile" build, which nearly identical to "Final", but with minimal profiling and debugging functionality so that we can still hunt down bugs.
    It turns out that this issue reproduces in "Final" only.
    Ahh, what we refer to as a "Heisenbug" in the software company I work for - essentially a bug that disappears when you try to observe it!

    It meant that getting any useful information out of the system to help guide our effects was problematic.

    The area of code this effect came from was the "patch lighting" system. Patches of landable terrain need to generate a lot of information before they're complete. There's the renderable patches which you see, physics patches that you collide with and then the patch lighting.
    This is the way of knowing which areas of the terrain should be shadowed according to the star light direction and the mountainous features. It needs to process a lot of neighbour patches to work, as the light may be coming in at a grazing angle, so very distant terrain features might be important.
    It also needs to know the results of its parent patch (it's a quadtree, each patch has four sub-patches, which each have four sub-sub-patches etc), and the neighbouring parent patches. An error in one of the upper level patches would trickle down to all the child patches, grand-child patches, and so on.
    After crowbaring some debugging aids into the Final build, and jury-rigging a debugging texture system into the patch lighting, I could start analysing values in the compute shader which runs on your GPU to figure out what was going on.

    It turned out to be related to which way the neighbouring parent patches occasionally thought they were rotated in space relative to the star light. It was occasionally mis-rotated due to a timing issue in the multi-threaded nature of the lighting data request system.
    In Profile builds, a previously unnoticed edge case could happen where the rotation would be used before it was ready, acting as if it was set to NAN (not a number). This would create a parent patch with no usable information, and so child patches would look normal.
    In Final builds for the same edge case, the same value would pass through to the GPU as zero. This would create valid lighting results for that parent patch, but from the wrong point of view. This would be seen as a dark square, whose results are passed down across the children. This meant that the dark square would persist from orbit to ground.
    This one difference in an uninitialised variable between two build types caused the headache you see above.
    Bravo for tracking that down and massive thanks for sharing the process with us (I actually meant to ask if you could do this since I know a few of us are really interested to understand what's going on here).

    Fingers crossed for 3.x.

    o7

  11. #116
    Originally Posted by Anthony Ross View Post (Source)
    Hi everyone,

    Thank you very much for all the effort you put into reporting this bug and the details you have provided. There is what I hope to be a solution for the issue lined up for testing and release not too long after 3.0. Thank you for your patience over this issue.
    Seeing as though you went to a lot of trouble in your investigations and helping to rule out possibilities for me, I wanted to tell you a little bit about what I found out. It was an awkward one to track down, the biggest problem being that it didn't reproduce at all on my team's computers.
    Render programmers have looked into some similar issues over the last few years and found some edge cases to fix up, but we never saw anything on the scale seen in these screenshots. I even have hardware similar to some of the reporters in this thread, but still saw nothing!

    We have mutliple types of builds to test and analyse. Each have different compiler optimisation settings, altering the balance between running speed and the amount of data we can get out of the game for debugging purposes.
    "Final" build is the one you get, with highest optimisation settings and no timing or profiling tags. There is also "Profile" build, which nearly identical to "Final", but with minimal profiling and debugging functionality so that we can still hunt down bugs.
    It turns out that this issue reproduces in "Final" only. It meant that getting any useful information out of the system to help guide our effects was problematic.

    The area of code this effect came from was the "patch lighting" system. Patches of landable terrain need to generate a lot of information before they're complete. There's the renderable patches which you see, physics patches that you collide with and then the patch lighting.
    This is the way of knowing which areas of the terrain should be shadowed according to the star light direction and the mountainous features. It needs to process a lot of neighbour patches to work, as the light may be coming in at a grazing angle, so very distant terrain features might be important.
    It also needs to know the results of its parent patch (it's a quadtree, each patch has four sub-patches, which each have four sub-sub-patches etc), and the neighbouring parent patches. An error in one of the upper level patches would trickle down to all the child patches, grand-child patches, and so on.
    After crowbaring some debugging aids into the Final build, and jury-rigging a debugging texture system into the patch lighting, I could start analysing values in the compute shader which runs on your GPU to figure out what was going on.

    It turned out to be related to which way the neighbouring parent patches occasionally thought they were rotated in space relative to the star light. It was occasionally mis-rotated due to a timing issue in the multi-threaded nature of the lighting data request system.
    In Profile builds, a previously unnoticed edge case could happen where the rotation would be used before it was ready, acting as if it was set to NAN (not a number). This would create a parent patch with no usable information, and so child patches would look normal.
    In Final builds for the same edge case, the same value would pass through to the GPU as zero. This would create valid lighting results for that parent patch, but from the wrong point of view. This would be seen as a dark square, whose results are passed down across the children. This meant that the dark square would persist from orbit to ground.
    This one difference in an uninitialised variable between two build types caused the headache you see above.
    Fantastic write-up!

    So basically you were caught initially in a catch-22 - in order to debug the problem, you needed to work with a debug/dev build, but it was the debug/dev build which was hiding the bug from you.

    Love it.

  12. #117
    Originally Posted by Anthony Ross View Post (Source)
    Hi everyone,

    Thank you very much for all the effort you put into reporting this bug and the details you have provided. There is what I hope to be a solution for the issue lined up for testing and release not too long after 3.0. Thank you for your patience over this issue.
    Seeing as though you went to a lot of trouble in your investigations and helping to rule out possibilities for me, I wanted to tell you a little bit about what I found out. It was an awkward one to track down, the biggest problem being that it didn't reproduce at all on my team's computers.
    Render programmers have looked into some similar issues over the last few years and found some edge cases to fix up, but we never saw anything on the scale seen in these screenshots. I even have hardware similar to some of the reporters in this thread, but still saw nothing!

    We have mutliple types of builds to test and analyse. Each have different compiler optimisation settings, altering the balance between running speed and the amount of data we can get out of the game for debugging purposes.
    "Final" build is the one you get, with highest optimisation settings and no timing or profiling tags. There is also "Profile" build, which nearly identical to "Final", but with minimal profiling and debugging functionality so that we can still hunt down bugs.
    It turns out that this issue reproduces in "Final" only. It meant that getting any useful information out of the system to help guide our effects was problematic.

    The area of code this effect came from was the "patch lighting" system. Patches of landable terrain need to generate a lot of information before they're complete. There's the renderable patches which you see, physics patches that you collide with and then the patch lighting.
    This is the way of knowing which areas of the terrain should be shadowed according to the star light direction and the mountainous features. It needs to process a lot of neighbour patches to work, as the light may be coming in at a grazing angle, so very distant terrain features might be important.
    It also needs to know the results of its parent patch (it's a quadtree, each patch has four sub-patches, which each have four sub-sub-patches etc), and the neighbouring parent patches. An error in one of the upper level patches would trickle down to all the child patches, grand-child patches, and so on.
    After crowbaring some debugging aids into the Final build, and jury-rigging a debugging texture system into the patch lighting, I could start analysing values in the compute shader which runs on your GPU to figure out what was going on.

    It turned out to be related to which way the neighbouring parent patches occasionally thought they were rotated in space relative to the star light. It was occasionally mis-rotated due to a timing issue in the multi-threaded nature of the lighting data request system.
    In Profile builds, a previously unnoticed edge case could happen where the rotation would be used before it was ready, acting as if it was set to NAN (not a number). This would create a parent patch with no usable information, and so child patches would look normal.
    In Final builds for the same edge case, the same value would pass through to the GPU as zero. This would create valid lighting results for that parent patch, but from the wrong point of view. This would be seen as a dark square, whose results are passed down across the children. This meant that the dark square would persist from orbit to ground.
    This one difference in an uninitialised variable between two build types caused the headache you see above.
    Interesting, thanks. But how does it explain this?

  13. #118
    Originally Posted by Anthony Ross View Post (Source)
    Hi everyone,
    Anthony, thank you for your time and for sharing this information with us. I will slow down my efforts to show how this bug makes my life as a pilot miserable, now that I know the fix is on the horizon

  14. #119
    This is awesome. Thank you Dr Ross.

  15. #120
    [deNiro]You! You're good, you.[/deNiro]

Page 8 of 10 FirstFirst ... 45678910 LastLast