Out of sheer curiosity -- does this work on the raspberry pi?

[keeganbrown]

just wondering if anyone has tried to build it.

[mikeseven]

I never tried but I don't see any reason why not. All dependencies are
typical Linux libraries so they should work on the PI. Rebuilding the node
module is not an issue too once nodejs is built on the PI.

So all you need are: AntTweakBar, FreeImage, GLEW, GLFW3. You can install
them with apt-get, except AntTweakBar that you may need to download and
build yourself.

I'd be interested to know.

-- mike
On Sep 11, 2014 12:43 PM, "ΚΣΣGΔΠ ΒRΘΨΠ" [email protected] wrote:

just wondering if anyone has tried to build it.

—
Reply to this email directly or view it on GitHub
#24.

[keeganbrown]

If I happen to get a chance, I'll build it and let you know how it goes.

[diogoviannaaraujo]

Anyone has any news on this?

[carli2]

I assume it won't work. Raspberry Pi has only GLES drivers. Hence this library links against GL which is not available on Raspberry Pi. It creates its window with SDL and it needs additional code to activate GLES on SDL.

It could be possible to adapt this library, but no one did yet.

[mikeseven]

Actually it should work but I never tried. Indeed, webgl was made for Opengl es but Opengl initialization is different than of GL es.

I have a PI and PI2, I should try! With node4 release, I started porting node-webcl to nan2. Once done, I'll try on PI...can't wait very exciting!!!

--mike

On Sep 20, 2015 8:38 AM, carli2 [email protected] wrote:

I assume it won't work. Raspberry Pi has only GLES drivers. Hence this library links against GL which is not available on Raspberry Pi. It creates its window with SDL and it needs additional code to activate GLES on SDL.

It could be possible to adapt this library, but no one did yet.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/24#issuecomment-141797210.

[timonsku]

Any news on this? Would be very very intersting to have this ported on the Pi2!
The only option one has for JS based graphics programming is the Epiphany browser which is less than optimal.

[mikeseven]

There is substantial work to be done to port to GL ES but once done it would work on any mobile device too.
It would be a great project for an internship. Anybody interested?

--mike

On Thu, Dec 3, 2015 at 5:10 AM -0800, "PTS93" <[email protected]mailto:[email protected]> wrote:

Any news on this? Would be very very intersting to have this ported on the Pi2!
The only option one has for JS based graphics programming is the Epiphany browser which is less then optimal.

Reply to this email directly or view it on GitHubhttps://github.com//issues/24#issuecomment-161634048.

[lukaaash]

When it comes to OpenGL ES 2 support, Raspberry PI is not a typical Linux. As far as I know, there is no GL support in X on PI and one has to use EGL and Broadcom dispman API to initialize a context. There is indeed FreeImage, GLFW3 and GLEW in Raspbian, but it looks like GLFW3 is somewhat problematic. And even if X and GLFW3 works, it seems like a hack - for example, GL window content stays on top doesn't pay attention to HDMI overscan settings, which makes the window frame and contents misaligned (Minecraft PI suffers from this issue, for example).

I would actually prefer WebGL on PI without X, although that pretty much rules out GLFW3 (although that can be made optional), which breaks this module's architecture. Unless we make node-glfw on PI use different APIs internally, and I guess mikeseven might not like such a hacky approach :-)

Still, I would really love to have WebGL on PI/PI2. I guess I will give this a try and then let's see where this takes us.

[timonsku]

With the port of Wayland for the Raspberry Pi we can have WebGL on the Pi without these hacks. There is a demo of that here https://github.com/Metrological/buildroot
https://www.youtube.com/watch?v=vpWYOu2NSF4

[mikeseven]

Very exciting. Indeed, in a GL ES environment, there is no need for all the machinery for GL desktop and thus glfw3 is probably overkill. All we need is creating a window and getting input after all.

--mike

On Sat, Jan 2, 2016 at 5:16 AM -0800, "PTS93" <[email protected]mailto:[email protected]> wrote:

With the port of Wayland for the Raspberry Pi we can have WebGL on the Pi without these hacks. There is a demo of that here https://github.com/Metrological/buildroot

Reply to this email directly or view it on GitHubhttps://github.com//issues/24#issuecomment-168390326.

[lukaaash]

I agree that Wayland would be the ultimate solution, but I did a bit of searching and got the impression that Wayland on Pi is still somewhat experimental and it's only moving forward slowly (please correct me if I'm wrong).

On the other hand, getting the hacky solution to work turned out to be quite simple - check out the changeset for node-webgl and the changeset for node-glfw.

At the moment, the Pi variant of node-glfw only provides the bare minimum needed for node-webgl to run - it doesn't provide any kind of input and doesn't come with AntTweakBar support.

On Raspbian with one of the recent versions of Node.js installed (I used v4.2.1), getting the Pi-enabled version to work is very simple:
npm install lukaaash/node-glfw
npm install lukaaash/node-webgl

Most of node-webgl/test work (except cube.js which requires AntTweakBar). Some examples work as well (wavefront.js and tunnel.js).

By the way, I'm not interested in X support very much at the moment. I need support for Raspberry Pi Touchscreen Display and because multi-touch is not even supported on X in Raspbian, getting glfw3 to work would provide no benefit to me at all. If someone else adds support for X (or Wayland), I would still love to keep console support as an alternative.

[mikeseven]

Thanks Lukas. Great work.

I've been looking for time to make a replacement in js/webgl of AntTweakBar with something similar to provide html like dialogs and gui.
Then all we need is to translate input events to glfw event system, from touch screens or even gpios on the pi.

--mike

From: Lukas Pokorny
Sent: Saturday, January 2, 13:20
Subject: Re: [node-webgl] Out of sheer curiosity -- does this work on the raspberry pi? (#24)
To: mikeseven/node-webgl
Cc: Bourges-sevenier, Mikael

I agree that Wayland would be the ultimate solution, but I did a bit of searching and got the impression that Wayland on Pi is still somewhat experimental and it's only moving forward slowly (please correct me if I'm wrong).

On the other hand, getting the hacky solution to work turned out to be quite simple - check out the changeset for node-webglhttps://github.com/lukaaash/node-webgl/commit/5b9396c4ec687bf615cd03e49164ebdfe5675d07 and the changeset for node-glfwhttps://github.com/lukaaash/node-glfw/commit/2f480e255957b5d615c9f83a76bc8ba87a7588d6.

At the moment, the Pi variant of node-glfw only provides the bare minimum needed for node-webgl to run - it doesn't provide any kind of input and doesn't come with AntTweakBar support.

On Raspbian with one of the recent versions of Node.js installed (I used v4.2.1), getting the Pi-enabled version to work is very simple:
npm install lukaaash/node-glfw
npm install lukaaash/node-webgl

Most of node-webgl/test work (except cube.js which requires AntTweakBar). Some examples work as well (wavefront.js and tunnel.js).

By the way, I'm not interested in X support very much at the moment. I need support for Raspberry Pi Touchscreen Display and because multi-touch is not even supported on X in Raspbian, getting glfw3 to work would provide no benefit to me at all. If someone else adds support for X (or Wayland), I would still love to keep console support as an alternative.

Reply to this email directly or view it on GitHubhttps://github.com//issues/24#issuecomment-168428839.

[timonsku]

Oh thats really cool! I will give that a try.

True Wayland is still not really stable yet but the foundation is working on it afaik and they want to make Wayland the standard window manager at some point.

@input you could have a look at OpenFrameworks on the Pi, they use GLFW aswell. Might be helpful.
The EGL window code is also worth a look regarding handling input on the Pi.

https://github.com/openframeworks/openFrameworks/blob/master/libs/openFrameworks/app/ofAppGLFWWindow.h
https://github.com/openframeworks/openFrameworks/blob/master/libs/openFrameworks/app/ofAppGLFWWindow.cpp

https://github.com/openframeworks/openFrameworks/blob/master/libs/openFrameworks/app/ofAppEGLWindow.h
https://github.com/openframeworks/openFrameworks/blob/master/libs/openFrameworks/app/ofAppEGLWindow.cpp

[dav-m85]

Agreeing with @lukaaash, GL ES2 without window manager is a way I would like to explore as well.

[mikeseven]

Me too! I just don't have any bandwidth for now.
I do think it's totally doable. (And remove AntTweakBar too).

--mike

On Mon, Feb 29, 2016 at 5:05 PM -0800, "dav-m85" <[email protected]mailto:[email protected]> wrote:

Agreeing with @lukaaashhttps://github.com/lukaaash, GL ES2 without window manager is a way I would like to explore as well.

Reply to this email directly or view it on GitHubhttps://github.com//issues/24#issuecomment-190476133.

[lukaaash]

@PTS93 I'm sure we could add GLFW and even Wayland (which sadly seems to be taking a long time) support as well, but I don't have time to look into that myself at the moment. It's just a hobby project for me. But if anyone would like to work on this, feel free to start with my fork and enhance it.

@dav-m85 and @mikeseven OK, so where do we go from here? My fork already runs on Raspberry Pi 2 (and I guess it would work on Pi 1 and Pi 3 as well), but it's not capable of handling any kind of input yet. I have been slowly working on that - I'm almost done with adding support for mouse and multi-touch (for the official Raspberry Pi Touch Display) through Linux input subsystem, and basic keyboard input doesn't seem to be very difficult either (although adding support for international keyboard layouts would be tricky).

However, this doesn't fit well into the current module structure with the node-webgl/node-glfw split. So what about refactoring it a bit:

1. Move the actual core WebGL code to webgl-core module that doesn't depend on node-glfw or any other npm modules.
2. Make node-webgl depend on webgl-core in addition to node-glfw (to retain backward compatibility).
3. Create another module - I'll call it webgl-next for now - that provides more-or less the same API as node-webgl, but only depends on webgl-core and expects that the consumer also references one (or more) of several modules that provide an API equivalent to node-glfw. One of those modules would be webgl-pi-xless. Anyone could easily add webgl-wayland or perhaps even bring back node-sdl. AntTweakBar would get moved to an independent module as well. Image code might get moved into another module as well to make it possible to eventually replace it with some pure Node.js image library.

The good thing about this is that node-webgl would still work just as it did before. Switching to to webgl-next would be an option for more adventurous users.

Or is such modular structure an overkill? What do you think?

[dav-m85]

@lukaaash Agreeing on the general idea of splitting things up. Thus someone interested in a specific platform would just require the needed module without having to bother with unecessary bindings.

I wonder to what extent the webgl-core you're drafting here could be in facts https://github.com/stackgl/headless-gl ?

[mikeseven]

Yes it is a good idea. I have been thinking along the same lines for a long time. I completely support a modular approach since this was the goal when I started node-webgl, you can still see other backends.

Now more than ever, we should have a backend for gles. And your extensions seem right. Maybe time to merge a pull request ;-)

--mike

On Tue, Mar 1, 2016 at 5:12 AM -0800, "Lukas Pokorny" <[email protected]mailto:[email protected]> wrote:

@PTS93https://github.com/PTS93 I'm sure we could add GLFW and even Wayland (which sadly seems to be taking a long time) support as well, but I don't have time to look into that myself at the moment. It's just a hobby project for me. But if anyone would like to work on this, feel free to start with my forkhttps://github.com/lukaaash/node-webgl and enhance it.

@dav-m85https://github.com/dav-m85 and @mikesevenhttps://github.com/mikeseven OK, so where do we go from here? My fork already runs on Raspberry Pi 2 (and I guess it would work on Pi 1 and Pi 3 as well), but it's not capable of handling any kind of input yet. I have been slowly working on that - I'm almost done with adding support for mouse and multi-touch (for the official Raspberry Pi Touch Display) through Linux input subsystem, and basic keyboard input doesn't seem to be very difficult either (although adding support for international keyboard layouts would be tricky).

However, this doesn't fit well into the current module structure with the node-webgl/node-glfw split. So what about refactoring it a bit:

1. Move the actual core WebGL code to webgl-core module that doesn't depend on node-glfw or any other npm modules.
2. Make node-webgl depend on webgl-core in addition to node-glfw (to retain backward compatibility).
3. Create another module - I'll call it webgl-next for now - that provides more-or less the same API as node-webgl, but only depends on webgl-core and expects that the consumer also references one (or more) of several modules that provide an API equivalent to node-glfw. One of those modules would be webgl-pi-xless. Anyone could easily add webgl-wayland or perhaps even bring back node-sdl. AntTweakBar would get moved to an independent module as well. Image code might get moved into another module as well to make it possible to eventually replace it with some pure Node.js image library.

The good thing about this is that node-webgl would still work just as it did before. Switching to to webgl-next would be an option for more adventurous users.

Or is such modular structure an overkill? What do you think?

Reply to this email directly or view it on GitHubhttps://github.com//issues/24#issuecomment-190718683.

[mikeseven]

@dav-m85, it would seem headless-gl could be an interesting backend especially for server apps.

On Mar 1, 2016, at 10:10 AM, dav-m85 <[email protected]mailto:[email protected]> wrote:

@lukaaashhttps://github.com/lukaaash Agreeing on the general idea of splitting things up. Thus someone interested in a specific platform would just require the needed module without having to bother with unecessary bindings.

I wonder to what extent the webgl-core you're drafting here could be in facts https://github.com/stackgl/headless-gl ?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/24#issuecomment-190837639.

[lukaaash]

@dav-m85 I have not looked thoroughly into headless-gl yet - I thought it's just a slight modification of node-webgl, but on closer look, it appears to be a rewrite that heavily depends on ANGLE, a GL ES wrapper around Direct3D. Because headless-gl claims to be more compatible with WebGL, it might make sense to base the proposed webgl-core on it instead, but that would involve forking and restructuring headless-gl as well... However, merging the enhancements made in headless-gl back into node-webgl (or webgl-core) looks like a good idea.

@mikeseven Incorporating my extensions into node-webgl in its current form would be tricky because of lack of full node-glfw API in my Pi-enabled fork - there's no support for any form of user input. And trying to cram raw Linux input handling into node-glfw doesn't seem right. Perhaps we should do some restructuring first? :-)

I'll try pushing what I already have in the next few days. It's work-in-progress, but it's almost good enough as proof-of-concept demo.

[timonsku]

Just a heads up, there is also the proper OpenGL driver coming which is in beta right now. Eben Upton made an estimate of about 6 month for it to be on a level with the current binary blob driver.

[lukaaash]

@PTS93 That looks very promising! I missed this news. Then, we might get full WebGL 1.0 (with DEPTH_STENCIL_ATTACHMENT, which is not part of GL ES 2.0 and not provided as an extension on Raspberry Pi) and perhaps even WebGL 2.0 later.

[lukaaash]

@mikeseven OK, I guess that instead of trying to restructure node-webgl, I'll first try merging my extensions into the main fork and then create a thin wrapper module around that adds support for raw input. This will make node-webgl easily usable on Raspberry Pi now. We can replace it with something better later.

[mikeseven]

Let's try. The input as used in glfw is pretty much standard X input that should also work on PI, no?

--mike

On Wed, Mar 2, 2016 at 7:43 AM -0800, "Lukas Pokorny" <[email protected]mailto:[email protected]> wrote:

@mikesevenhttps://github.com/mikeseven OK, I guess that instead of trying to restructure node-webgl, I'll first try merging my extensions into the main fork and then create a thin wrapper module around that adds support for raw input. This will make node-webgl easily usable on Raspberry Pi now. We can replace it with something better later.

Reply to this email directly or view it on GitHubhttps://github.com//issues/24#issuecomment-191293437.