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?
