- 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)
Projection now occurs only at specified timestamps.
Todo:
projection class now dependent on image sequences, will have
to change that once we read specific instrument schedule.
- ImageSequencer class added, requires planetary data service files (not added to openspace-data, too large)
: Given current time returns path to specific image in dataset for projection.
- Changes to RenderablePlanetProjection class to accomodate sequencing
- Fixed normal computation in reverse-mapping stage
- Rudimental target recognition (will prob. become part of separate class at some point - since both fov & proj classes do similar things)
Next up:
- Redo pluto mockup visualization & begin spreadsheet reader for instrument-switching.
TODO:
- fixes so it reads mission specific modfile keywords (ie targets)
- speedup using one more pass (vertex map generated every something-frame)
- sequencing (timestamp check + load of separate images on-the-fly)
- pass in geometric data of target + target-texture switching (later)
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?
