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 12 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: 
|
Global makes it hard to understand where the variable is used, modified, etc. And static doesn't seem to make any sense since this variable is only created in a function that does lots of other things, so its constructor shouldn't affect performance.
|
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 |
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 hardward 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.
|
The earthshine is fixed now too. |
…bly improve performance" This proves to be a bit less performant, and additionally requires a higher OpenGL version for correct work.
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.