Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

oF in HTML5 #1319

Closed
gimlids opened this Issue · 102 comments

14 participants

David Stolarsky Kyle McDonald Elliot Woods Gabriel arturo Walter Perdan Vilson Vieira ofZach Brendon Smith Andreas Bergmeier Christoph Buchner Christopher Baker Jason Van Cleave Tim Gfrerer
David Stolarsky

Issue: openFrameworks does not run in the web browser.

Solution: the emscripten backend for the LLVM compiler generates JavaScript, many C++ OpenGL projects have been demonstrated running in the browser with WebGL.

Is anyone interested in this?

Kyle McDonald
Owner
David Stolarsky

Right, camera input for example wouldn't work for free, but you could get it through a Flash webcam bridge, or eventually through HTML5 webcam support. Likewise sockets won't work, but XmlHttpRequest and WebSockets will. Also libs we don't have source for, like Fmod, won't work. But if you have the C++ (or C, or Obj-C, or others), emscripten will convert it to JavaScript, and the switch from OpenGL to WebGL is demonstrated e.g. here: http://www.syntensity.com/static/ammo.html (Bullet Physics demo, it's a big C++ 3D physics engine).

emscripten: https://github.com/kripken/emscripten/wiki

I haven't used emscripten myself yet, but it looks very very healthy on github, and obviously it's really amazing. LLVM is the new compiler Apple is pushing, it replaces parts of or all of GCC, depending on how you use it. It's the default compiler when you use Xcode 4. Basically the LLVM family can compile lots of languages, including the C's, into "LLVM bitcode" and from there, backends can generate native code for x86, or ARM, or whatever, and these crazy people decided to make a JavaScript generator for it.

Kyle McDonald

that's amazing. we totally need to get on this. i think webgl will definitely be more likely to be adopted in a cross-platform, cross-browser way than any of the chrome nacl stuff. and having OF running on the web would be huge!

Elliot Woods
Collaborator

there's a demo of a Python runtime ported to JavaScript using emscripten, and also a h264 decoder
LLVM byte-code ftw

it seems using the v8(?) engine of chrome it's possible to get machine-code like performance if you code it with specific 'register'-friendly data structures. something like a 20% drop from machine code is possible for some projects.

but this is all a toy and doesn't offer true oF-in-browser support (devices, filesystem, consistent performance)
also it has no automated handling of opengl-to-webgl (or specific opengl wrapping at all)

emscripten and equivalents could revolutionise webcode

what would the IDE be like?

is there a reason not to make a native openFrameworks.js?
this would also remove the laborious compile-time
but would obviously cause issues with syntax / objects

what about native client (that's a pretty easy cross-platform deployment mechanism we could hook right into with likely less hassle than event an iPhone or Android which we've already achieved)

David Stolarsky

right, this would not fully support all of oF. "openFrameworks.js" might be the wrong name. it's more like oF on iPhone, which also does not support arbitrary devices. the IDE is whatever you normally use, the code looks the same, you just compile in a different way, outputting JavaScript and HTML instead of OS-native binaries.

the filesystem (well file reads at least) would become HTTP loads. writes actually could happen too, by just adding a little server-side file write end point (one filesystem, endless number of users, interesting, no?). webcam will work with some glue; overall device support would be no worse than on iOS.

my original motivation is to have a way to write primarily graphical / animation "widgets" in one language/framework and deploy them to web browsers, natively on mobile devices, and natively on desktop platforms. but i think "apps" and "applications" are also viable candidates for this sort of system, and perhaps the web server as the filesystem could be a quite interesting feature to offer oF-land.

i think performance will work itself out as JavaScript and WebGL mature.

Gabriel

Hi !
I'm a huge fan of javascript. The idea behind running oF in the brower just make me happy.
But what are we aiming to ?

A. writing javascript language and use oF API.
B. writing C++ language and compile to oF HTML5 app, cross browser (Opera, IE, Firefox, Chrome, Safari, etc..)

It seems @codeboost already made a step in the A path : https://github.com/codeboost/JOpenFrameworks

What would be the benefit ? What would be the limit ? Actually, it seems that :
using camera is not a stopper :

About performance I totally agree with @gimlids performance will work while JS + WebGL grow up.

Have a nice day !

David Stolarsky

the way i imagine it, this is (B), exporting a normal C++ oF app to HTML5. though perhaps converting oF to .js through emscripten would make it pretty easy to actually provide oF's API to JavaScript coders.

the benefit is (1) opening the web browser to oF developers, but maybe they already know sufficient JavaScript? need to do some market research =) and benefit (2) "write once, run everywhere" for graphical / animated apps. to elaborate on my original motivation -- i want to target native iOS and the web browser at the same time. (and Android and desktop at the same time as well, sure why not)

also i agree, JavaScript is surprisingly delightful, especially once you get into the functional style.

Elliot Woods
Collaborator

the 'tidy way' is going to be somehow writing an openFrameworks lib that compiles to js and wraps native WebGL calls for graphics. then when you compile you staticly link that lib instead of the oF OpenGL ones

and then a seperate piece of work to expose oF api back to JS for in-browser livecode hacking

David Stolarsky

A little update/bump because today Google/Chromium announced they are forking WebKit --> Blink and making some big, interesting changes, and also emscripten is alive and well, and Mozilla is somehow involved with it. So like, the web, and stuff.

@elliotwoods If I understand you correctly, I think you are suggesting more work than is necessary for this. What emscripten is supposed to mean is that we just write an appropriate Makefile and voila, oF apps can be compiled straight to "HTML5." Only caveats I think are local filesystem access, sockets, things like that. OpenGLES automatically gets mapped to WebGL through the emscripten (and maybe asmjs.org) process, so as long as "HTML5" mode uses OpenGLES calls, as already exist for iOS, that part is taken care of. Maybe C/C++ sockets will be automatically mapped to WebSockets now, or in the future.. not sure on that.

Can anyone think of outstanding reasons a lot more work might have to be done? Poco (I'm not so familiar with it, nor its integration in oF)? FMOD audio comes as a DLL already, so I assume emscripten will not eat it up.

For ofFile, a portion of ofFile (the read part) could be implemented as a URL load, so you just put your app on a web server, and file reads happen over HTTP...

arturo
Owner

i've been trying emscripten, haven't done anything serious yet just tried to compile a couple of c programs and it looks promissing. i want to try to compile OF. i've been looking at google's naci for a while but the fact that it only runs on chrome and that the only way to distribute naci apps is through the chrome store so it makes it way less interesting that it could seem at first.

Once we have gles2 in the core it should be fully compatible with webGL i guess. There's probably some stuff to do like packing resources with the binary while compiling but apart from that i think it's just a matter of compiling and removing the modules that won't work ( i guess sound and video by now )

Walter Perdan

i discovered the JopenFrameworks project and i tought that it can run in a browser. After seeing the video in the forum http://forum.openframeworks.cc/index.php/topic,6335.0.html and reading this discussion i realize that it can't as it is run in a browser. Will be nice if we can run OF application via a .js in a browser. But when it will possible?
Regarding the discussion on WebGl: Does the OF team plan to add support for this project? or it something more like a parallel project.
I know that Processing has Processing.js, OpeneScenGraph has osgjs.js , so i think will be super cool to have a kind of OpenFrameworks.js that can works directly in a browser.

Kyle McDonald

@kalwalt i don't know anyone who is actively developing OF in the browser right now. the only real "plans" for OF are to keep supporting people in whatever way they're using it. but if it's something you're excited to see, we're excited to support you in making it happen :) maybe @gimlids and @arturoc can give an update on what they've found so far.

Walter Perdan

thank's for the answer @kylemcdonald ! yes i'm very excited , i'm trying right now emscrypten. I've only tested the basic examples for now. i want to see OF in my browser! In Ubuntu 12.04 64bit i installed llvm3.2 as suggested form the emscripten wiki https://github.com/kripken/emscripten/wiki/Tutorial . I'm not sure of one thing. i have installed only the 64bit version of llvm3.2 should i install also the 32 bit version?
On the other hand i wan't to try also FireBreath http://www.firebreath.org/display/documentation/FireBreath+Home . i found it in the OpenSceneGraph 3 CookBook an example for integrating OSG into web browser through firebreath. When i will be familiar with the Firebreath API sure i will test it into OF.

Vilson Vieira

@kalwalt any updates? I just installed LLVM and Clang 3.2 in Ubuntu 11.10 and I'm interested in helping with oF building using emscriptem.

As pointed in https://github.com/kripken/emscripten/wiki/Building-Projects I believe we have to build every oF dependency as well...

arturo
Owner

I've been looking at this recently and i also think the best option would be emscripten, nacl is another, it would be faster but it's chrome only and it requires to go through the chrome store.

emscripten supports webgl, which should work without problem with the latest programmable GL renderer, except for VAOs which i'm not sure if they work in GL ES/WebGL

and yes it needs to recompile every library we use with emscripten so a good beginning would be to start by doing that, the other thing needed would be to create the corresponding platform makefile config file.

we'll probably need to do something in the makefile to include any resource file in data in the executable although in this case the best would be to use online resources.

apart from that i think all the code we currently have should work.

Walter Perdan

@automata @arturoc for now i'm only trying to understand how emscripten works. I tried different simple examples that you can find in the tests folder and i can say that it is very easy when the code is limited to one or few .cpp or .c files. Even the ability to export directly to .html with the javascript code embedded is awesome! For me became more difficult when is involved an entire project. But as point out arturo we should recompile every library we use. The question is: should be a difference doing this in linux or windows or Mac?

the final result should be something like a of.js as for processing.js ? we should use emscripten also for testApp.* and main.cpp? or we can code directly in javascript after?

we'll probably need to do something in the makefile to include any resource file in data in the executable although in this case the best would be to use online resources.

do you mean a config.h? i looked in https://github.com/kripken/box2d.js/blob/master/Makefile and https://github.com/kripken/box2d.js/blob/master/root.h

arturo
Owner
Kyle McDonald

If we had an of.js that supported all the libraries we use (not just gl) wouldn't that mean of.js would be something like a 3MB download? Is it common to have js libraries that are that big?

Gabriel
arturo
Owner

3Mb is huge and probably an of.js would be even bigger, i think it's ok though this is not a usual web page it's a c++ app running in the browser, users won't shouldn't expect fast downloads...

also we can host the libraries with version somewhere so every app can point to the same library and take advantage of the browser cache, that way the library will be downloaded once only for all the apps using the same version

Walter Perdan

you @kylemcdonald @gabrielstuff and @arturoc are right regarding the size of the hypothetical of.js. This is a nonsense if you want make a little interactive app on the web. ( but maybe at this point better use another library, processing.js , jquery, or other) but if you want develop a 3D interactive app? see the BananBread project https://github.com/kripken/BananaBread for the code and for the demo https://developer.mozilla.org/it/demos/detail/bananabread just for an idea. The point is that Openframeworks is not a game engine but we could do very interesting stuff with a javscript version in the 3d field and with the OF flexibility.

Gabriel
Walter Perdan

Absolutely yes, sure it will be easier. There are also other project like scene3d.js and osg.js (mentioned above) but i'd like to do also some little app with OF if it is possible. In these days i'm exploring different javascript libraries to find the best that fits on my ideas and Three.js is full of resources...

ofZach
Owner

here's a slide show about C++ and emscripten that has some useful info about porting games, etc:

http://de.slideshare.net/andreweissflog3/quovadis2013-cpp-ontheweb

Walter Perdan

thanks @ofZach the slide is very useful. it is a bit clear now some of the emscripten ascpects.

Walter Perdan

Tryed the smartest possiblity with emscripten id est run emmake make in an example folder but i got this:

emmake make
Package gl was not found in the pkg-config search path.
Perhaps you should add the directory containing gl.pc'
to the PKG_CONFIG_PATH environment variable
No package 'gl' found
Package glew was not found in the pkg-config search path.
Perhaps you should add the directory containing
glew.pc'
to the PKG_CONFIG_PATH environment variable
No package 'glew' found
Package glu was not found in the pkg-config search path.
Perhaps you should add the directory containing glu.pc'
to the PKG_CONFIG_PATH environment variable
No package 'glu' found
Package gstreamer-0.10 was not found in the pkg-config search path.
Perhaps you should add the directory containing
gstreamer-0.10.pc'
to the PKG_CONFIG_PATH environment variable
No package 'gstreamer-0.10' found
Package gstreamer-video-0.10 was not found in the pkg-config search path.
Perhaps you should add the directory containing gstreamer-video-0.10.pc'
to the PKG_CONFIG_PATH environment variable
No package 'gstreamer-video-0.10' found
Package gstreamer-base-0.10 was not found in the pkg-config search path.
Perhaps you should add the directory containing
gstreamer-base-0.10.pc'
to the PKG_CONFIG_PATH environment variable
No package 'gstreamer-base-0.10' found
Package libudev was not found in the pkg-config search path.
Perhaps you should add the directory containing libudev.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libudev' found
Package cairo was not found in the pkg-config search path.
Perhaps you should add the directory containing
cairo.pc'
to the PKG_CONFIG_PATH environment variable
No package 'cairo' found
Package gl was not found in the pkg-config search path.
Perhaps you should add the directory containing gl.pc'
to the PKG_CONFIG_PATH environment variable
No package 'gl' found
Package glew was not found in the pkg-config search path.
Perhaps you should add the directory containing
glew.pc'
to the PKG_CONFIG_PATH environment variable
No package 'glew' found
Package glu was not found in the pkg-config search path.
Perhaps you should add the directory containing glu.pc'
to the PKG_CONFIG_PATH environment variable
No package 'glu' found
Package gstreamer-0.10 was not found in the pkg-config search path.
Perhaps you should add the directory containing
gstreamer-0.10.pc'
to the PKG_CONFIG_PATH environment variable
No package 'gstreamer-0.10' found
Package gstreamer-video-0.10 was not found in the pkg-config search path.
Perhaps you should add the directory containing gstreamer-video-0.10.pc'
to the PKG_CONFIG_PATH environment variable
No package 'gstreamer-video-0.10' found
Package gstreamer-base-0.10 was not found in the pkg-config search path.
Perhaps you should add the directory containing
gstreamer-base-0.10.pc'
to the PKG_CONFIG_PATH environment variable
No package 'gstreamer-base-0.10' found
Package libudev was not found in the pkg-config search path.
Perhaps you should add the directory containing libudev.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libudev' found
Package cairo was not found in the pkg-config search path.
Perhaps you should add the directory containing
cairo.pc'
to the PKG_CONFIG_PATH environment variable
No package 'cairo' found
compiling x86_64 object for: src/main.cpp
mkdir -p obj/x86_64Release/src
/home/walter/emscripten/emscripten/em++ -c -Wall -fexceptions -I. -I../../../libs/glu/include -I../../../libs/FreeImage/include -I../../../libs/assimp/include -I../../../libs/assimp/include/Compiler -I../../../libs/fmodex/include -I../../../libs/freetype/include -I../../../libs/freetype/include/freetype2 -I../../../libs/freetype/include/freetype2/freetype -I../../../libs/freetype/include/freetype2/freetype/internal -I../../../libs/freetype/include/freetype2/freetype/internal/services -I../../../libs/freetype/include/freetype2/freetype/config -I../../../libs/kiss/include -I../../../libs/portaudio/include -I../../../libs/rtAudio/include -I../../../libs/tess2/include -I../../../libs/poco/include -I../../../libs/openFrameworks/ -I../../../libs/openFrameworks/app -I../../../libs/openFrameworks/graphics -I../../../libs/openFrameworks/3d -I../../../libs/openFrameworks/sound -I../../../libs/openFrameworks/math -I../../../libs/openFrameworks/types -I../../../libs/openFrameworks/communication -I../../../libs/openFrameworks/utils -I../../../libs/openFrameworks/gl -I../../../libs/openFrameworks/video -I../../../libs/openFrameworks/events -march=native -mtune=native -Os -MMD -MP -MFobj/x86_64Release/src/main.d -MTobj/x86_64Release/src/main.o -oobj/x86_64Release/src/main.o -c src/main.cpp
In file included from src/main.cpp:1:
In file included from ../../../libs/openFrameworks/ofMain.h:5:
../../../libs/openFrameworks/utils/ofConstants.h:143:12: fatal error:
'GL/glew.h' file not found
#include
^
1 error generated.
emcc: compiler frontend failed to generate LLVM bitcode, halting
make: *** [obj/x86_64Release/src/main.o] Errore 1
walter@walter-RC530-RC730:~/oF.js/of/examples/graphics/color$

shouldn't pkg's already configured with makefile?

David Stolarsky
Elliot Woods
Collaborator
Walter Perdan

@elliotwoods i think that the reason for those errors is the fact that i didn't run a ./configure emconfigure before the emmake make process (because we haven't one in OF, but i'm not very expert in this field, i have a lot to learn) . the emconfigure should configure emscripten with all the packages, includes, etc as a configure always should do. Your are right about video player, video grabber and cairo. I didn't change any part of OpenFrameworks in this test. I'll have to exclude some parts of the code and to try to solve the problem of packages and especially GL. the most problematic definitely will be the poco lib.I'll have to exclude some part of the code and try to solve the problem of packages and especially GL. the most problematic definitely going to be the poco lib.
yes, it is probably a laboratory curiosity, more than a serious project. I tried the three.js and is fantastic. You can create a scene with blender and export it in .json format, there is also the project threeNode.js https://github.com/idflood/ThreeNodes.js very interesting, and Sublime also has support for this library.

p.s. my name is walter but my nick is @kalwalt not @ w a l t e r . sorry for the problem!

Brendon Smith

@kalwalt @elliotwoods I have been looking into porting this library over and spent a copious amount of time this weekend trying it I am having the same issues @kalwalt was having I was just curious if anyone had made it further along? It would be wonderful to be able to use oF c++ and compile down to javascript especially now that asm.js is in Chrome Canary. http://arstechnica.com/information-technology/2013/05/native-level-performance-on-the-web-a-brief-examination-of-asm-js/

Andreas Bergmeier

The main problems seem to be (synchronization points/threading) and messy gl. I'll have a look, but will probably have to rip apart quite a bit of code.

arturo
Owner

take into account that something that rips apart quite a bit of code won't be accepted in the core :) still it'll be an interesting experiment to see what needs to be modified to get OF working with webGL.

my idea is that we'll need to ifdef or make separate implementations for non-fixed pipeline for classes like ofTexture, ofVbo and ofFbo and that poco is going to be really problematic.

are you using emscripten?

Andreas Bergmeier

I am currently analyzing what needs to be done.
1. is replacing Poco classes behind some typdef logic, so it is possible to write a same-interface implementation for the web.
2. Replace ofThread with some kind of ofWorker. Which btw would be far superior to dealing with low level thread handling anyway.
3. See whether event notification can stay synchronous. I would prefer using notifyAsync.
4. Cleaning up GL handling.

Yes, I am using Emscripten/C++11/cmake/Eclipse. So I guess my code will not be very similar with the C++98 style you use.

Christoph Buchner
Owner

That's no problem, our code style is detailed in https://github.com/openframeworks/openFrameworks/wiki/oF-code-style. Also, be sure to read https://github.com/openframeworks/openFrameworks/blob/master/CONTRIBUTING.md#contribute-code to see how we work with PRs etc. :-)

arturo
Owner

ofWorker sounds good.

We'll also need to replace ofURLFileLoader with something that does the same but not based in poco but instead uses whatever emscripten provides to download http resources

the rest of places were we use poco is mostly for the events which is actually a bunch of headers that we could pull from poco as a first step and then utility functions that can probably just be implemented without using poco

Andreas Bergmeier

And there is quite a bunch of code where you could replace Poco and use stdlib just fine.
This will get more important over the next years, since the stdlib will get more extensive.

arturo
Owner

yes that would be great, there's a group looking into making OF c++11 compatible. by now we want to only make it compile with c++11 not directly use it in the core (or at least maintain compatibility with c++98) for a while so old IDEs still are supported. but i agree removing dependencies with poco is a good idea.

arturo
Owner

this is the c++11 issue:
#2577

Andreas Bergmeier

Just to be clear: I will write in C++11.
If after getting it to work, you guys want to support Emscripten, you can backport it to C++98.

arturo
Owner

sounds good

Andreas Bergmeier

openFrameworks on Chrome (via Emscripten) http://t.co/AxNopt4ZCv

Christopher Baker
Collaborator
Andreas Bergmeier

Could someone with a compiling EGL/OGLES2 installation please make a screenshot of the customEGLWindowSettings example.

arturo
Owner

yeah! have you managed to compile poco on emscripten, or did you removed all dependencies?

don't have any arm board right now with me, @bakercp @jvcleave can you send an screenshot?

Christopher Baker
Collaborator
Walter Perdan

hi, @abergmeier did you manage to compile OF with emscripten? if yes you are great!

Andreas Bergmeier

@arturoc yes, I compiled Poco and all dependencies. I use some experimental extensions to Emscripten we are working on.

@kalwalt Let us wait till you saw all the modifications to the source I had to do ;)

I am doing this as my Bachelor Thesis, so will post both the repo and full writeup what I did when I am done.
In the end we will have to dispose of sndfile, since its' License does not allow for linking in.

BTW: Is someone working on exception safety/consistency in the code?

Jason Van Cleave
Collaborator

screenie

customeglwindowsettings

Andreas Bergmeier

Thanks @jvcleave So I guess since the z rotation seems right, that the problems lies either within the matrix math or the texture coords. Is anyone familiar with the TARGET_OGLES code in IRC these next days?

Jason Van Cleave
Collaborator
Jason Van Cleave
Collaborator
Andreas Bergmeier

@jvcleave I am not getting why my bitmap is so much bigger than yours.
Could you perhaps output the values (for one frame) of buffers for uniform modelViewProjectionMatrix and attributes position and texcoord?

Jason Van Cleave
Collaborator

@abergmeier sure - if you want to write what you need I can paste it in and run it later tonight

Andreas Bergmeier

Just noticed - you are compiling with TARGET_RASPBERRY_PI, right? That means that you are running a different shader/render path.

arturo
Owner

yes, the shaders are different for raspberry

Andreas Bergmeier

For both, modelViewMatrix is never actually used. So modifying modelViewProjectionMatrix should give the exact same picture regardless of TARGET_RASPBERRY_PI.

And enforcing the unique shader renders the same for me.

Does anyone have the example working on something else than Rasperry?.

Andreas Bergmeier

Just a shot in the dark but @jvcleave could you try replacing

rpiLogo.loadImage("Raspi_Colour_R.png");

by

auto buffer = ofBufferFromFile( "Raspi_Colour_R.png", true );
if( !rpiLogo.loadImage(buffer) ) {
    ofLogError("ofApp") << "Loading image 'Raspi_Colour_R.png' failed.";
    std::terminate();
}

in ofApp.cpp.

Andreas Bergmeier

I get the same output when I scale drawing by 0.001f. Strange.

Jason Van Cleave
Collaborator

with updated code (I can't use auto though)

customeglwindowsettings2

Andreas Bergmeier

So I am rebasing my changes to nice little commits (a lot of them). Wondering whether I should submit the pull-requests to the C++11 repo.

arturo
Owner

that's great, thanks! i think it's better to submit them to the main repo that way we don't end up with a ton of changes to merge from a different branch. The c++11 repo is mainly for adding compatibility with c++11 at a project level but we are not adding c++11 features just yet.

Also if you have a public repo where you are working i could take a look before you send the PR's if you want. It could even be useful to merge them into a different branch or repository for review before merging them into master since i guess there'll be some big changes?

Andreas Bergmeier

The problem is all changes are based on the C++11 repo. All code is written in C++11, too. So if you do not want C++11 in master, I could send the pull-requests to another branch (em perhaps).
Still the changes would require all changes to the C++11 repo anyway.
Seems to me like it would then make more sense to submit the requests against the C++11 repo since that will have to be merged to master at some point anyway.

Christoph Buchner
Owner

I think your changes should just be PR'd to main OF after the C++11 changes land in the main repo (this can happen from a branch on the C++11 repo, of course, so you can start integrating earlier), otherwise the C++11 repo PR will have the additional burden of carrying your changes (and we can't easily separate them when we merge into main OF)

Andreas Bergmeier

@bilderbuchi We could solve that problem by creating a new branch em in the C++11 repo. I could then submit the pull requests against that. So you guys could review every change and already prepare in em. Once you then merge the C++11 repo, you can apply the Emscripten changes separately.

arturo
Owner

oh, if it needs the changes in the c++11 repo then yes, it makes sense to send the PR's there

Christoph Buchner
Owner

We could solve that problem by creating a new branch em in the C++11 repo. I could then submit the pull requests against that.

yes, exactly. Here, have a go: https://github.com/openFrameworks-cpp11/openFrameworks/tree/feature-emscripten (branched from the cpp11 feature branch)
@tgfrerer copied FYI. could you maybe sync up the cpp11 repo with OF/master again, tim,, it's been a while?

Tim Gfrerer
Collaborator
Christoph Buchner
Owner

darn it, I just realized there's a typo in the branchname. I'll correct it shortly.
edit: corrected & updated with the latest from cpp11.

Andreas Bergmeier

Ok, the first non-C++11 pull request landed #2766. Once these are in the C++11 repo I'll start submitting the C++11 pull requests.
In general I wonder how to prevent people from breaking ofGLProgrammableRenderer for OGLES all the time. Are there automated tests, that can be run on the code?

Christoph Buchner
Owner

Are there automated tests, that can be run on the code?

Sadly not. I previously tried to motivate people to start with this, but the resonance was low. Only diasbruno started to implement some testing, see #1068

Andreas Bergmeier

@tgfrerer Can you do the magic merge dance again ;)

Christoph Buchner
Owner

do you mean pulling latest OF master into cpp11?

Andreas Bergmeier

@bilderbuchi yeah, that would be a much lamer way of saying it ;)

Christoph Buchner
Owner

I'm on it.

Christoph Buchner
Owner

oh fun. FreeImage.h has been changed in the meantime in cpp11, in openFrameworks-cpp11/openFrameworks@1c8ce38. magic dances will take a little longer...

Christoph Buchner
Owner

alright, updated both cpp11 and feature-emscriptem. git merge <branch> -s recursive -X renormalize really comes in handy at times. @tgfrerer could you take a quick look, wenn's passt? only conflict was in Freeimage.h, but I think your updated version was preserved correctly.

Tim Gfrerer
Collaborator

Vergeltsgott für's Zusammenführen, Christoph! (= "thanks for the merge" – sometimes English seems a bit more concise, n'est-ce pas?)

I've pulled the latest version in cpp11, & compiled and tested the image example, thinking that if anything had happened with freeimage, it would have barfed on it. All went well, and so I'm off to the pub.

Cheers
#
T

Christoph Buchner
Owner

Prost!

Andreas Bergmeier

Mai, guad hob das gmocht!
Thx :)

Andreas Bergmeier

Ok, the thesis is now officially out in the wild. I guess now someone needs to port the changes upstream.

Christopher Baker
Collaborator
Christoph Buchner
Owner

nice work! I like the OF analysis part.
Interesting part about sndfile. If that is our only non-permissive (LGPL) library, we should probably plan to remove it, since the aim of OF (afaik) is to be permissive/MIT-licensed. @arturoc ?
Congrats on finishing the thesis, and I hope you will hang around here (and contribute) even if we don't move fast enough for your at times. ;-)

arturo
Owner

congrats andreas! let us know when you publish the code, i'm really looking forward to test it

bilderbuchi, libsndfile is linked dinamically so it's ok

Elliot Woods
Collaborator
Andreas Bergmeier

@arturoc Is already published - just follow the links in the thesis.
@elliotwoods sorry, I kind of missed the link to the example. Added it now to the blog post.

Elliot Woods
Collaborator
Christoph Buchner
Owner

LGPL is pretty permissive, no?

pretty permissive, yes. compatible with e.g. the Apple app store, no.

arturo
Owner

oh, great, since i had already read the thesis, i didn't got in the pdf :)

Walter Perdan

Openframeworks -> emiscripten: I can't belive that is becoming reality! Many thanks for this @abergmeier and good luck for your thesis!

@elliotwoods next stop online IDE? yesss!

Andreas Bergmeier

openFrameworks has been added to the demo page of Emscripten.

Walter Perdan

@abergmeier that's great!

Walter Perdan

there are some news from this side? when we can test the new OF with emscripten? (i'm not talking of the example that you show) i'm learning three.js but i'd like to develop some personal project with Openframeworks in webgl.
Thanks

Andreas Bergmeier

You can of course always start working based on my repo. Be aware, thought, that It depends on some experimental Emscripten stuff, that we are discussing about currently. So not ETA, when this will be upstreamed.
And I think nobody yet has been found, for backporting the changes to openFrameworks.

Walter Perdan

Thank you @abergmeier i will try with your repo, also i see that is well commented with istructions, really excited to get hand on it!

Walter Perdan

i'm trying to build the libraries (poco,kiss.. ect) but i don't undesrtand the 'empkg' command where it come from? it's a special feature of emscripten or i need to install other pkg ?

Andreas Bergmeier

empkg is an extension to Emscripten currently only available in the incoming branch of https://github.com/abergmeier/emscripten.
If people want to keep up to date with empkg, here is our discussion.

Walter Perdan

thank you @abergmeier i'm going to fork your repo (incoming branch) and to test in linux64 and maybe windows. i will report here my progress from a OF side.

Walter Perdan

@abergmeier i installed your branch i run empkg inside the openframeworks folder and i get this error:

walter@walter-RC530-RC730:~/of$ empkg get poco && empkg build poco
INFO requests.packages.urllib3.connectionpool: Starting new HTTPS connection (1): raw.github.com
INFO requests.packages.urllib3.connectionpool: Starting new HTTPS connection (1): raw.github.com
INFO requests.packages.urllib3.connectionpool: Starting new HTTPS connection (1): raw.github.com
The following package sources will be installed:
poco - 1.4.6p2
INFO requests.packages.urllib3.connectionpool: Starting new HTTPS connection (1): raw.github.com
INFO requests.packages.urllib3.connectionpool: Starting new HTTPS connection (1): raw.github.com
INFO requests.packages.urllib3.connectionpool: Starting new HTTPS connection (1): raw.github.com
CMake Error: Could not create named generator Ninja
ERROR root: Configure step failed with non-zero return code 1! Command line: ['cmake', '-DCMAKE_BUILD_TYPE=Release', '-DCMAKE_INSTALL_PREFIX:PATH=/home/walter/.local/share/emscripten-libs/system/poco/1.4.6p2', '-G', 'Ninja', '.', '-DCMAKE_TOOLCHAIN_FILE=/home/walter/emscripten/cmake/Platform/Emscripten.cmake']
Traceback (most recent call last):
File "/home/walter/emscripten/empkg", line 125, in
args.handle()
File "/home/walter/emscripten/empkg", line 122, in handle
handler( package_versions )
File "/home/walter/emscripten/empkg", line 55, in handle_build
version.build()
File "/home/walter/emscripten/tools/pkg.py", line 344, in build
builder( self.path(), env )
File "/home/walter/emscripten/tools/pkg.py", line 566, in shell
subprocess.check_call( ['sh', '-c', command], cwd=cwd, env=env )
File "/usr/lib/python2.7/subprocess.py", line 511, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['sh', '-c', u'emcmake cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX:PATH=${EMSCRIPTEN_SYSTEM_ROOT} -G Ninja .']' returned non-zero exit status 1
walter@walter-RC530-RC730:~/of$

i run only poco at the moment, have you an idea of this kind of error?

Walter Perdan

Sorry, from a google search the error above happens because i'haven't Ninja generator installed, and maybe my cmake version is outdated...

Walter Perdan

@abergmeier i have installed Ninja and the newest version of cmake 2.8.12.2, i did this:

cd of
empkg get poco && empkg build poco
empkg get kiss-fft && empgk build kiss-fft
empkg get tess2 && empkg build tess2
empkg get sndfile && empkg build sndfile
empkg get freeimage && empkg build freeimage
empkg get freetype && empkg build freetype

i get some erros like this:

Build files have been written to: /home/walter/.local/share/emscripten-libs/sources/freetype/2.5.1
log: reading configuration file: install
die: error: unable to read configuration file
Traceback (most recent call last):
File "/home/walter/emscripten/empkg", line 125, in
args.handle()
File "/home/walter/emscripten/empkg", line 122, in handle
handler( package_versions )
File "/home/walter/emscripten/empkg", line 55, in handle_build
version.build()
File "/home/walter/emscripten/tools/pkg.py", line 344, in build
builder( self.path(), env )
File "/home/walter/emscripten/tools/pkg.py", line 566, in shell
subprocess.check_call( ['sh', '-c', command], cwd=cwd, env=env )
File "/usr/lib/python2.7/subprocess.py", line 511, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['sh', '-c', u'ninja install']' returned non-zero exit status 1

if i run ./rebuild in the same folder i receive unknown command.

a part this issue may i run cmake after that can you give more detailed details fo the build process please?
Thank you

arturo
Owner

this has been merged in master, there's still some problems buf there's an specific issue

arturo arturoc closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.