Change some interfaces on SpiceManager
Removed target position return in powerscaled coordinates and only use glm::dvec4 instead as the Spice library does not have higher accuracy anyway
Shadow cylinders extending from planet terminator in opposite dir of sun
Plane that displays the global texture map of a planet as projections appear
^latter is an addition to RenderablePlane class, a renderable plane can have
boolean keyword "ProjectionListener" - determines whether or not it displays
Store frames for bodies in SpiceManager, still adding "IAU_" if
no frame is added for the body. Adding frames in renderableModel for
67p to get proper inertial frame.
- When loading SPICE kernels, coverage for each body is stored.
- If the body does not have spk coverage a position is estimated.
- Added "pulsating" transparency levels for renderableModels with
estimated position.
- Spice manager clean up, left a few unused methods but removed a lot of
dead code.
- To support multiple missins being loaded, some errors are simply
ignored in spicemanager, for better or worse.
- Added start time and stop time as dictionary keys for renderables.
- Made RenderableTrails only show the time between gaps.
- Added but out commented vesta coordinate system swich in renderengine.
NOTE: Renderables using spiceEphemeris will give errors if body keyword
is omitted in modfile (When checking SPK coverage in position update).
Instead of spheres, the planets are now created as triaxial ellipsoids
according to the corresponding radii values in the SPICE kernels (if such
values are available). Apart from being more scientifically accurate, the
planets are shaped as the intersection functions in SPICE expects.
The textures will now also be aligned in longitude as in reality (w.r.t.
UTC) when using a texture map ranging from -180 in the left end to +180 on the
right, with 0 longitude in the middle (such as Greenwich in Earth texture)
The rest is pretty straight forward, renderable trail is the ephemeris class and wavefrontobject is a very crudely constructed reader... ill fix that on monday
Added functionality:
- New class renderablesphericalgrid is repurposed code from powerscaledsphere class.
Due to z-buffer issues used as reference grid to confirm planetary orbits are correct.
This has been a major problem as prior we had no visual reference.
Now we have a Galactic-, Celestial- and Ecliptic-coordinate grid.
To this also added separate shader: grid_vs.glsl / grid_fs.glsl
These grids have a static-rotational matrix derived from partiview (thanks to Brian)
since spice req. to-from frame to compute rotational matrix.
Time dependency:
- Added struct RuntimeData - which for now only contains openspace time and is passed to all renderables
- All renderables accept runtimeData, keep private reference and use for computation of rotational matrix
- This obviously carries corresponding changes to Scenegraph and ScenegraphNode.
Spicemanager:
- Added function that more easily provides access to rotational matrix used in spice
(used in renderableplanet for computing planetary objects spin around axis)
Ephemeris-classes:
- Now compute ephemeris from spice based on timeepoch in runtimedata
TODO: once z-buffer fixed - set ephemeris correctly as meters (not kilometers)
Renderengine:
- Advances time with the advanceTime method in RuntimeData struct
ISSUES:
- Our Y axis NOT same as SPICE or star-catalogue, all renderables rotated now 90deg, needs redefinition,
lots of debugging and major headaches before this conclusion.
- Depth buffer needs to be fixed in order to properly place planets.
- Spice kernels have finite time-range, when time stops - simulation ends - ugly fix: reset time to zero.
Possible fix: kernels de431 (part 1-2) cover huge timespan and most likely have functions to extrapolate time,
drawback is that they are 1,7 gb each.
TODO:
- Compute and draw dynamic ephemeries for each renderable. Either do full year sweep then update for each point or
create a tail of linesegments for each planet. Dont know yet how to do this, would like spicephemeris to be
sub-class of Renderable (have own render() method) - good/bad?
Alexander Bock