MOARdV
ORBIT_DISPLAY
Schematic rendering like the JSIOrbitDisplay, just using line renderers instead of inefficient GL calls.
Options:
Filled planet instead of a circle (make it easier to understand which line is orbit, which is planet. Same for atmosphere.
Components, Phase 1:
- [x] Display surface / camera / infrastructure
- [x] Ownship orbit renderer
- [x] body / atmosphere renderer
- [x] target orbit renderer
- [x] Maneuver orbit renderer
- [x] Support partial orbits (where there's a start time and/or stop time, such as patches)
- [x] Orbit line width
- [x] Body line width
- [x] ownship orbit colors
- [x] target orbit colors
- [x] maneuver orbit colors
- [x] body/atmo color (overrides automatic color selector)
- [ ] Support hyperbolic orbits
- [ ] Vessel icons
Components, Phase 2:
- [ ] body prime meridian marker, ownship longitude marker, target longitude marker, landing longitude marker
- [ ] Select a patch
- [ ] Query the number of patches in the patchedConicSolver (
fc.???) - [ ] Query planet color / atmo color as strings (
fc.BodyPlanetColor()) to use for color tinting of text. Is this needed?
Different colors for the filled planet depending on which planet we're orbiting?
Different colors for the filled planet depending on which planet we're orbiting?
Yes. And maybe a master override color if the IVA designer wants to control the color directly. And, while I'm at it, maybe a cool fade effect for the atmosphere (although that's such a small slice, it may not be worth the extra work).
Different colors for the filled planet depending on which planet we're orbiting?
It sounds interesting, but only if it does not require a lot of resources and we will be able to change or completely turn off the color fill.
Personally, I use overlapping information text over an orbital map and color filling can make the text less readable, especially small text. so I do not think I'm going to use this feature extensively
What I personally would be interested in getting in the new version of the orbital map is a couple of features:
- A render of some mark of a given longitude, or more correctly, of its projection onto a map. To give the user at least a general idea of the location of the vessel relative to the surface. as the source of the longitude value, there may be:
- zero meridian (light gray color)
- longitude of the target (yellow line if the target is the ship landed on the surface, or a selected Waypoint)
- longitude specified by the user (for example, longitude of KSC or any other random location, blue line),
- and also the longitude of the predicted landing site (if it exists)
- the second feature is the ability to switch the focus of the map to the next body, if the result of the current trajectory or planned maneuver is an encounter
Seeing upcoming orbits would be awesome for planning chained maneuvers. One thing I miss in my IVA is my excessive abuse of conics on the map.
Regarding OP, it's a surprise to me that GL Calls are inefficient, why is the line renderer faster?
Regarding OP, it's a surprise to me that GL Calls are inefficient, why is the line renderer faster?
GL calls are done in immediate mode, which is an artifact of the pre-GPU OpenGL API. Modern GPUs don't support immediate mode, so the GL API or the game engine above it must batch and send that data. Those calls are done every Unity Update() call (including the transforms to put them into the right place on-screen), so that's a lot of recomputing the same data over and over at the mod's level, and sending that data through Unity. The LineRenderer (presumably) is not emulating immediate mode, and it does not require resending data every Update.
That's horrible! Thanks for the information, I would have kept acting on the assumption that using GL is direct hardware - wasn't aware Unity was using such a dated GL API
A lot of stuff to do for this task.
I need to decide how to handle target orbit rendering. I think RPM ignored the argument of periapsis for the orbits it rendered, but I really should account for it - if the target is in an elliptical orbit with a periapsis on the opposite side of the planet from the ownship's periapsis, the relative orbits will be very wrong if I do not account for relative arguments of periapsis. I also need to work out how to handle updating orbit lines - I don't want to update them every Update(), or even every FixedUpdate(). Maybe I can store the orbital parameters in a vector and test them on FixedUpdate() to see if they have changed.
Ah! Here's something: since the orbits will be drawn with LineRenderer, I can allow each line to have two colors (start and end), similar to the ELLIPSE page object. With two colors, I can draw the orbits similar to how the Map View draws them, with startColor where the vessel currently is, and endColor at the end of the orbit (future position).
Very early support for ORBIT_DISPLAY on DropBox. Support for current vessel (for eccentricity < 1.0) and drawing the body that the vessel orbits.
My big request for this feature (and all displays) is the ability to go completely monochrome to emulate an early CRT monitor. Greenscale, that horrible Orangescale I remember from library computers in the 90s, Grayscale... The orbit display with RPM seems not to have the ability to change the color of the body itself, which means the greenscale CRT MFD I'm working on has white in it.
My big request for this feature (and all displays) is the ability to go completely monochrome to emulate an early CRT monitor.
My intent is that you can configure all of the components in the page config - you can override the atmosphere and body colors, set the various orbit colors, etc. That's actually available with the release I did today. See the documentation for a little more detail.
Slow progress. DropBox has the current edition. Renders current orbit, target orbit (if in the same SoI), maneuver node orbit (if in the same SoI), and current body/atmosphere.
The automatic scaling is not perfect if the target or maneuver node has a very different LAN or ArgPe, or a hyperbolic orbit. I will revisit that feature next, I think.
One thing I am not happy with is the automatic colors for bodies / atmospheres. I don't think I have the right values, since they're not very saturated. I've added a hack to gain the colors towards full saturation, but it's ... meh. I could use hard-coded color tables like I use on Distant Object Enhancement, but it would be nice to find a color somewhere in KSP that would work. Maybe I can find the Map mode orbit colors?