Linux playground

[GLS]

OK, I think I finally got it, there was still a uint16_t remaining somewhere...
I can't push a fix now, if you want to test it, it's in OGLMesh.h in class OGLMesh, struct GROUPREC definition.
There is a :

        uint16_t nIdx;           // number of indices

that needs to be changed to :

        uint32_t nIdx;           // number of indices

Is that really the issue? Looks like it works in Windows with 16b... If the mesh has less than 65536 vertices it should all work.

 

[Jordan]

Is that really the issue? Looks like it works in Windows with 16b... If the mesh has less than 65536 vertices it should all work.

Yes, that solves the problem. I don't know why it didn't work before, because Windows only uses 16 bit.

@Gondos
Pay attention to the buttons in the top left, if you enlarge the window immediately before the scenery is started, the buttons are clickable. This can be used as a temporary solution until you have solved the problem.

 

[Gondos]

Is that really the issue? Looks like it works in Windows with 16b... If the mesh has less than 65536 vertices it should all work.

The 16bit limitation is for the number of vertices, the index buffer can be larger than that (I checked the D3D client, it is using a DWORD for the number of indices)

 

[Gondos]

I cannot reproduce your seams issues
Can you try with antialiasing turned on? (uncomment the "// glfwWindowHint(GLFW_SAMPLES, 4);" in OGLClient.cpp)

 

[Jordan]

I cannot reproduce your seams issues
Can you try with antialiasing turned on? (uncomment the "// glfwWindowHint(GLFW_SAMPLES, 4);" in OGLClient.cpp)
View attachment 28884

That's it. Just have the feeling that it is a bit slower, which is also to be expected.

Edit: Commenting out the line again and selecting "Override Applications Settings" in the NVIDIA configuration and setting the antialiasing higher than 0 also helps.

 

[Gondos]

That's it. Just have the feeling that it is a bit slower, which is also to be expected.

Edit: Commenting out the line again and selecting "Override Applications Settings" in the NVIDIA configuration and setting the antialiasing higher than 0 also helps.

Looks like a driver bug then

 

[Jordan]

@Gondos
I installed the xorg drivers for testing, same problem, without antialiasing the seams are visible.

 

[n72.75]

 

[Gondos]

I may have found the cullprit.
Can you try by removing these lines in OGLClient.cpp?

    glEnable( GL_POLYGON_SMOOTH );
    glHint( GL_POLYGON_SMOOTH_HINT, GL_NICEST );

 

[Jordan]

I may have found the cullprit.
Can you try by removing these lines in OGLClient.cpp?

    glEnable( GL_POLYGON_SMOOTH );
    glHint( GL_POLYGON_SMOOTH_HINT, GL_NICEST );

Nice find. It works. Antialiasing turned off in NVIDIA Settings, no seams artifacts.

But I discovered another BUG. If I zoom out, in the outside view, then clipping occurs. For example, here in the NASSP scenery "Apollo 11 - 02 - Before Launch T-30sec.scn" flight time 115sec. See screenshot.

 

[Gondos]

Nice find. It works. Antialiasing turned off in NVIDIA Settings, no seams artifacts.

But I discovered another BUG. If I zoom out, in the outside view, then clipping occurs. For example, here in the NASSP scenery "Apollo 11 - 02 - Before Launch T-30sec.scn" flight time 115sec. See screenshot.

Yeah, welcome to alpha quality software ^^
I noticed that bug even from up close, there are a couple of seconds when the rocket is half hidden soon after launch.
I have no idea where it comes from, I'm currently trying to run orbiter with floating point exceptions turned on to see if there are some divide by zero errors in the camera code but so far I'm stymied by a ton of other arithmetic exceptions before I get to this point in the launch procedure?
Edit: no fpu exception, looks like an issue when going through the cloud layer, there is some camera voodoo going on in the couldmgr2
Edit2 : it's a z-buffer issue, the D3D client disables zwriting when rendering the planets. It fixes the clipping issue when I do the same but some geometry now appears through the surface on the launch pad.
I wonder if the frustrum hacks that were implemented back when z-buffers were 16bits are still necessary with 24bits ones...

 

[Gondos]

I just pushed a bunch of crap to github, it should fix the clipping issue. I hope I didn't mess something up with the submodules...

 

[Jordan]

I just pushed a bunch of crap to github, it should fix the clipping issue. I hope I didn't mess something up with the submodules...

Zooming Rotating no clipping at all.

Next bug, after the S-IC separation, you are moved backwards in the VC, so that the VC is far ahead of you.

Speaking of submodules. When compiling, a file named "UCSO" is created in "/orbiter_linux/orbiter_test/orbiter/build/Orbitersdk/include" and compiling stops. After renaming the file or deleting (maybe, haven't tested it) it compiles without error.

 

[Gondos]

Zooming Rotating no clipping at all.

Next bug, after the S-IC separation, you are moved backwards in the VC, so that the VC is far ahead of you.

Yep, and the CSM door opens on stage separation, no immediate cause comes to mind...

Speaking of submodules. When compiling, a file named "UCSO" is created in "/orbiter_linux/orbiter_test/orbiter/build/Orbitersdk/include" and compiling stops. After renaming the file or deleting (maybe, haven't tested it) it compiles without error.

Should be fixed

 

[Matias Saibene]

Dear @Gondos I have good news for you!
I've finally tried Orbiter on Linux and I was able to open the G42-200 scenario and get it ready to fly without much trouble.
The only problem is that again Orbiter does not detect the + key to add or start thrust. I tried it on the G42-200 and the DeltaGlider (DGS too).
I attach the build log, the run log and a neofetch log showing my system info.
Apart from that small inconvenience I have had no problems.

You are doing an excellent job porting Orbiter to Linux.

 

[Gondos]

Dear @Gondos I have good news for you!
I've finally tried Orbiter on Linux and I was able to open the G42-200 scenario and get it ready to fly without much trouble.
The only problem is that again Orbiter does not detect the + key to add or start thrust. I tried it on the G42-200 and the DeltaGlider (DGS too).
I attach the build log, the run log and a neofetch log showing my system info.
Apart from that small inconvenience I have had no problems.

You are doing an excellent job porting Orbiter to Linux.
View attachment 29028

There's nothing much to it, the code for this bird is really clean and was a breath of fresh air
Most kudos go to the original developers who responsibly open-sourced their work to make that possible

 

[Gondos]

OK, I'm a bit less clueless regarding the camera issue on Apollo staging. It has to do with the center of gravity shifting but I must be missing something because I rechecked the OGL code against the D3D client and I can't find an explanation so far... I don't even know if it's the camera or the mesh that's in the wrong place...
On top of that, if I jettison the tower on the launchpad, the view is offset as well as misoriented so it's not a translation only issue ?
Edit: Hum, if I enable the cockpit mesh from the outside, I get this after LET jettison, so it looks like it's a mesh position/transformation issue...

 

[yitianetie]

Hi everyone,

I am particularly impressed by your replies and screenshots. Despite the artifacts and bugs, It seems promising. I will try on my side later when I will be more available. Just a question about the MFD : I remember when i tried Orbiter with wine and Vulkan, I got huge performance drop with some sophisticated MFDs, especially on XR fleet, and not so on Windows. Do you still have this performance drop with the native version you are testing ?

Warmest regards

 

[Jordan]

Edit: Hum, if I enable the cockpit mesh from the outside, I get this after LET jettison, so it looks like it's a mesh position/transformation issue...

How do you do that?

 

[Gondos]

How do you do that?

In VVessel.cpp, there's a bunch of tests that you can comment to do that :

        if (bCockpit) {
            if (internalpass && (vismode & MESHVIS_EXTPASS)) continue;
            if (!(vismode & MESHVIS_COCKPIT)) {
                if ((!bVC) || (!(vismode & MESHVIS_VC))) continue;
            }
        } else {
            if (!(vismode & MESHVIS_EXTERNAL)) continue;
        }