Status of GLScene for Lazarus (Linux)

[silvercoder70]

What is the status of GLScene for Lazarus? And then for Linux?

My setup is Linux Mint, Lazarus (latest). I do have a Windows in a VM and would prefer not to have to touch that.

I checked out a couple of the threads in relation to this and problems people encountered. I tried the one downloaded via the Online Package Manager (1.0?) and that does not build/install. And I know there are other versions out there. But my questions are simple (?):

Is there a known working version of GLScene for Lazarus?
Is there a known working version of GLScene for Lazarus that works on Linux?
What version is it?

[Handoko]

GLScene is an interesting project. I haven't really tested it seriously. But I had bad experience with it. If you want to know more, read here:

https://forum.lazarus.freepascal.org/index.php/topic,52088.msg383311.html#msg383311

[TRon]

Is there a known working version of GLScene for Lazarus that works on Linux?

How can there be ?

The SF project page states: "GLScene Engine for Delphi & C++Builder VCL Windows 32/64"

Now, there is some work done to compile with Lazarus but afaik that is all there is.

fwiw: I've managed to be able to find 6 related github and/or sf pages and other websites mentioning glscene (or lzscene and none of them re able to clear up any questions, there is no proper versioning so all is left to the imagination of the user. Even our own ccr is a mess for this project. I personally wouldn't touch it with a ten-foot pole (with all respect to the original author because on windows it was a wonderful project).

See also this post from WP (it might be that you need to modify the link manually because the forum software decided by reason of insanity to add/remove the session id)

[silvercoder70]

I had found different versions online (some forked etc) and before I went down to the road of trying them all out (not really) I wondered if there was any "recommended" version. While there might be information on one page about support, when you get to that page it reads differently. Hence the question.

[FangQ]

I have been using glscene in one of my lazarsus projects over the last 10+ years. It has been reliable and stable. For Ubuntu 14.04 - 20.04 with Lazarus 2.x (2.0, 2.1, 2.2, ...), I had always been able to install it conveniently using the built in "Online package manager" and it runs without any issue.

However, this breaks in newer Linux, such as Ubuntu 22.04 (it appears to be unrelated to lazarus version, because the following error appears regardless of the lazarus version)

I have been reliably getting the following error

GLViewer.pas(41,21) Error: Forward declaration not solved "class WSRegisterClass;"

When asking this error on google, Germini suggests that this has something to do with gtk2 vs gtk3, but rebuilding lazarus with either gtk2 or gtk3 did not help - rebuilt IDE - lazarus 4.2, won't display correctly with gtk3; rebuilt with gtk2 still shows the same error.

when installing lazarus 2.0.x on Ubuntu 22.04, I am getting the same error, but it runs without any problem when testing on Ubuntu 18.04

would be much appreciated if someone can suggest a way to install glscene on Ubuntu 22.04, even with the older lazarus versions

[BrunoK]

I cant test with linux but adding the lines marked with ~bk in the IFDEF linux for WSRegisterClass  might work.

Note that I'm not (edit) knowledgeable about linux ...

Attachment : attempt at correcting GLViewer.pas

[wp]

Tested GLScene available in OPM:

No, this does not help because TGLSOpenGLControl exists in unit GLWidgetContext only inside a windows-only define. I passed this blocker by putting the call to "class procedure WSRegisterClass" inside a MSWINDOWS define in the interface part too:

Code: Pascal  [Select][+][-]

1.   TGLSceneViewer = class(GLLCLViewer.TGLSceneViewer)
2.   public
3.   {$IFDEF MSWINDOWS}
4.     class procedure WSRegisterClass; override;
5.   {$ENDIF}
6.   end;
7.  

The next issue is in unit GLSceneForm at another WSRegisterClass. Here I put the entire implementation code inside an MSWINDOWS define:

Code: Pascal  [Select][+][-]

1. class procedure TGLSceneForm.WSRegisterClass;
2. const
3.   Registered : Boolean = False;
4. begin
5.   {$IFDEF MSWINDOWS}
6.   if Registered then
7.     Exit;
8.   inherited WSRegisterClass;
9.   RegisterWSComponent(TGLSceneForm, TGLSOpenGLForm);
10.   Registered := True;
11.   {$ENDIF}
12. end;

Now the runtime package compiles and the designtime package installs.

I am not a user of GLScene and just checked whether I could run some of the sample projects under Linux. I was able to run the Plot3D sample (in examples/MathApps), but only after replacing in the uses clause the "windows" unit by "LCLIntf, LCLType" and rewriting the line {$R CURSORS.RES} as {$R Cursors.res}. In the Chaos example I had to replace the "windows" unit by "LCLIntf, LCLType" as well, and I had to add unit cthreads to the top of the project's uses clause. I could not run Collisions/Raycast/SphereSweep project, and then I gave up.

So, in total, GLScene basically is working in Linux, but the sample projects are in a bad shape.

[BrunoK]

I dont know if it was addressed to me but the implementation off the LCL widgetset code for
    class function CreateHandle(const AWinControl: TWinControl; const AParams: TCreateParams): HWND; override; is different for linux than for windows, thus I think the target widgetset must be bound to the linux widget subclass version.

I'm probably wrong if you tested the code and it did work. So ignore my code.

[BrunoK]

Remark on wp's TGLSceneForm.WSRegisterClass;
Skipping the call to inherited WSRegisterClass; for non windows widgetset's may cause them to be incorrectly bound inside their TWSLCLComponent tree bindings. So either they have an implementation of WSRegisterClass including the inherited call that insures tree inheritance consistency or left out to the default behavior of component creation and registering.

It would be nice that someone test the changes on linux.

wp, can you test and make your comments.

In the joined zip :
  GLScene\GLSceneLCL\Source units that should replace the CCR distribution
    GLViewer.pas - as proposed by wp
   .\DesignTime\GLSceneForm.pas - as suggested by wp taking in account my above comment re WSRegisterClass

  \GLScene\GLSceneLCL\Examples projects revisited to suppress Windows dependency
    Superellipsoid2
   SphereSweep
    Airplanes, uses a GLViewer component that was causing touble   
   
   

[wp]

In a second run I changed the MSWINDOWS define in TGLSceneForm.WSRegisterClass such that it removes the entire procedure now (rather than just the contents as before), and it makes no difference.

Code: Pascal  [Select][+][-]

1. {$IFDEF MSWINDOWS}
2. class prcoedure WSRegisterClass; override;
3. {$ENDIF}

I tested the three projects that you mentioned, and they all run - but they require quite a lot of rework (I am sure that nobody tested them under Linux before...):

• Add cthreads to the uses clause of the project unit.
• Specify the Destination file name in the project settings so that the binary is written next to the texture files needed, otherwise the files are not found.
• Usually rewrite {$R CURSORS.RES} to {$R Cursors.res}
• Occasionally remove the Windows unit and replace it by LCLType and LCLIntf.
• Replace Windows backslashes by Linux forward slashes.
• In the Airplanes sample I renamed all image files to lowercase and called LowerCase() on the filenames whenever they were loaded.

Saying that the demos were running, though, does not mean that they are correct. Look at the two screenshot taken from the Airplanes demo. The Windows screenshot looks correct, but the Linux screenshot looks as if the outside surfaces are missing and allow a look into the airplane. I do remember that there is a "culling" parameter in OpenGL which defines which face of a surface is "outside" - maybe there are differences between Linux and Windows there?