Recent

Author Topic: Provided GL, GLext librarys vs dglOpenGL  (Read 2874 times)

ChrisR

  • Full Member
  • ***
  • Posts: 157
Re: Provided GL, GLext librarys vs dglOpenGL
« Reply #15 on: December 23, 2019, 04:29:35 pm »
Avra,
  I did look at  pl_OpenGL - there are many nice demos that can provide a nice starting point for projects. I have two comments

1. The project '6e_raycast' is based on my code, specifically https://github.com/neurolabusc/vx but it does not include the BSD license. Note this is an old project, using legacy OpenGL. A modern version of this project using Core OpenGL is the render project I provide here https://github.com/neurolabusc/OpenGLCoreTutorials . Finally, an even more recent incarnation of this project is here https://github.com/neurolabusc/Metal-Demos/tree/master/volumerender - with this version being able to be compiled to Core OpenGL on Windows, Linux and MacOS as well as to Metal on MacOS. I would appreciate it if this project included the original license. Links to the modern projects would be helpful.

2. All the projects in pl_OpenGL use legacy OpenGL, with inefficient calls like glBegin/glEnd. I suspect legacy OpenGL will be supported on Windows for many years, and these are elegant demos. However, legacy OpenGL does not use the resources of the graphics card efficiently, and projects that use legacy OpenGL will me much harder to port to Metal/Vulkan than modern OpenGL core projects. Indeed, one can directly port OpenGL Core GLSL shaders to Vulkan's shader format. My Metal-Demos repository shows how one can compile to either Metal or OpenGL Core with relatively minimal changes in the code. Furthermore, users should be aware that legacy OpenGL will make cross platform difficult. First, MacOS will only support legacy OpenGL up to 2.1, so legacy projects on MacOS must not use any modern features. So MacOS users are forced to either choose legacy old OpenGL or modern Core OpenGL without the legacy features. The situation for GTK3 is even more strict: only OpenGL Core is supported when GTK3 detects a modern graphics system. Therefore, legacy OpenGL apps written in Lazarus that run fine using GTK2 will not run on GTK3 (another regression is that GTK3 does not support multi-sampling for OpenGL). This is unfortunate, Ubuntu 19.10 has removed default support for GTK2. Personally, I would recommend Lazarus Linux users who want to target OpenGL to use the QT5 widgetset, which does allow modern OpenGL to run in compatibility mode.

It is unfortunate that there have been so many forks in the high performance graphics world. Legacy OpenGL did make it easy to develop a basic 'Hello World' and helps users get familiar with the concepts. OpenGL Core requires shaders, and removes many of the nice helper functions for matrices. Vulkan takes this one step further, requiring the user to specify many low level details. While more recent APIs do allow higher performance, they do require a huge investment of time. Just like one can choose a high level language or a lower level language, one can choose the correct tool for the graphics they want.

zeljko

  • Hero Member
  • *****
  • Posts: 1144
    • http://wiki.lazarus.freepascal.org/User:Zeljan
Re: Provided GL, GLext librarys vs dglOpenGL
« Reply #16 on: December 23, 2019, 05:31:25 pm »
Note that I'll make some major changes in Qt5 for OpenGL support because of https://bugs.freepascal.org/view.php?id=36342

avra

  • Hero Member
  • *****
  • Posts: 1930
    • Additional info
Re: Provided GL, GLext librarys vs dglOpenGL
« Reply #17 on: December 24, 2019, 08:29:42 am »
The project '6e_raycast' is based on my code, specifically https://github.com/neurolabusc/vx but it does not include the BSD license
Is it OK if I add https://github.com/neurolabusc/vx/blob/master/license.txt to '6e_raycast' dir? I would automate that with my conversion script, and that will work as long as they keep that directory structure. If you give me a green light I will do it like that. I still think that you should also report that to PilotLogic forum, since I can not fix license violation in CodeTyphon (where I get pl_* components from). I can not do that because they banned me after seeing that I have made pl_* open source components available to Lazarus users.
ct2laz - Conversion between Lazarus and CodeTyphon
bithelpers - Bit manipulation for standard types
pasettimino - Siemens S7 PLC lib

JernejL

  • Jr. Member
  • **
  • Posts: 89
Re: Provided GL, GLext librarys vs dglOpenGL
« Reply #18 on: April 13, 2020, 06:27:03 pm »
Regarding original thread - i ended up making my own headers because i was dissattisfied with the state of both dopengl and lazarus's.
 
I think lazarus one can be put on right track, i'd much prefer that to dopengl.
 

 

TinyPortal © 2005-2018