Post #452by Janus » 11.07.2019, 06:31
@john71
One of the things games do with 3D is presort things, which means everything, according to vector and distance.
This reduces the dependence on Z buffers for depth sorting at the display stage.
Basically, layers are drawn starting with the most distant, growing progressively closer until clipping.
Celestia does almost none of that.
Basically, it starts with DSOs, then moves closer, at first.
However, asteroids, comets and planets along with moons don't have a consistent display depth.
With everything in motion, including the observer, it hands the display handler a real mess.
One way that might, and I say might, help, sounds counter intuitive.
Keep DSOs, clusters, stars, etc done first.
When working in a solar system, instead of adding directly to the display stack.
You hand off the commands to a stack that sorts by vector/depth as you add to it.
You then hand the whole stack off at once, with vector and in particular depth, already mixed together in order.
This reduces the real overhead because you only do depth once, when adding it, not for every single item.
Right now the display handler has to do a depth check for every single item you add.
Or, look at this way, right now a bubble sort by depth is being done for every item, with each item added making the next sort slower.
The display stack, which can be a simple stack, or even a C++ vector or list, can be sorted just the once.
The secret is to index base coordinates for each item using dot norm or .norm() which equates to length.
list.insert_item_at(item, list.closest(item.norm()))
This is a pseudo-code approximation, but it conveys the point, or so I hope.
Look up the index of the closest match by distance or dot norm, then insert at that index.
In a lot of ways, it is just a prerender sorting system indexed by depth, then vector.
Janus.
I just wanted to highlight this problem.