A quick story about how this evolves.
More than 4 months ago, I finally decided to take my chance at a GPU passthrough in a Windows 10 VM on my Linux workstation.
<technical rant>
To make the story longer, the reason I took this decision was that I noticed that my Windows 7 partition didn't want to boot after I changed my AMD CPU (with one that had an integrated GPU on it). I could live with this until I couldn't: due to some older configurations, I have a large amount of diskspace configured as NTFS filesystems. Unfortunately, the only known and reliable way to fix the NTFS filesystems is by using Microsoft's chkdsk program (no open source Linux tools available for the task).
So when some of the larger size installed games (Elite: Dangerous and Eve Online being some of the culprits) started giving errors during their updates, I found I had to get access to a running Windows instance to chkdsk and fix the damage. That was the moment when I noticed that even the USB installation image of Windows 7 wouldn't boot on the new hardware. Booting a Windows 10 installation USB image just to get access to the chkdsk became the norm.
Until the day I asked myself why wouldn't I replace the Windows 7 installation with a new Windows 10 installation. Of course, the answer was that I wouldn't want to invite any uninvited guests in my system. Well, that turned out not to be a problem: because _the only_ reason that Windows instance is to be installed would be to give me access to the single tool I need not very often, there would also be no reason for that Windows instance to _ever_ access internet. Thus the whole setup occurred with the network cable unplugged. Then, before and after plugging it back in, I made sure the network card is disabled, and stays so.
To end this part of the story, installing Windows 10, also revealed that the HDR monitor that _never_ allowed me any HDR experience in Windows 7, is doing it without any restrictions in Windows 10. The conclusion that my VM should also be a Windows 10 one came naturally. And the network setup under Linux was way easier to prevent _it_ from getting to the Internet, but allow _me_ to exchange info over the network (mouse and keyboard integration, being the most necessary).
</technical rant>
Back to this Oolite topic.
All dandy and nice, I can seamlessly move my mouse around my Linux X session, and my Windows 10 VM output, bonus, the HDR monitor works HDR under the VM as it is not able under X.
Alas, when I tried to run Oolite on my new integrated AMD GPU I left for Linux, this is what I've got:
The same, on the NVidia GPU (even previously on Linux, or in the VM under Windows 10) would look like this (expected):
It took me these 4 months to finally realize what didn't match on AMD in the shader I was trying to tweak. A very long of this time was taken by my doubts that I missed some magic drivers for the integrated AMD GPU and that the open source versions didn't raise up to the needed level.
I ran the Windows version under Wine, with the same result. Moreover, any other game I usually run under Wine, would flawlessly run without any visual glitch. I had to start revisiting the shader code, after I installed the SDL2 Oolite branch, and the issue was present there, too. The second screenshot above is actually taken on the integrated AMD GPU after i figured out what the fix was.
So right now I'm back to trying to find a way to do the right thing with the normal map in the shader.
Meanwhile, I also found a way for my Blender attempts to better mimic a gas giant. This is a Blender screenshot, with the big one being my result and the lower ones references (the colour palette is directly taken from one of the NASA's Jupiter mp4 they have; also I didn't put any "storm" in at this time):
So BPlanets is not dead, but its advancing is very slow.
