Provided GL, GLext librarys vs dglOpenGL

[ChrisR]

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]

Note that I'll make some major changes in Qt5 for OpenGL support because of https://bugs.freepascal.org/view.php?id=36342

[avra]

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.

[JernejL]

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.
 

[Seenkao]

Для понимания!
"Устаревший" OpenGL, давно удалён из OpenGL. В Версии 3.3 точно. Но! Это зависит от видеокарты пользователя.
На новых видеокартах "устаревший" OpenGL - эмулируется. Поэтому, в некоторых случаях, вы не потеряете в производительности используя "устаревший" OpenGL. Но! При этом, вы полностью сохраните совместимость со старыми видеокартами.

google translate:
For understanding!
"Deprecated" OpenGL, removed from OpenGL long ago. In Version 3.3, exactly. But! It depends on the user's video card.
On new video cards "outdated" OpenGL is emulated. Therefore, in some cases, you will not lose in performance using the "legacy" OpenGL. But! At the same time, you will fully maintain compatibility with old video cards.

[ChrisR]

1. The license for my raycast project is included with the source project. It would be nice to have this included:
  https://github.com/neurolabusc/vx

2. I agree that for Linux and Windows (but not MacOS), you can mix-and-match legacy and modern OpenGL. These operating systems support OpenGL, and well coded legacy OpenGL can be as efficient as modern OpenGL. There are two reasons I prefer modern OpenGL. First, it abandons immediate mode, so the code only uses the efficient modes that better leverage GPU hardware. Second, it is a lot easier to port code to other platforms (MacOS, or handheld devices that use OpenGL ES).

[Seenkao]

Давайте смотреть объективно. Я ни кого не принуждаю использовать "устаревший" OpenGL и, так же не принуждаю пользоваться "новым".
Всё зависит от создаваемого приложения и от разработчика который будет выбирать, что ему использовать.

Но по поводу MacOS и OpenGL ES, я не совсем согласен, но "новый" OpenGL более совместим, только на начальном уровне, когда узнаёшь лучше, то вполне понимаешь, что OpenGL ES - это сильно урезанная версия OpeGL, и в любом случае, надо будет доделывать многое, для использования OpenGL ES как (вместо) OpenGL. Если, конечно, не использовать библиотеки, где это всё уже реализовано. Но опять же и в "устаревшем" OpenGL ES так же есть реализации OpenGL.
А MacOS, ни как не влияет, на OpenGL, кроме выбора версии OpenGL. А если выбран "устаревший" OpenGL, то тут уже зависит от того, какая видеокарта. Если старая, то будет работать немедленный доступ, если новая, то будет простая эмуляция "устаревшего" режима.

И, не стоит забывать, что на "устаревшем" OpenGL некоторые вещи мы в любом случае не сможем сделать, так как в "новом".

google translate:
Let's look objectively. I do not force anyone to use the "outdated" OpenGL, and I also do not force anyone to use the "new" one.
It all depends on the application being created and on the developer who will choose what to use.

But about MacOS and OpenGL ES, I don't quite agree, but the "new" OpenGL is more compatible, only at the initial level, when you get to know better, then you quite understand that OpenGL ES is a heavily stripped-down version of OpeGL, and in any case, it is necessary will do a lot to use OpenGL ES as (instead of) OpenGL. Unless, of course, you use libraries where all this has already been implemented. But again, the "legacy" OpenGL ES also has OpenGL implementations.
And MacOS doesn't affect OpenGL in any way, except for the choice of the OpenGL version. And if "outdated" OpenGL is selected, then it already depends on what video card. If an old video card, then immediate access will work, if a new one, then there will be a simple emulation of the "outdated" mode.

And, do not forget that on the "outdated" OpenGL we will not be able to do some things anyway, as in the "new" one.

[avra]

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.

I did not receive a reply from ChrisR neither here neither via PM, so I will delete '6e_raycast' directory from pl_opengl package examples in new ct4laz. If someone has an objection for any other directory or package, please report it.

[ChrisR]

You are free to use my code as long as you respect the license. The included license is a simple BSD 2-Clause license, which requires you to include the license when you share the code.
  https://opensource.org/licenses/BSD-2-Clause
This is a permissive license that is fully compatible with sharing. You can even use my code in professional projects without paying me anything, as long as you include the license.

[avra]

You are free to use my code as long as you respect the license. The included license is a simple BSD 2-Clause license, which requires you to include the license when you share the code.
  https://opensource.org/licenses/BSD-2-Clause
This is a permissive license that is fully compatible with sharing. You can even use my code in professional projects without paying me anything, as long as you include the license.

I have already finished packing pl_opengl for new ct4laz and '6e_raycast' dir is excluded. If you have any other directory that you wish excluded please say so. If you give me your mail in private message, I can send you pl_opengl for full check before official release. There will also be RC candidate available for a while.

At the end I have decided not to be the one who should fix this specific CodeTyphon licensing issue, and as with all previously known cases I will exclude reported code from ct4laz. So, the real address for fixing issues will be PilotLogic. Once they have your license back into sources - I can include that dir again.