Celestia 1.7.0 Development Thread

[Dimmi72]

So it might be a minor error in the code and it could probably be fixed. That would be great, because the MacOS Version runs really smooth except this minor problem. I like this version a lot and if this could be fixed it would be far better. :-)

[Markerz]

it is just weird that on Mac, planets/moons don't render while stars render well as point, while on iOS, neither renders. But with MetalANGLE, both are working well.

the bad commit seems to be this one cause the moons not to render.
https://github.com/CelestiaProject/Celestia/pull/ ... 87ee37b465d80774bcfc8b9dad48ae

[Dimmi72]

Hi Markerz,

I don't know if it is of any importance, but I did find a slight difference in the differently coloured codes.

The moons do render on IOS as well as circle, the do not render on MacOS.

[Janus]

Sorry if this is the wrong place to ask, but I have a question.

Why was glew dropped in favor of libepoxy?

I have been swamped with work for a few months, and I finally get a chance to catch up.
Apparently glew has been replaced with libepoxy, fine, whatever.
I grabbed libepoxy, put it in place, tried a compile.

I get a missing file warnings, gl_generated.h, which I cannot find anywhere.
Eventually, I discovered it has to be generated on a system by system basis, using something called meson.

Got meson, {0.54.3}, extracted into a directory.
Put a copy of libepoxy in a dir under meson.
Opened an admin cmd prompt.
Tried 'meson epoxy/src'
Tried 'meson epoxy/include/epoxy
Made no difference.

Made a fresh VM since I do not let random stuff on my system, installed meson {0.54.3}, no change.

Main binary: C:\Meson\meson.exe
Build Options:
Python system: Windows
The Meson build system
Version: 0.54.3
Source dir: C:\Meson\epoxy\include\epoxy
Build dir: C:\Meson
Build type: native build

ERROR: First statement must be a call to project

Any thoughts on actually getting this to work?


Janus.

[onetwothree]

Meson invocation is "meson srcdir builddir" so it should be:

Code: Select all

cd c:\meson\epoxy
md build
meson . build


[Markerz]

@Dimmi72

the related code for point moons/planets not rendering should be in render.cpp starting from line 1786 in renderPoint method.

@onetwothree, is there any possible way to debug it?

[onetwothree]

maybe using renderdoc, i used it on gnu/linux. but is works with gl es build only

[Markerz]

No good tool for macOS for OpenGL, I used Apitrace, which it says to offer replay, but it didn't work for me, there is only a list of frames and calls.

Added after 2 hours 49 minutes:
bringing glBegin/glEnd is not the right way to fix it, but it can be fixed in this way.... lol but probably @onetwothree you have the idea what is (might be) wrong here..

or use glEnableVertexAttribArray

[Dimmi72]

Hi Markerz,

there are Nightly Builds of Renderdoc for MacOS, I don't know how reliable they are.

And there should be two tools for GL Testing in Xcode. Maybe they help.

[onetwothree]

or use glEnableVertexAttribArray

You also added glDrawElements instead of glDrawArrays. What is minimal required change? glEnableVertexAttribArray or glDrawElements or both?

there are Nightly Builds of Renderdoc for MacOS, I don't know how reliable they are.

Renderdoc doesn't support GL2.1.

[Markerz]

this is the minimum change

[onetwothree]

So this looks like another bug in macos

[Markerz]

looks like an apple bug and specific to macOS, even on iOS it is fine. I tested on macOS 10.15.5 on either NVIDIA/AMD(both probably backed by Metal), and macOS 11.0 in VMware (no gpu accelerate so should be just OpenGL), it produces the same result. How should we work around this then.

[Dimmi72]

Hi Markerz,

I took the render.cpp and copied it to Xcode in a Metal File, I don't know if this is of any help.

[onetwothree]

How should we work around this then.

let's apply your current workaround. with the comment that this is required to fix bugs on macos

[Markerz]

@Dimmi72 we already found the cause, it might be macOS being a bad citizen in implementing OpenGL. will be fixed by this https://github.com/CelestiaProject/Celestia/pull/791

[Dimmi72]

Ah, that's great news... :-) looking forward for the next test build. :-)

[Markerz]

you can test here for the fix

https://install.appcenter.ms/orgs/celestiaproject ... ribution_groups/public testers

Also, I released two updates for iOS, one with Metal, one without, you can test them on TestFlight. The build 36 does not have metal and uses libepoxy like other frontends, the build 35 (you should be able to find in "Previous builds") uses Metal(ANGLE)

[Dimmi72]

Hi Markerz,

I just tested the newest IOS apps, build (36). When texture setting are on hight, Saturn is black. The rings and moons show, but Saturn seems to be a black sphere. When I turn to medium and low settings, it shows.

In build(35), it runs normal, shows Saturn even when on texture setting high. I think it runs a little cooler and it runs smoother (especially when the star names are shown in the demo).


For the new MacOS build, it works now with the moons showing. Great job. And the yaw roll pitch now works with command.

[Dimmi72]

Hi Markerz,

I was testing several AddOns and I figured that virtual textures only work when placed into textures directory in the program. I wonder if it would be possible to add a textures folder in the library directory that is created by the program and make that available, same as the extras and script folder? Because when I update now, I have to copy the virtual textures to a folder, update the program and copy them back to textures in the program, while the AddOns in the library directory stay untouched.

Virtual textures seem to work only when in the textures folder.