Page 45 of 48

Posted: 29.06.2020, 09:25
by 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. :-)

Posted: 29.06.2020, 14:53
by 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. ... 87ee37b465d80774bcfc8b9dad48ae

Posted: 29.06.2020, 15:51
by 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.

Posted: 29.06.2020, 20:41
by 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?


Posted: 30.06.2020, 05:42
by onetwothree
Meson invocation is "meson srcdir builddir" so it should be:

Code: Select all

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

Posted: 30.06.2020, 06:41
by Markerz

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?

Posted: 30.06.2020, 07:31
by onetwothree
maybe using renderdoc, i used it on gnu/linux. but is works with gl es build only

Posted: 30.06.2020, 11:40
by 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.

Screen Shot 2020-06-30 at 7.38.46 PM.png

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..

Screen Shot 2020-06-30 at 10.27.43 PM.png

or use glEnableVertexAttribArray

Screen Shot 2020-06-30 at 10.46.21 PM.png

Posted: 30.06.2020, 18:05
by 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.

Posted: 30.06.2020, 21:37
by onetwothree
Markerz wrote:or use glEnableVertexAttribArray

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

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

Renderdoc doesn't support GL2.1.

Posted: 30.06.2020, 23:58
by Markerz
this is the minimum change

Posted: 01.07.2020, 08:11
by onetwothree
So this looks like another bug in macos :)

Posted: 01.07.2020, 10:23
by 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.

Posted: 01.07.2020, 11:08
by 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.

Posted: 01.07.2020, 12:16
by onetwothree
Markerz wrote: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

Posted: 01.07.2020, 13:22
by Markerz
@Dimmi72 we already found the cause, it might be macOS being a bad citizen in implementing OpenGL. will be fixed by this

Posted: 01.07.2020, 14:00
by Dimmi72
Ah, that's great news... :-) looking forward for the next test build. :-)

Posted: 01.07.2020, 14:07
by Markerz
you can test here for the fix ... 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)

Posted: 01.07.2020, 14:44
by 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.

Posted: 03.07.2020, 05:16
by 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.