I’m experiencing an anomaly with Wallpaper.
If I use wallpaper on Rendered Viewport, the image is being displayed properly.
But, when I changed the Viewport to Raytrace, the image is being displayed vertically flipped.
I’m currently using HP Zbook 17 G6 with Intel 9750H and Quadro T1000 on 471.41 nvidia driver under Win 10. Tried to revert back to many earlier drivers, still it gave me the same result.
Anyone experiencing the same problem? Is this a known bug?
Really appreciate it in advance.
BTW, I just tried to render it, it gave me the same vertically flipped result
Just a workaround to solve quickly: flip the image in a photo editor and save it as a copy.
Use the flipped image as background to obtain a correct render.
This is on my list to fix: RH-65054 Wallpaper is inverted when Rendering
Thanks for the kind suggestion. I actually had tried it, but the funny thing is, sometimes it inverted image as well, and sometime it did good
Thanks Nathan. I guess I’m not facing this alone. However, I tried it on my Lenovo P40, and couldn’t replicate the issue. Everything seemed to be working properly. However, my HP Z820 produced the same result as my Zbook 17. Very strange
You are probably using different versions of Rhino. This is the result of a fix I made at the begin of the summer for another issue.
The change effectively sets the camera upside down, but I hadn’t accounted for the wallpaper.
Thanks Nathan. I’m currently using Rhino 7 SR8 with Windows 10 ver 2004 build 19041.
I’m still trying few things hopefully could work as a workaround. The rendering result is so much better with raytrace compares to rendered viewport. The issue is somehow annoying
I made a commit to fix this issuie. It should appear in Rhino 7.9 if all goes well.
The commit: Ensure wallpaper image is created the correct way up. · mcneel/RhinoCycles@5025414 · GitHub
Excellent, Nathan! I know that it looks simple outside as flip, but could be hair pulling inside.
Fortunately this case was easy to do (:
As fallout of the earlier mentioned fix there is now a problem also with two-point perspective. It was a bit more involved, but I’ll be committing a fix for that one too soon (: