Intersections with planet and instrument FOV boundary vectors / boresight seem to be correct with a margin of error. This could be either due to
precision issues experienced at greater distances, light-time or stellar aberration correction methods, planetary radius etc etc.
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?
At this moment only the (by NAIF considered) most cruicial
c_spice API's have been covered, such as getting state vectors
from one reference frame to another, simple time conversions,
load/unload of single and multiple kernels etc. All of which as
described in:
http://naif.jpl.nasa.gov/pub/naif/toolkit_docs/C/info/mostused.html
Also added linker flag to except the LIBCMTD.lib as it caused conflicts
on Windows.
