Use array buffer for all drawing calls

[levinli303]

There are places where GL functions like glVertexAttribPointer are called with pointer address rather than offset. Might it be a good idea to replace all of them with array buffer when/if we are going to revamp the render engine some time?

I found out about this in WebGL that you have to always bind an array buffer, or they will just not render and log warning in the browser console.

As Emscripten supports WebGL and SDL, it is actually not hard to port to make a web version of Celestia.

[levinli303]

[375gnu]

agree. this is a good idea, but straightforward replacement will kill performance. and actually emscripten supports this old mode, there is an option to enable it:

If your application renders geometry from client side memory, it will need to build with the linker flag -s FULL_ES2=1. This mode is convenient to ease porting of new codebases, however WebGL itself does not support rendering from client side memory, so this feature is emulated. For best performance, use VBOs instead and build without the -s FULL_ES2=1 linker flag.

[levinli303]

@375gnu Great! now it actually works just like the other ES builds.

These are generating warning, I believe it is also happening at least on iOS build when validation is enabled. glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, texAddress); glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, texAddress); glTexParameterfv(target, GL_TEXTURE_BORDER_COLOR_OES, bc);

And the other warnings are GL ERROR :GL_INVALID_OPERATION : glDrawElements: attempt to access out of range vertices in attribute 0 which does not have call stack, and this warning is not showing in Safari.

[375gnu]

GL_TEXTURE_BORDER_COLOR_OES

is not supported in pure GLES v2 (and hence WebGL 1.0). we need to check if it's mandatory, maybe we can live without it

[levinli303]

yeah and also GL_CLAMP_TO_BORDER_OES. I added defines with values from other platforms for the two to make it pass compile. Well just like the iOS build I don't see any problem so far.

[levinli303]

With the recent changes, the WebGL port is much better now, still missing rectangles

[375gnu]

so now we have 2 remaining pieces of code to update: rectangles and model drawing (index buffers) and then fix performance regressions caused by migration.

[375gnu]

Core is done in #1582. The only remaining piece is Celx::GL module.

[375gnu]

@levinli303 @ajtribick what do you think about hosting webgl port at celestia.space as an online demo?

[levinli303]

@levinli303 @ajtribick what do you think about hosting webgl port at celestia.space as an online demo?

sounds good. a key thing would be to get a tiny data ready for the use in web, as it wouldn't be good for it to be 300m. i have some small changes for it to be used in emscripten, which also need to be upstreamed.

[levinli303]

i have updated the https://celestia.mobi/web to use the latest code and disabled FULL_ES2

[375gnu]

nice. i have > 60 fps. there are some artifacts on saturn, perhaps due to missing CLAMP_TO_BORDER texture mode, but else seems to be good.

[levinli303]

nice. i have > 60 fps. there are some artifacts on saturn, perhaps due to missing CLAMP_TO_BORDER texture mode, but else seems to be good.

yeah error is logged into the browser console. Another thing is that I did not use libepoxy as i think it depends on dlopen (i suppose gl calls are compiled into the wasm file by default), and dlsym (symbols are not glXXX, but rather emscripten_glXXX). maybe we should support the use of direct GLES calls without libepoxy?

[375gnu]

It should be possible, but we may need some extensions, but none of them is mandatory