Development of cross-platform programs for 2D-3D graphics

[LBox]

Is it possible to develop cross-platform (Win, Mac, Linux) programs in Lazarus for 2D-3D graphics and animation
like Adobe After Effects, Fusion, Nuke, Blender, Cinema4D, 3dMax, etc.? 

If yes, will it be possible to do this with a single code base without spending a lot of time on compatibility with three different platforms?

Thanks in advance to everyone ✌

[vercetti]

List of cross-platform raster/vector/3D graphics libraries https://wiki.freepascal.org/Graphics_libraries

[BlueIcaro]

Hi, take a look: https://castle-engine.io/

/BlueIcaro

[LBox]

List of cross-platform raster/vector/3D graphics libraries https://wiki.freepascal.org/Graphics_libraries

Thanks for the link. Very useful information. As I understood from the table provided,
the BGRA library is the most advanced of all existing ones.

By the way, while searching, I came across another very cool SDL library www.libsdl.org,
and it is strange that it is not mentioned on the table in the link above.

Hi, take a look: https://castle-engine.io/

Yes, I have heard about the Castle engine and its author deserves respect for the great work done,
but alas, from the video presentations that I have seen, I get the impression that Castle is still very raw,
or the presentations do not reveal the full potential of this engine.

[Warfley]

Taking the example of blender, how this is usually done is, they first write a general engine, which has some platform dependant code in it. This engine defines the basic rendering tools. Then the actual application logic and UI is written platform independent in that engine. This is why the UI and buttons in blender have a very unique look and the UI behaves very differently from the typical winapi forms or macos cocoa applications.

Doing this is a lot of effort, as you basically maintain two projects, the engine and the in engine editor, but you get as a result a fully portable system.
It's not just with blender, it's for example also the exact same thing with the Godot game engine, where the editor is basically just a program written in the very same engine.

There is an fpc based game engine the castle engine, which you can probably use as rendering engine, so you might consider this to start of with. I personally have no experience with it, but I think the maintainer frequents this Forum

[Seenkao]

Если вы хотите использовать для этого LCL, то вы столкнётесь с проблемой интерфейса. Интерфейс вашей программы будет по разному выглядеть по разному на разных платформах.
Для того чтоб интерфейс выглядел везде одинаково, надо использовать инструменты, которые не используют LCL. Зачастую это однооконные программы основанные на OpenGL или Vulkan (для MacOS - Metal, желательно). Много ли реализаций интерфейса для OpenGL/Vulkan/Metal ? Я не знаю. Вероятно мало, основные силы сосредоточены именно на LCL. Если вы хотите именно чтоб на каждой ОС весь интерфейс выглядел одинаково, то очень большая вероятность, что вам придётся многое делать вручную (но может быть кто-то подскажет, где есть уже реализованные интерфейсы).

By the way, while searching, I came across another very cool SDL library www.libsdl.org,
and it is strange that it is not mentioned on the table in the link above.

Альтернатива SDL на Паскале - ZenGL.

Google translate:
If you want to use LCL for this, you will face the problem of the interface. The interface of your program will look different on different platforms.
In order for the interface to look the same everywhere, you need to use tools that do not use LCL. Often these are single-window programs based on OpenGL or Vulkan (for MacOS - Metal, preferably). Are there many implementations of the interface for OpenGL / Vulkan / Metal? I do not know. Probably few, the main efforts are concentrated on LCL. If you want the entire interface to look the same on each OS, then it is very likely that you will have to do a lot manually (but maybe someone will tell you where there are already implemented interfaces).

By the way, while searching, I came across another very cool SDL library www.libsdl.org, and it is strange that it is not mentioned on the table in the link above.

An alternative to SDL in Pascal is ZenGL.

[VisualLab]

Taking the example of blender, how this is usually done is, they first write a general engine, which has some platform dependant code in it. This engine defines the basic rendering tools. Then the actual application logic and UI is written platform independent in that engine. This is why the UI and buttons in blender have a very unique look and the UI behaves very differently from the typical winapi forms or macos cocoa applications.

When making such a decision, it would be necessary to consider the "other side of the coin". Users of specific OSes generally prefer software tailored to the OS, and therefore also the GUI. Deviations usually cause irritation among users who find the program's operation unintuitive (surprising). Blender has a reputation for having a strange and underdeveloped GUI, although this has improved somewhat over the last few years. Only a few, die-hard users praised Blender's UI. This is not the only such case. We can recall the history of the TrueSpace program by Caligari (https://en.wikipedia.org/wiki/TrueSpace), which is no longer developed today. It belonged to the same category as Blender (and other previously mentioned 3D editors). It also had an unusual GUI and was also criticized for it (and also had a handful of admirers, just like Blender). It is not without reason that the creators of the most popular 3D editors do not use fancy GUIs and strange ways of working.

However, if the program is intended for personal use or for a team of developers (graphic designers) who are also involved in UI design, then the above suggestion does not matter.

[Warfley]

When making such a decision, it would be necessary to consider the "other side of the coin". Users of specific OSes generally prefer software tailored to the OS, and therefore also the GUI. Deviations usually cause irritation among users who find the program's operation unintuitive (surprising).

This is only half true. Look at the most popular applications. The most popular Office Suite is Microsoft office, which has a full custom design. The most popular code Editor is VSCode also fully custom design. Music player: Spotify, chat Client: Discord, Browser: Chrome, Creative App: Photoshop, etc. all have complete custom UIs and don't use any standard controls (at least for the main controls, office for example has a lot of standard buttons in extended dialogs).
I can't think of a single extremely popular app that uses native UIs. Users love custom UIs if they are good. The problem is when you use a custom UI and it's bad. Infact for many applications their custom UI becomes part of ther Brand and unique selling point. I can recognize VSCode or Photoshop with my glasses off from a distance because of the unique way it looks.

Native UI is always an "acceptable" default. Not good but also not bad. So it's more like: If you aren't good at UI/UX design, e.g. because you don't have UI/UX designers in your team, better stick with the proven defaults. If you have good designers go wild and make something great.

And you can often see that with OpenSource vs Proprietary software. To stick with Blender, Blender has a very unintuitive Design, but it's not because it's custom, just because it's bad. Cinema4D for example (the other 3D Software I have experience with) also has a complete custom UI, but it's usually praised for it's UI and UX and how intuitive it is as the best 3D program for beginners (at least it was back when I used it, which is over a decade ago). Same with Gimp vs Photoshop, both custom UIs, but Photoshop is praised and Gimp is frowned upon.

[VisualLab]

When making such a decision, it would be necessary to consider the "other side of the coin". Users of specific OSes generally prefer software tailored to the OS, and therefore also the GUI. Deviations usually cause irritation among users who find the program's operation unintuitive (surprising).

This is only half true. Look at the most popular applications. The most popular Office Suite is Microsoft office, which has a full custom design. The most popular code Editor is VSCode also fully custom design. Music player: Spotify, chat Client: Discord, Browser: Chrome, Creative App: Photoshop, etc. all have complete custom UIs and don't use any standard controls (at least for the main controls, office for example has a lot of standard buttons in extended dialogs).
I can't think of a single extremely popular app that uses native UIs. Users love custom UIs if they are good. The problem is when you use a custom UI and it's bad. Infact for many applications their custom UI becomes part of ther Brand and unique selling point. I can recognize VSCode or Photoshop with my glasses off from a distance because of the unique way it looks.

Native UI is always an "acceptable" default. Not good but also not bad. So it's more like: If you aren't good at UI/UX design, e.g. because you don't have UI/UX designers in your team, better stick with the proven defaults. If you have good designers go wild and make something great.

And you can often see that with OpenSource vs Proprietary software. To stick with Blender, Blender has a very unintuitive Design, but it's not because it's custom, just because it's bad. Cinema4D for example (the other 3D Software I have experience with) also has a complete custom UI, but it's usually praised for it's UI and UX and how intuitive it is as the best 3D program for beginners (at least it was back when I used it, which is over a decade ago). Same with Gimp vs Photoshop, both custom UIs, but Photoshop is praised and Gimp is frowned upon.

Perhaps I should clarify what I wrote. Because the "devil is" in the difference between the look & feel of GUI controls and the libraries used to build the GUI. For example, the GUI of MS Office, Adobe applications (e.g. Photoshop, Audition, etc.) or Cinema 4D or Maya does not contain any very fancy controls. It is true that they differ slightly in graphic style from the standard ones available in the OS. And it is true that the libraries are probably non-standard (i.e. developed for internal use by teams of programmers in these companies). I also agree that their UI is carefully and aesthetically designed. The problem with the standard GUI is the lack (or limited) styling possibilities.

In my opinion, in Blender or TrueSpace these differences are much greater than in the above-mentioned applications. They have quite abstract GUIs. In the 90s of the 20th century, some programs (e.g. multimedia or utility programs) had such strange GUIs (rather rare today). On the other hand, GIMP, in my opinion, has a fairly standard GUI (I mainly mean the controls). In its case, you can immediately feel that it was built using GTK (as we know, this is why this library was created, before it started to live its own life).

On the other hand, "programs" written using HTML/CSS/JS are basically a program-like product. It's just like in the 1970s and 1980s, chocolate-like products were produced in communist countries in Europe due to the lack of currency to purchase appropriate raw materials. In the case of the creators of these program-like products, there is a lack of: knowledge, patience, experience and willingness to acquire this knowledge ("it has to be made as quickly as possible, from anything, it doesn't matter that it will put a heavy load on the processor and eat up a lot of RAM"). So they "make" such IT monsters (although VSC imitates real GUI quite successfully, its flaws have already been discussed in several threads on this forum).

[LBox]

Wow!
Thank you all very much for such an interesting discussion of this topic, because it helps beginners like me choose the right path or at least identify the main ones.

I will say right away that writing an engine, and then building UI on its basis is definitely not my path, because I want to separate UI from the engine and start with UI.

It is also important for me that UI looks the same on all three platforms. As I understand it, the BGRA library can help me with this, although there are also a couple of controllers that are missing, which means I will need to learn how to write my own controllers based on this library or assemble them like a constructor from existing ones.

As for the engine part of the program, it would be visible only in special viewports such as the scene view and camera view.

Well, as I understand it, the engine itself will be based on OpenGL and I will only need to decide whether to take one of the ready-made ones or write it from scratch.
I like the first way more because writing an engine from scratch is difficult and time-consuming, and there is probably no point in reinventing the wheel.

In any case, the engine is still a long way off