New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
getSubImage / getViewSubImage need to be called every frame #174
Comments
It is pretty much already a requirement to call getSubImage / getViewSubImage every frame; if you don't then it means you haven't rendered anything and the previous frame might be reprojected. We just need to make it more clear in the spec, afaiu. |
It seems strange that textures become valid again at the beginning of the frame before |
That is not correct. Only projection layers have a SHOULD that they should refresh each frame (by calling |
I think there is a confusion here. Who said the textures become valid BEFORE getSubImage / ViewSubImage is called? No, in my understanding the call to getSubImage returns you a valid texture to use; until then - you don't have a texture to render to. Even the fact that it returns the same JS object (WebGLTexture) doesn't change that: until you call getSubImage that texture is "invalid".
It is correct for ANY layer which you want to update. If you did not call getSubImage then it will be reprojected. It is just much less likely that projection layer got skipped the update, but otherwise the behavior is the same for all layers. |
OK. I think we're actually in agreement: |
Yes! Sorry, my wording was confusing. |
@Artyom17 Do we need to wait until the WebGL group defines this behavior or can we describe it in the layers spec? |
Also, are there public notes from that meeting that we can refer to? |
I am not sure if the notes are public, but I'll send you a link. |
/agenda What should be the behavior of the color and depth textures? |
I agree with @cabanier that either we should rename this issue or open a new one about how webxr texture state should change in rAFs. |
I'm still waiting from @toji. I'm unsure how we should phrase the behavior of these textures. |
Addressed with PR #201 |
On virtual WebGL face-to-face we discussed ways to prevent the textures to be renderable \ sampleable out of rAF. We (Brandon, Rafael, Jeff, me) agreed that the texture should become "invalid" at the end of the rAF and while the WebGLTexture object remains the same, we need to rebind it to make it valid again. I am going to make this work in Oculus Browser, and we need to straighten the spec language about this. The related issue is #101
CC @cabanier @toji @RafaelCintron
The text was updated successfully, but these errors were encountered: