Re: OpenGL project
Locked
 
|
Hi,
Some progress on the OpenGL project: _ I read much of the sources around NBOpenGL, the architecture looks nice to me, so will keep it, but am actually considering to strip it to OpenGL ES 2! This is a subset of OpenGL, but is supported on more platforms (Android, iOS, RPi), and will be easier to maintain in the long term. _ A working minimal demo in C (https://drive.google.com/file/d/0B6Y_O5MtrUaEbXFjTGhUcTZwY3M/view?usp=sharing) _ SDL2 gave me some headaches (2~3 seconds to start & open a window, could not properly display the title bar, displays big ugly pixels on retina screen, could not test it in Pharo since it did not find library file). So I tried GLFW and LOVE IT (starts fast, handles the pixel density problem nicely, amazing documentation). I will work to bind it with FFI. _ Anybody else working on porting NBOpenGL? I am rather slow, so if we can sync work would be perfect :) Cheers, Thibault > ------------------------------ > > Message: 2 > Date: Sat, 12 Mar 2016 09:06:36 +0100 > From: stepharo <[hidden email]> > To: [hidden email] > Subject: Re: [Pharo-users] OpenGL project > Message-ID: <[hidden email]> > Content-Type: text/plain; charset=windows-1252; format=flowed > > Check bloc under Moose in the CI > there is a little class with the binding. > > Stef > > Le 11/3/16 13:22, Thibault Raffaillac a ?crit : > > Hi, > > > > I would like to do a bit of OpenGL in Pharo, but it does not seem to work > > at the moment. > > > > Tried NBOpenGL with a spur image (50560): > > _ fails at installation from configuration browser (need to click again on > > installing to get all classes) > > _ demo "GLTTRenderingDemo new openInWorld" fails at NBGLContextDriver with > > error "No suitable implementation found for initializing OpenGL context > > for your platform" (running on a Mac) > > > > Tried with a pre-spur image (50496): > > _ same weirdness at installation > > _ demo fails at NBGLCurveRenderer with "MessageNotUnderstood: receiver of > > on: is nil" > > > > Is there a working demo available out there? I have worked a lot with > > OpenGL ES 2.0 and could definitely provide work on the topic. > > > > Cheers, > > Thibault > > |
|
|
Can you include a proper build script? cc --std=c99 -Wall --pedantic -I/opt/homebrew/Cellar/glfw3/3.1.2/include -L/opt/homebrew/Cellar/glfw3/3.1.2/lib -lglfw3 minimal-glfw.c -o minimal-glfw minimal-glfw.c:15:5: warning: suggest braces around initialization of subobject [-Wmissing-braces] 256, 0, // top point ^~~~~~~~ { } minimal-glfw.c:16:5: warning: suggest braces around initialization of subobject [-Wmissing-braces] 512, 256, // right point ^~~~~~~~ { } minimal-glfw.c:17:5: warning: suggest braces around initialization of subobject [-Wmissing-braces] 256, 512, // bottom point ^~~~~~~~ { } minimal-glfw.c:18:7: warning: suggest braces around initialization of subobject [-Wmissing-braces] 0, 256}; // left point ^~~~~~ { } 4 warnings generated. Undefined symbols for architecture x86_64: "_glAttachShader", referenced from: _main in minimal-glfw-368070.o "_glBindBuffer", referenced from: _main in minimal-glfw-368070.o "_glBufferData", referenced from: _main in minimal-glfw-368070.o "_glClear", referenced from: _main in minimal-glfw-368070.o "_glClearColor", referenced from: _main in minimal-glfw-368070.o "_glCompileShader", referenced from: _main in minimal-glfw-368070.o "_glCreateProgram", referenced from: _main in minimal-glfw-368070.o "_glCreateShader", referenced from: _main in minimal-glfw-368070.o "_glDrawArrays", referenced from: _main in minimal-glfw-368070.o "_glEnableVertexAttribArray", referenced from: _main in minimal-glfw-368070.o "_glGenBuffers", referenced from: _main in minimal-glfw-368070.o "_glGetAttribLocation", referenced from: _main in minimal-glfw-368070.o "_glLinkProgram", referenced from: _main in minimal-glfw-368070.o "_glShaderSource", referenced from: _main in minimal-glfw-368070.o "_glUseProgram", referenced from: _main in minimal-glfw-368070.o "_glVertexAttribPointer", referenced from: _main in minimal-glfw-368070.o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) make: *** [minimal-glfw] Error 1 On 24 March 2016 at 17:59, Thibault Raffaillac <[hidden email]> wrote: Hi, |
|
|
In reply to this post by Thibault Raffaillac
Hi Thibault,
I put Ronie in copy because he is interested very much on having 3d stuff working. Why do you say “porting NBOpenGL”? Is it just a matter of rewriting the native calls with the new FFI system? Cheers, Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
|
|
|
In reply to this post by Thibault Raffaillac
> Can you include a proper build script?
Yep sorry, here are the steps I used to make it run on OSX: $ brew install glfw3 $ cc demo.c -lglfw3 -framework OpenGL For other systems the doc is hopefully detailed enough (http://www.glfw.org/docs/latest/build.html). > Why do you say ?porting NBOpenGL?? Is it just a matter of rewriting the > native calls with the new FFI system? NBOpenGL functions were generated automatically from NBGLGenerator, so I need to get used to the tool beforehand. It looks like a lot of work was put into this, can I find a paper about it? Also, IMO this all looks too complex. My point in limiting to ES 2 is not just removing functions, I want to make it look simple like the C demo! Thibault |
|
Better name it "Pharo OpenGL ES" so people don't get confused why some of their OpenGL code does not work. You won't finds docs about it , the guy that made it rarely frequents this forums anymore and his code is based on a api that is no longer included and supported by Pharo because it was doing a lot of machine code stuff that was very hard to maintain. My advise is don't worry about backward compatibility , make it easy, make it simple. Don't be afraid to code some of it in C if you have to. Sometimes it's far easier to use C than Pharo. Pharo is no magic wand. And foremost ask a ton of questions. We love questions. On Fri, 25 Mar 2016 at 11:38, Thibault Raffaillac <[hidden email]> wrote: > Can you include a proper build script? |
|
|
In reply to this post by Thibault Raffaillac
Hi Thibault,
Strange, I tried "brew install glfw3 “ but it does not work. Instead, I had to do "brew install homebrew/versions/glfw3” When I try to compile your file: -=-=-=-=-=-=-=-=-= /tmp> cc demo.c -lglfw3 -framework OpenGL demo.c:2:10: fatal error: 'GLFW/glfw3.h' file not found #include <GLFW/glfw3.h> ^ 1 error generated. -=-=-=-=-=-=-=-=-= Cheers, Alexandre > On Mar 25, 2016, at 6:37 AM, Thibault Raffaillac <[hidden email]> wrote: > >> Can you include a proper build script? > > Yep sorry, here are the steps I used to make it run on OSX: > $ brew install glfw3 > $ cc demo.c -lglfw3 -framework OpenGL > > For other systems the doc is hopefully detailed enough (http://www.glfw.org/docs/latest/build.html). > >> Why do you say ?porting NBOpenGL?? Is it just a matter of rewriting the >> native calls with the new FFI system? > NBOpenGL functions were generated automatically from NBGLGenerator, so I need to get used to the tool beforehand. It looks like a lot of work was put into this, can I find a paper about it? > Also, IMO this all looks too complex. My point in limiting to ES 2 is not just removing functions, I want to make it look simple like the C demo! > > Thibault > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
|
|
In reply to this post by Thibault Raffaillac
> Strange, I tried "brew install glfw3 ? but it does not work.
> Instead, I had to do "brew install homebrew/versions/glfw3? Yep good point thank you. > demo.c:2:10: fatal error: 'GLFW/glfw3.h' file not found Homebrew should place the GLFW folder in /usr/local/include, and cc should list it among include directories with -v Cheers, Thibault > > Cheers, > Alexandre > > > On Mar 25, 2016, at 6:37 AM, Thibault Raffaillac > > <[hidden email]> wrote: > > > >> Can you include a proper build script? > > > > Yep sorry, here are the steps I used to make it run on OSX: > > $ brew install glfw3 > > $ cc demo.c -lglfw3 -framework OpenGL > > > > For other systems the doc is hopefully detailed enough > > (http://www.glfw.org/docs/latest/build.html). > > > >> Why do you say ?porting NBOpenGL?? Is it just a matter of rewriting the > >> native calls with the new FFI system? > > NBOpenGL functions were generated automatically from NBGLGenerator, so I > > need to get used to the tool beforehand. It looks like a lot of work was > > put into this, can I find a paper about it? > > Also, IMO this all looks too complex. My point in limiting to ES 2 is not > > just removing functions, I want to make it look simple like the C demo! > > > > Thibault > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Pharo-users mailing list > [hidden email] > http://lists.pharo.org/mailman/listinfo/pharo-users_lists.pharo.org > > > ------------------------------ > > End of Pharo-users Digest, Vol 35, Issue 121 > ******************************************** > |
|
|
On 26 March 2016 at 18:44, Thibault Raffaillac <[hidden email]> wrote:
No. It should put them in `brew --prefix`/include, which only happens to be /usr/local/include if you followed homebrew's default installation instructions. If you have pkg-config installed, you can use it to determine the correct preprocessor and linker flags to the compiler, like so: pkg-config --cflags --libs glfw3 |
|
|
In reply to this post by kilon.alios
On 25 March 2016 at 12:51, Dimitris Chloupis <[hidden email]> wrote:
Why cutting things down to a subset? You have all specs on Opengl.org .. all you have to do today is to import xml file and generate proper ffi calls. You can, of course, add support of OpenGL ES.. but why throwing away rest of spec? It just a spec.. you don't have to use it if you don't need it. Instead, if that feels too big - you can do it smarter way: - make package/subpackage/classes for ES edition and for full edition. It shouldn't cause much trouble if you do it right. Because throwing away is easiest part - but making something that will serve for years .. harder, because tomorrow someone else can come and throw your stuff away :) OpenGL is around for years now.. and i don't think ES edition will replace standard.. I would prefer to be able to access to full OpenGL functionality, at a day i will need it.. why cutting things down? There's many ways to do things in smart way so, nothing will be lost. If you don't want/can't maintain or support full OpenGL support - that's another story. Then just don't call your project OpenGL - it will cause confusion to those who expecting things to work out of the box, and finding out it just OpenGL ES..
Yep, make it work. That's all what matters.
Best regards,
Igor Stasenko. |
|
|
In reply to this post by Thibault Raffaillac
There's (hopefully!) no question of throwing it away already. That represents too much work, and pretty good design choices IMO. Yet I'm still pretty new to Pharo/Smalltalk so simply need time. At the moment I am only practicing on a GLFW binding.
Now, I do believe in OpenGL and hardware rendering in general (vs software & framebuffer stuff), but these APIs are constantly evolving (with hardware, market needs, ...), with driver manufacturers having little care about backward compatibility. This means in that sea of innovations we have to spot the few key technologies which are going to last long enough to be still in use by the time they reach Pharo users (think of tesselation, or geometry shaders, hardly heard of nowadays). OpenGL ES 2 is such a key tech, I think, for its wide adoption in Android, iOS, RasPi. Still, there is no doubt it is going to be ditched too in a decade or so (command buffers are already being reintroduced in Vulkan...), and then in Pharo. With that in mind, my point is to make it as few and small classes as possible, to make it easier (and faster!) to ditch them later when a new key tech arises. That said, I'm looking for least effort solution, so will still strive to replace NB with UFFI in generator. Cheers, Thibault > Why cutting things down to a subset? > You have all specs on Opengl.org .. all you have to do today is to import > xml file and generate proper ffi calls. You can, of course, add support of > OpenGL ES.. but why throwing away rest of spec? It just a spec.. you don't > have to use it if you don't need it. Instead, if that feels too big - you > can do it smarter way: > - make package/subpackage/classes for ES edition and for full edition. > It shouldn't cause much trouble if you do it right. > Because throwing away is easiest part - but making something that will > serve for years .. harder, because tomorrow someone else can come and throw > your stuff away :) > OpenGL is around for years now.. and i don't think ES edition will replace > standard.. I would prefer to be able to access to full OpenGL > functionality, at a day i will need it.. why cutting things down? > > There's many ways to do things in smart way so, nothing will be lost. > If you don't want/can't maintain or support full OpenGL support - that's > another story. Then just don't call your project OpenGL - it will cause > confusion to those who expecting things to work out of the box, and finding > out it just OpenGL ES.. > > > > My advise is don't worry about backward compatibility , make it easy, make > > it simple. Don't be afraid to code some of it in C if you have to. > > Sometimes it's far easier to use C than Pharo. Pharo is no magic wand. > > > > > Yep, make it work. That's all what matters. |
|
|
On 1 April 2016 at 13:23, Thibault Raffaillac <[hidden email]> wrote: There's (hopefully!) no question of throwing it away already. That represents too much work, and pretty good design choices IMO. Yet I'm still pretty new to Pharo/Smalltalk so simply need time. At the moment I am only practicing on a GLFW binding. Hi, Thibault.. don't get me wrong: i am fully supporting any effort to bring cool and fast and fancy graphics tech to Pharo. So, nice to hear from you! There's not much effort in generating calls to numerous GL function - it just a matter of parsing opengl spec and producing appropriate smalltalk code out of it.. The main hurdle, i guess, you may find is service code and GL context wrappers i made to handle extension(s) and dealing with the fact that different extensions may or may not be available depending what kind of context you created. I did it by instantiating a table of function pointers and making a specialized custom ffi callout mechanism, that instead of standard way - looking up for a function pointer once and for the rest of session, doing it individually on a per-context basis. That ensures that you can use different contexts safely without risk of calling a function that is not supported in current context while it was supported in another context, one that you used just before. I don't know how you could preserve such kind of functionality in UFFI.. the only thing i know is that you are much more limited in choice. Sure it could be done.. but would it be as efficient as before (just one extra pointer lookup in table of pointers before making a call)? So, that's what i worry about. Cheers, Best regards,
Igor Stasenko. |
«
Return to Pharo Smalltalk Users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |