-
Notifications
You must be signed in to change notification settings - Fork 345
Webgl rendering
kripken edited this page Sep 5, 2012
·
20 revisions
(This page is out of date; this part of the project was completed successfully.)
We will manually port the rendering code to use a subset of OpenGL we can easily translate to WebGL.
- See here for ehsan's demo of his work on the Emscripten OpenGL ES 2.0 to WebGL bindings.
- See the WebGL docs zfor differences between WebGL and OpenGL ES 2.0, and here for general OpenGL/OpenGL ES 2.0 differences. For GLSL differences between OpenGL ES 2.0/WebGL and desktop OpenGL, see here.
- WebGL calls cost more than OpenGL native calls, because of JS<->native code communication. We might need to optimize code to make fewer calls, or avoid certain types of rendering. For example, if some visual effect (explosions? water?) constantly uploads vertex data each frame, that might be slow. We should check if it is, because it might not be, but if it is then a simple optimization might be to previously upload all the needed values, etc.
The first goal is to not modify the Sauerbraten code at all, as much as possible. We emulate functionality in the emscripten GL emulation layer.
Later on it might make sense to optimize the code to avoid emulation overhead. For example setting vertex attrib pointers once and then calling drawElements many times is better than the emulation figuring out that nothing changed and it does not need to completely re-set the rendering state
###(Likely) Avoidable Limitations
- mdlalphatest is not supported. We can add support for it with something like
if(gl_FragColor.a < ..) discard;, however that means adding this code + a varying to every single shader. So for now we should not use models with alpha (like tree leaves etc.)
- shadowmapping is tied to occlusion queries (see
rendergeom), it isn't clear what we should do there.
- Browsers can't modify the screen resolution. So if we render to the whole screen, we will use that resolution, which might be slower than a lower resolution. Should investigate the possibility to render to a smaller size and blow it up to the actual resolution, but that might look horrible.