Despite improvements made to PBR texture loading with Ray Tracing in the latest preview, this issue remains persistent in build 1.21.100.23
Can confirm this is still an issue as of preview version 1.21.100.21.
Confirmed this issue affects stable release 1.21.80, it really should be fixed soon. May pose a photosensitivity hazard.
Attaching a video of the issue from my duplicate report:
[media]Even in preview 1.20.10.21 this issue is still present when Ray Tracing is enabled.
I've been able to observe its occurance in Preview 1.19.80.23.
Can confirm this report has been resolved erroneously, as the issue has not been fixed in 1.19.73.
Was this issue incorrectly resolved? 1.19.72 isn't available on Windows, and neither the previous hotfix 1.19.71 or the latest preview 1.19.80.22 have fixed the issue.
Affects latest preview 1.19.80.22.
Myself as well as many others would still like to get sort of calrification at all on why this issue won't be fixed. Evidently the model can be slightly edited in order to avoid any z-fighting on it's surfaces so from a third person perspective it doesn't seem reasonable not to fix this. Would appreciate any actual information on it though so that we have more than speculation to go off of.
Would you mind providing some context behind the decision to not fix this issue?
I would have an example if these blocks could apply PBR textures, but in order to get the same effect their models must be recreated and converted to blocks to demonstrate PBR capabilities. At the moment they function the same as entities and never apply any of the PBR textures that they are assigned.
Would you mind providing more information on the reasoning behind not fixing this issue?
No. That issue describes the z-fighting experienced by the different surfaces of the pot. This issue is similar to the issues with chests, trapped chests, ender chests and piston arms as all of these objects don't support PBR textures.
This issue is still present in release 1.19.62 and can still be reproduced by following the procedure outlined in this report.
I have not experienced this issue post 1.19.70 previews. Fix seems to have also worked on my end.
This issue appears to be fixed in preview 1.21.100.23