cosmoscout / cosmoscout-vr Goto Github PK

This should be implemented with a secondary image tile source.

Especially at low frame rates this can become very annoying.

The following things need to be done:

All eclipses

• Integrate limb darkening.
• Cache the shadow textures for reuse.
• Generate lookup textures at perihelion and aphelion and interpolate between them to get better results for eccentric orbits.
• The shadow textures should have an exponential scale on the vertical axis with the origin at the start of the penumbra.
• The eclipse shader extension should use prefixes for all definitions to avoid name collisions.

Eclipses without atmospheres

• The ray tracer needs to work in 3D.
• Fix the wrong conversion factor in the photon tracer shader.
• Do all calculations in double precision.
• The lookup tables for the density and refractive indices should be a texture instead of an SSBO.
• Move the texture tracing to the GPU. (NVIDIA has atomic floats)
• (To enhance precision it might be worth having the origin at the bottom of the atmosphere instead of the body center.)

Eclipses with atmospheres

• Generation of texture can be done on the GPU with a compute shader.

CosmoScout VR currently doesn't compile with MinGW.

Known issues:

• Curl doesn't compile, because it is missing the function recv
• OpenSG is confused about which operating system it is compiled for

This is hard to reproduce and requires some more investigation. Sometimes the application crashes when data outside of the SPICE kernel coverage is requested.

This should be solved using the .gitattributes file.

This should be implemented with a secondary texture.

cps-fly-to-locations and csp-sattelites are missing #include <string> in their respective Plugin.hpp files.

Without importing <string> building cosomoscout will fail.

It's simply not required that this is done in a DFN node. This makes the code much more difficult to understand and maintain.

It's simply not required that this is done in a DFN node. This makes the code much more difficult to understand and maintain.

It is not clear where issues should be reported: In the main CosmoScout VR repository or in the individual submodules?

The Problem

Simple 2D/3D geometric types and algorithms related to them (intersections, areas, volumes, distances) are implemented multiple times throughout the application and scattered over plugins.

The Solution

Create a small glm based utility package that implements common geometric types and related functions.

The Alternatives

Instead of developing it beforehand, the types and algorithms can be created on demand in the core engine.
So each time a new geometric type gets created for some functionality in a plugin it should be put in the core engines utility namespace, where it can be reused by other plugins.

Common Types

2D

• Circle
• Rectangle
• Square
• Triangle
• Line
• Ray
• Curve
• Spline

3D

• Sphere
• AABB
• Box
• Cube
• Polygon
• Line
• Ray
• Curve
• Spline
• Plane

There are cases which are hard to reproduce where the application hangs for several seconds when the simulation time changes quickly.

For now it seems to happen only in cluster mode.

It's simply not required that this is done in a DFN node. This makes the code much more difficult to understand and maintain.

This should include:

• The most recent git tag
• The branch name
• The current commit hash

I added the cmake to my PATH enviroment variable to start compiling but make_externals.bat failed due to the invalid parameter "--parallel 8". After removing the argument, make_externals.bat just works fine.

When using the auto-fly-to option to another planet, the target latitude and longitude is wrong if the simulation time differs from the system time.

Describe the Bug

Using the fly-to-locations feature with MSL results in MSL always having the focus for rotation.

Steps to reproduce the behavior:

1. Go to fly to locations in the GUI
2. Click MSL
3. Zoom out
4. Try to rotate around Mars with left click pressed

Expected Behavior

The rotational center should be Mars when zooming out.

System

• CosmoScout VR version 1.1.0
• OS: SLED12
• Compiler: GCC 8.1.0
• Graphics Card: NVIDIA QUADRO P6000

Several shaders of CosmoScout VR require #version 430. Do we really need this?

Due to the refactoring in the gl-calls in WorldSpaceGuiArea are useless now. As a result, GuiItems in the WorldSpaceGuiArea are not drawn to their proper positions.

The Problem

When started for the very first time, users are greeted with a black screen for several minutes, as the example data is downloaded.

The Solution

The progress of the individual downloads should be printed on the loading screen.

This should include

• Current simulation time
• Current observer position and rotation
• State of all GUI options

Currently the time speed is goes from realtime directly to hours, which in some applications is to coarse.

I suggest adding minutes to the possible speeds.

Add a document which explains:

• How releases are named.
• How releases are created.

A lot of shaders are querying the location of uniforms every frame, which should be avoided.
The uniform locations should be queries once after the shader has been linked and saved for reuse.

I propose the following convention for caching uniforms in a render class.

class SomeRenderer : public IVistaOpenGLDraw {
  public:
    SomeRenderer() {
        /* compile shader and link shader */
        mUniforms.mvp = glGetUniformLocation(mShader, "uMVP");
        mUniforms.color = glGetUniformLocation(mShader, "uColor");
        mUniforms.sunLocation = glGetUniformLocation(mShader, "uSunLocation");
    }

    /* ... */
  private:
    /* ... */

    uint32_t mShader;

    struct {
        uint32_t mvp;
        uint32_t color;
        uint32_t sunLocation;
    } mUniforms;
}

Classes wich query uniforms every frame:

cs-core

• tools/Mark.cpp

cs-graphics

• MouseRay.cpp

cs-gui

• ScreenSpaceGuiArea.cpp
• WorldSpaceGuiArea.cpp
• SpriteGui.cpp

cs-scene

• Trajectory.cpp

csp-atmospheres

• VistaAtmosphere.cpp

csp-lod-bodies

• TileRenderer.cpp
• PlanetShader.cpp

csp-measurement-tools

• PolygonTool.cpp
• DipStrikeTool.cpp
• EllipseTool.cpp
• PathTool.cpp

csp-rings

• Ring.cpp

csp-sharad

• Sharad.cpp

csp-simple-bodies

• SimpleBody.cpp

csp-stars

• Stars.cpp

csp-trajectories

• DeepSpaceDot.cpp
• SunFlare.cpp

I am currently performing some experiments in feature/actions. Here is the current status:

• Build on Windows
• Build on Linux with gcc
• Build on Linux with clang
• Run clang-format validation
• Trigger CI with pushes to master and develop
• Trigger CI for pull requests
• Trigger CI with [run-ci] in commit messages
• Experiment with OSX builds
• Use github actions to produce binary builds for windows and linux
• Upload binary builds directly to Github release
• Use some kind of cache to speed up builds

It would be great, if a notification is shown, when the user travels to a planet or a pre-defined location on a planet.

The windows start scripts (start.bat and vive.bat) should behave similar to the Linux start script (start.sh).

When being on Mars, selecting Olympus Mons as fly-to-target crashes the application.

Especially at low frame rates, the observer moves much to quickly to a planet's surface.

The Problem

Double or multi click events with the Web GUI elements are not supported at the moment

The Solution

Measure time between two clicks and increase click count

The Alternatives

None

Document the project setup with different IDEs.

• Visual Studio
• Visual Studio Code
• Sublime
• CLion
  • Linux
  • Windows
• QT Creator
• Eclipse?
• CodeBlocks?

There are several classes which are instantiated multiple times with each instance having an identical shader program. This should be optimized! Here are some classes which are affected:

• WorldSpaceGuiArea.hpp
• ScreenSpaceGuiArea.hpp
• Trajectory.hpp
• Mark.hpp
• Sunflare.hpp
• DeepSpaceDot.hpp
• SimpleBody.hpp
• Sharad.hpp
• Ring.hpp
• PolygonTool.hpp
• PathTool.hpp
• EllipseTool.hpp
• DipStrikeTool.hpp

This should be now in the csp-fly-to-locations plugin.

Building glew through make_externals.bat fails with the following error:

This seems to be related to: nigels-com/glew#180
Using the proposed fix from: https://gitlab.com/ssrobins/conan-glew/blob/stable/CMakeLists.diff resolves the issue and glew builds without errors

Using VS2019 with MSVC 141

Check for errors in the config and catch them to prevent crashes. Also give the user useful feedback.

• core
• anchor-labels
• atmospheres
• fly-to-locations
• lod-bodies
• measurement-tools
• rings
• satellites
• sharad
• simple-bodies
• stars
• trajectories

It is only used in there.

The current implementation for manipulating the simulation time is very cumbersome.

When interacting with gui elements e.g. moving a draggable html element, the focus/events get lost in CosmoScout VR when leaving the visible element. These events should be working until the mouse is released

It would be great if plugins checked out to the plugins directory would not need to be registered in the plugins/CMakeLists.txt.

This CMakeLists.txt should loop over all plugin directories. In order to enable or disable building a specific plugin, an option should be added to each and every plugin's CMakeLists.txt.

The current implementation of cascaded shadow maps can be significantly improved by automatically adjusting the shadow parameters at run time. A possible approach might be to check the current depth range.

Some externals have to compiled in debug mode, too.