Thanks, I didn’t know it was a GL thing initially. After seeing a bunch of examples of glScissor, I don’t see why in my above example the area outside the scissor is all black. How do I draw the original scene, then draw it again in the scissor area on top of the original scene?
But still no luck. In mine I’m calling setScissor and setViewport before each render call. What am I still missing?
EDIT: Ah, I see, I need to call the setScissor and setViewport functions before each call, otherwise the next animation frame will have the wrong scissor. And setScissorTest(true) can be called in init code.
@Mugen87 So any time we use scissor to draw more stuff than just a single render call, it will always be more expensive.
Is there a way to draw something only once, then use scissor to update only part of the screen so that we can get better performance?
For example, suppose we draw something to the whole display in the first frame, but all frames after that we only want to update the bottom right corner (suppose the only thing changing is a spinning logo in the bottom right corner, otherwise nothing else changes at all).
I’m guessing we’d have to render the initial scene to a texture but still have to draw the texture each frame, then just draw in the bottom right corner with scissor. Is that the best way to only update parts of the screen?
if you really have a large amount of static content that is not affected by camera movement or the like, you can render it once into a texture and then each frame the first thing you render is a full screen quad with that texture applied.
And then we render only part of the screen with a scissor.
Look for the “Perspective scrolling test” example, then scroll horizontally, and the WebGL ducks are clipped (thanks to scissor).
Hm. Do you have any reason to believe that this is because of scissor? This is expected behavior for a canvas in a div which has style.overflow="scroll".
@EliasHasle Sorry for the late reply, but on that page, there is only a single canvas covering the whole window, and each of the multiple 3D scenes is drawn onto that single canvas, including the scene that appears cut off when scrolled.
This screenshot shows the only canvas in the inspector, highlighted in blue, covering the whole page:
The reason for this technique is that, if there are too many WebGL canvases on a page (on my system, the limit is 32), then adding any more than 32 causes the first ones to crash in FIFO order due to the limit. So, to prevent that issue, all the scenes share a single canvas, and they are rendered to a portion of the single canvas based on the position where they should be based on the DOM container positions.
