I tried using RTT with GetTextureDataAsync to get a snapshot of the current viewport, but I got an incorrect image that looked cropped. After debugging, I found that the problem was with the camera’s Target. I tried using another model (both are the same helmet, but one is the original model and the other is processed by GLTF Transform), and the results are different, which makes me confused
By the way, target and position are obtained from my project
Here is PG: https://playground.babylonjs.com/#FAN4GS#3
(BTW, why not use CreateScreenshotUsingRenderTarget? This seems like a good use case for it
The version used in my local project is 8.10.0. At first I suspected it was a version problem, so I did an experiment with PG, but I found that the problem still exists. When I load the model of url2 and get a snapshot, the image downloaded on Windows Chrome is as follows
By the way, the difference between the url2 model and url1 is that url2 has been processed by GLTF Transform.
This is also a solution. I will consider implementing it in this way later, but what puzzles me is why this happens when I manually trigger the RTT render and use GetTextureDataAsync to get the data.
Since I don’t have a macOS device, I can’t reproduce the same situation as yours, but the snapshot you obtained shows a black area that looks like a clipping surface. On my device, the snapshot I obtained is a large black area. Since the alpha of clearColor in my RTT is set to 0, when it doesn’t capture the objects in the render list, it should return a fully transparent image, right?
Oh, hey, nice catch! I totally missed the artifact.
In a second here, I’ll switch to a Windows machine and see if the issue repros there.
Also wonder if CreateScreenshotUsingRenderTarget will have the same issue, since its implementation is essentially the same as the PG you provided…hmm…
On my device, the snapshots obtained by CreateScreenshotUsingRenderTarget are as expected. I guess I missed some settings that caused the manual triggering of RTT rendering to not obtain the expected snapshots. It’s confusing.
1 Like
After investigating, the TL;DR explanation is that this is a synchronization issue related to rendering, but the correct way to address it– which involves timing the RTT render “around” the regular render loop– is nuanced and tricky 
So functions like CreateScreenshotUsingRenderTarget abstract this sync complexity away, in an optimal way.
1 Like
Can you provide me with a PG that manually calls RTT rendering? I want to know how to fix it based on my current one so that I can pinpoint the problem when I encounter it in the future.
This PG is akin to how it’s done in our screenshot tool:
2 Likes
This is what is downloaded when I run the PG right now (on MacOS, Chrome):
