Commit Graph

4 Commits

Author SHA1 Message Date
Alexander Bock
a6ebddb8eb Updated copyright header in all files 2015-02-17 14:20:03 +01:00
Alexander Bock
4de8071efe Force all Renderables to declare an 'isReady' function to circumvent assertion triggers when a crucial element of initialization fails
Fix velocity in RenderableStars
2014-11-28 01:41:26 +01:00
Alexander Bock
7359adf400 Replaced RuntimeData with separate, temporary structs that are passed around 2014-09-26 13:29:01 +02:00
michal
700f590a2a SPICE-time dependency, retrieval of spice ephemerides and rotational matrix + coordinate references.
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?
2014-09-19 20:32:33 -04:00