Commit Graph

8 Commits

Author SHA1 Message Date
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
michal
7bd44efc8e code optimization, cleanup. 2014-08-30 21:33:30 -04:00
michal
7e078352d0 Fixes to shader pipeline.
- Added second shader for points only
- VBO interleaved array passed to both shaders
- passthrough in geom. shader works
- reading of additional scalar data from speck files.

TODO: calibrate scale and apparent brightnesses
2014-08-30 16:40:44 -04:00
michal
b1851e5313 Added geometry shader for halos and separate shader for points. Parsecs->m conversion works and added test-data to datafolder. 2014-08-28 23:04:27 -04:00
michal
8f3bcdeb54 WIP3: problems with texture coordinates, needs fix. 2014-08-26 19:26:09 -04:00
michal
013d4c5bb6 WIP: intermediary commit, will attempt to run HC's code on this machine. 2014-08-25 17:37:23 -04:00
michal
d75171c69b Added new class renderablestars.cpp for rendering starfields.
As for now only reads and stores *.speck file data.

TODO:
1. write cache mechaninsm (load avg ~15 sec)
2. fix render function.
3. add textures.
2014-08-20 11:29:31 -04:00