search

OCESS / orbitx

Rewrite of OrbitV, maintained by Patrick, Gavin, and contributors
MIT License
10 stars 18 forks source link

WIP: Landing graphics of a sphere segment #61

Closed pmelanson closed 5 years ago

pmelanson commented 5 years ago

Graphically, this code needs to be improved a little bit (for example, why does the landing graphic flicker?)

But for now, Kyoung would you be able to adapt this to use the new API? Feel free to change it to your satisfaction, architecture-wise. For example, there definitely could be a new file to come out of this, and it looks appropriate to derive this from Displayable.

Thank you so much! I very much appreciate it

goodday0404 commented 5 years ago

I am wondering

  1. why do we need to draw landing graphic only for target and reference?
  2. What happens if we change target or reference?
  3. any performance issue if we draw landing graphic for all planets?
  4. any special reason that we need to change name set_origin to new_origin?
  5. in _draw function, why do we need to update origin, target, and reference using "common.find_entity" instead of new_target(or origin, reference)?
pmelanson commented 5 years ago

Thanks for taking a look, I appreciate it.

  1. and 3. drawing a landing graphic is significantly more work than just drawing a sphere. I didn't put this in any comments (and maybe I should have), but drawing a landing graphic for every planet takes about 10 seconds at startup. So either we can:

    • just have the program not do anything for 10 seconds (seems bad)
    • have a background thread create new landing graphics so the rest of the program can keep executing (requires thread synchronization, prone to bugs)
    • or just draw a few landing graphics that we care about. We could either draw the landing graphic for the closest body, which would require finding out what the closest body is and dynamically switching landing graphics, or just let the user decide what bodies they care about by setting reference and target. I chose the latter, because it was the simplest to implement, and we're near the end of this project. Also, during real-life operation, everybody always lands on a planet while they have it set to be either reference or the target.

  2. When we change reference or target, the old ref/targ will lose its landing graphic and the new ref/targ will start drawing a landing graphic. I think this is good-enough behaviour for now, although after this project is done I'll see if I can come up with a better solution.

A note on that, currently if, say, we're landed on our reference the Earth but we have the Moon set as the target, focusing the camera on the Moon will show an ugly rendering of the landing graphic. I would like to eventually make the landing graphic become more transparent the further the habitat is from it, like your code for your first piece of work on landing graphics did, but I don't want to add too much functionality without incorporating your GUI refactor.

    1. This is actually kind of a mistake, and we can take it out. Initially, one of my solutions for updating landing graphics required a distinction between updating the ORT every tick, and setting a new ORT when the user makes a selection in the drop-down menu. However, there's no distinction anymore, so if you want I can remove this change (or if it's easier, you can remove it, or not).

How does this sound? Thank you so much for taking a look, and feel free to suggest anything for me to do before you incorporate this.