From fa4c55a21abd856e3459784415cbebd2a14e4069 Mon Sep 17 00:00:00 2001 From: Peter Mitrano Date: Mon, 6 Mar 2023 02:09:35 +0000 Subject: [PATCH] found another potential typo --- doc/programming/visualization.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/programming/visualization.rst b/doc/programming/visualization.rst index 517afa6a..4ebc8c76 100644 --- a/doc/programming/visualization.rst +++ b/doc/programming/visualization.rst @@ -411,7 +411,7 @@ there may be no window framebuffer). From the perspective of OpenGL, there are important differences between the window framebuffer and offscreen framebuffer, and these differences affect how the MuJoCo user interacts with the renderer. The window framebuffer is created and managed by the operating system and not by OpenGL. As a result, properties such as resolution, -double-buffering, quad-buffered stereo, mutli-samples, v-sync are set outside OpenGL; this is done by GLFW calls in our +double-buffering, quad-buffered stereo, multi-samples, v-sync are set outside OpenGL; this is done by GLFW calls in our code samples. All OpenGL can do is detect these properties; we do this in mjr_makeContext and record the results in the various window capabilities fields of mjrContext. This is why such properties are not part of the MuJoCo model; they are session/software-specific and not model-specific. In contrast, the offscreen framebuffer is managed entirely by OpenGL,