Add support for proper lunar mesh instead of the ellipse#4835
Add support for proper lunar mesh instead of the ellipse#483510110111 wants to merge 7 commits intoStellarium:masterfrom
Conversation
|
Great PR! Please pay attention to the following items before merging: Files matching
This is an automatically generated QA checklist based on modified files. |
|
Sounds terrific, even before trying. But yes, a separate switch please for the "lighter" systems (2010 field laptops, Raspberries, ...). |
|
Very nice! I'm not sure why, but for some reason the Earthlight is broken: 
|
|
Hmm... I see no changes when toggle support 3D models for SSO |
Of course, I said in the OP that this switch is currently missing. |
Oh, yeah! My eyes missed this part... |
|
OK, so now the toggle between the sphere and the proper mesh should work. |
|
The earthshine still seems to look different from |
|
The earthshine is fixed now too. |
|
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
This makes them mostly independent from mesh density, which is especially noticeable near the poles when mesh density is low.
The model is not in the Wavefront OBJ format, because the textual nature would inflate the size of already rather large model and reduce loading speed. Instead, the format is as follows: 0 uint32 number of vertices, N 4 uint32 number of indices, M 8 float32 minimum radius 12 float32 maximum radius 16 uint16[3*N] array of altered spherical coordinates (see below) 16+3*2*N uint32[M] array of indices The spherical coordinates are stored as triples of uint16, in the following order: 1. Radial coordinate linearly remapped so that value=0 means rMin and value=65535 means rMax, 2. Elevation of the vertex linearly remapped so that value=0 means -PI/2 and value=65535 means PI/2, 3. Azimuth of the vertex linearly remapped so that value=0 means -PI and value=65535 means PI.
This drastically improves performance of lunar mesh rendering on ASUS ProArt PX13 with AMD Radeon 890M (from 8 FPS to 33 FPS).
The imprecision of the hardware implementation of sin leads to broken geometry of the Moon every 0.9° of elevation.
Before this patch a model would be shown at the same time as a survey, which would result in ugly overlapping and generally not make sense.
|
Conflicts have been resolved. A maintainer will review the pull request shortly. |
We require at least CMake 3.18 because of the use of ARCHIVE_EXTRACT.
|
Seems I'm missing something.
The moon is not rendered (stars are visible), but the Nomenclature marks (crater ovals) are there. Ah, reading helps... :-) unpacked the mesh file, restarted. WOW! That lunar rim is simply insane! And now somebody has to observe occultations.... I still should test with RPi3/4 and my smaller field laptops. |
Wait, what? Unpacking should happen automatically at CMake stage. Did it not work for you? |
|
I did not investigate at which stage CMake would unpack. After switching to the branch, QtCreator detects new files and triggers CMake to prepare compilation (with previously configured plugins, NLS, PCH, etc.), then I compile and run inside QtCreator. No install step, if that's where unpacking might happen. |
4 participants
This is a WIP implementation of the lunar mesh, which helps us get
What's currently missing:
This should obeyflagUseObjModelsand resort to the old sphere-based rendering when it's disabled. Or maybe add a separate feature flag, since the other models are much more lightweight?This implementation includes a 44 MiB lunar mesh in a custom binary format optimized for compressibility, so its 7zip archive is only 7 MiB. This archive is what's contained in the repo, and it gets extracted on installation, so the installers will get the 44 MiB input. I hope that in particular Inno Setup will be able to achieve a similar compression. Of all compressors only 7zip and lzma/xz achieve about 7 MiB size, others (bzip2, gzip) appear to be much less efficient (13 MiB and 21 MiB, respectively). I chose 7zip because CMake supports it out of the box.
The worst-case performance of displaying only the Moon fullscreen at 0.3° FoV on my ASUS ProArt PX13 (with AMD Radeon 890M) dropped from 42 FPS to 33 FPS, which seems fair for the improvement achieved. On Zenbook UX333F with Intel UHD Graphics 620 the drop is from 16 FPS to 4.4 FPS, which is why it's desirable to fix the ability to turn the feature off.
I don't intend for this to get into 26.1, since it's likely to break some other aspect of planet rendering, so I suppose it should aim at 26.2.