mirror of
https://github.com/OpenSpace/OpenSpace.git
synced 2026-04-26 05:58:48 -05:00
700f590a2a
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?
40 lines
1.1 KiB
C++
40 lines
1.1 KiB
C++
#ifndef __RUNTIMEDATA_H__
|
|
#define __RUNTIMEDATA_H__
|
|
|
|
enum increment{
|
|
YEAR, MONTH, DAY, HOUR, MINUTE, SECOND, MILLISECOND
|
|
};
|
|
|
|
struct RuntimeData{
|
|
public:
|
|
RuntimeData() :_openspaceTime(0.0){
|
|
};
|
|
void setTime(double time) { _openspaceTime = time; }
|
|
double getTime() { return _openspaceTime; }
|
|
|
|
// cant come up with proper user friendly-method, this will do.
|
|
void advanceTimeBy(double nr, increment incr){
|
|
switch (incr){
|
|
case YEAR: _openspaceTime += (nr * year); break;
|
|
case MONTH: _openspaceTime += (nr * month); break;
|
|
case DAY: _openspaceTime += (nr * day); break;
|
|
case HOUR: _openspaceTime += (nr * hour); break;
|
|
case MINUTE: _openspaceTime += (nr * minute); break;
|
|
case MILLISECOND: _openspaceTime += (nr * millisec); break;
|
|
default : _openspaceTime += (nr);
|
|
}
|
|
}
|
|
|
|
private:
|
|
double _openspaceTime;
|
|
|
|
double year = 3.154*pow(10, 7);
|
|
double month = 2.628*pow(10, 6);
|
|
double day = 86400;
|
|
double hour = 3600;
|
|
double minute = 60;
|
|
double millisec = 0.001;
|
|
};
|
|
|
|
#endif // __RUNTIMEDATA_H__
|