Sean (May 21 2019 at 13:58): Sean (May 21 2019 at 13:58):I've been working on debugging the regress_rtwizard_D test case failure and wanted to shared some updates. Looks like the failures are genuine mistakes, and possibly that even the committed reference is wrong. Looks like the occlusion modes aren't testing/applying the edge pixels correctly.
Sean (May 21 2019 at 14:04):This shows the three occlusion modes (regress is using om=1) which are on the top row. Two leftmost images are the two specified occlusion objects. Notice the occluded pixels on the hub cylinders in om=1 (differences shown in the second column, bottom row). Remaining two black images is supposedly the unoccluded edge pixels and a default edge rendering.
Screen-Shot-2019-05-21-at-9.56.12-AM.png
Sean (May 21 2019 at 14:05):Zooming in, you can see the hub cylinder pixels that are partially occluded, partially not occluded.
Screen-Shot-2019-05-20-at-11.13.35-PM.png
Sean (May 21 2019 at 14:06):All differences with the reference image accentuated 2x. Screen-Shot-2019-05-20-at-8.17.41-PM.png
Sean (May 21 2019 at 14:18):Occlusion modes om=2 and om=3 are even worse (upper two right images), but I suspect a symptom of the same problem. However it is determining occlusion is inconsistently getting applied.
Intuitively, it seems as though there's some tolerance or logic fault with the overlay edge hit points being actually on the overlay objects. I would expect all edges on occluded objects to either draw or not be drawn, probably the prior, for om=1. For om=2, I would probably expect all edges to draw and the unoccluded objects to show where not on edges. For om=3, I would expect all edges to draw, unoccluded to show where not on edges, and occluded to show dithered (this part seems part seems correct now).
So it's 1) not drawing edges when it always should and 2) incorrectly determining that an occlusion has occurred.
Sean (May 21 2019 at 14:22):I've ruled out rtwizard or the framebuffer doing anything wrong.
Anyone looking to help debug this, the file in question is src/rt/viewedge.c for rtedge. Running "ctest -R regress.*D" will run the test case that fails.
Alternatively, you can run these manual steps to reproduce the bug:
bin/fbserv 0 /dev/Xl &
bin/rt -B -F 0 -V 1.0 -R -A 0.9 -p 0 -C 255/255/255 -c "{viewsize 6.787387573242200e+03}" -c "{orientation 2.480973490458727e-01 4.765905732660484e-01 7.480973490458729e-01 3.894348305183902e-01}" -c "{eye_pt 1.845382932318572e+04 1.175461729657747e+04 1.044847417329058e+04}" share/db/m35.g component/suspension component/power.train
bin/rtedge -B -F 0 -V 1.0 -R -A 0.9 -p 0 -c "set fg=0,0,0" -c "set om=1" -c "set oo=\\\"component/power.train component/suspension\\\"" -c "viewsize 6.787387573242200e+03" -c "orientation 2.480973490458727e-01 4.765905732660484e-01 7.480973490458729e-01 3.894348305183902e-01" -c "eye_pt 1.845382932318572e+04 1.175461729657747e+04 1.044847417329058e+04" share/db/m35.g component
Sean (May 22 2019 at 14:34):UPDATE! This problem is now FIXED. See recent commits for details, but short summary is occlusion objects that were also in the render object lists ended up occluding themselves (inconsistently due to floating point fuzzing). Fix was to detect overlapping/exact occlusion and not treat that as occluded, thus all exterior exposed edges will get drawn.
Last updated: Oct 09 2024 at 00:44 UTC