- ABufferFixed should work but it doesn't. But the interface works at
least.
- ABufferFixed works for normal rendering
- Removed position for ABuffer, it should make rendering much faster.
Todo:
- Figure out why the fetching of pixelData for ABufferFixed gives wrong
result.
- First draft of the ABuffer visualizer renders a cube with all fragments
from the single linked abuffer. Lua command to turn on is
openspace.visualizeABuffer(true)
- Fixed LuaConsole to stop receiving input command after inputing command
- Fixed LuaConsole not to add command to history if it is identical to the
most recent command.
TODO:
- Add support for dynamic and fixed abuffer
- Scale the cube to match the window ratio
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.
After 32 maya exports and about 600 different attempts of different rotations / scalings along each axis
I realised that the model is in fact correctly aligned and that what we are seing are precisional errors with the
stupid boresight-polygon-baton.
Nevertheless, out of all of those Im keeping some of the more cruicial test-objects (8 to be precise) for future reference,
these can be deleted at some point, I just really want to keep them for now, comfort blanket.
- Fixed so ABuffer reinitializes properly (could probably be optimized by
not resizing of smaller than before)
- Now setting size properly from window dimensions
- SGCT side-by-side stereo working
- Only first version of the RenderablePlane
Todo:
- Support rotation of planes
- Support billboarding
- Support different local origin (LowerLeft, LowerRight, Center...)
- Started working on PowerScaling with some initial changes
- Faking the stars by blending with the abuffer
- Changed texture filtering for planets, looks better in my opinion
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?
- added shader-side B-V (blue-visible band) index conversion to standard RGB 0-255
- distance-modulus is computed correctly (to the 9th decimal) from one of the interleaved parameters of the vbo
- the apparent magnitudes are in relation to the cameras position in space. (needs a proper overlook / calibration)
- sprite quads are scaled with the apparent magnitude in heuristic fashion (ogl coordinates have really no real relation to empirical data)
TODO:
- Look over the quad scaling which right now is scaled using the z-distance and apparent magnitude, wont work properly if we move outside of the solar system
- Determine if scale of universe is proper
- When zooming out the camera stops at #INF and gets stuck ( had no time to look into this )
- Very red stars need dimming, probably a threshold operation
- 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
Jonas Strandstedt