semarsip / osghimmel Goto Github PK

Move the compositional intensity handling to Himmel, and only pass a uniform to 
each geode.

If a user want's to apply a specific intensity handling via HDRR or Temporal 
Glares etc. we should not scale the intensity values into visible ranges 
ourself.

these are highly optimizable (e.g., just check the HDR function and others).
this shader consumes most of the time..

Branch name:
/trunk

Purpose of code changes on this branch:
decide whether or not to refactor all shader fragments

When reviewing my code changes, please focus on:
can usage of individual shader objects per shader fragment simplify their 
structure, usage, and maintainability? if so, apply refactoring.

split the moon in two or more vertical stripes, for each aquire the refraction 
corrected height and scale the v-component in the moons fragment shader by 
linear interpolation within the stripes.

Branch name:
/trunk

Purpose of code changes on this branch:
The following naming scheme for glsl shaders should be applied:
* uniform variables begin with u_: uniform mat4 u_razInverse;
* varying variables begin with v_: out vec4 v_ray;
* attributes begin with a_

After the review, I'll merge this branch into:
/trunk

Create filter or adjusted noise generators to provide the full spectrum of 
A-Clouds (namely Cirrus, CirroCumulus, CirroStratus, and AltoStratus).
These should be automatically used based on an assigned enum paramter, all 
within the highcloudlayer geode.

There currently already is a moon glare for screenshot purposes only.
It does not scale well for the moons dynamic lighting and completely ignores  
lunar eclipses.
This could be done on cpu side, based on the lunar phase.

[deleted issue]

There are currently no issues concerning problems, but it would be more 
convenient to have all shaders strictly applying to a standard.

What is the expected output? What do you see instead?
All shader fragments are strictly applying version 150.

Currently, in each frame a high resolution texture is composed, based on 
multiple noise tiles with different octaves and resolutions each.
This is done to provide dynamic movement and shape dynamics for clouds.
There are several problems with this approach: Most of the detail is only 
required towards the zenith. At the horizon only a tiny fraction is required 
(first noise layer).

Simple idea: use sphere-map projection to provide a better detail distribution 
for the case of hemisphere mapping, that we obviously have here. This also 
allows to substantially lower the resolution (probably 1/8th of the area)

the bright stars do not align with the intensity distribution of the star-map. 
There seem to be two milky-ways...

gcc build was tested earlier this year, but not again since then...
there should be some minor issues at most...

The mapping of random values generated per star and per frame are non uniformly 
distributed to provide more natural looking scintillations.
This mapping should be adjustable (e.g., the exponent, currently 8).

Somehow the sun's z position is not considered. So during day-night transitions 
and at night, clouds are totally wrong.

Furthermore at night, the earth shadow should be considered, so no scattering 
for clouds at all..

For the moon, one could use a low resolution grid (e.g., 16x16 Texture) with 
random variations in optical density.
These than should be cause interpolated deformations of the moons' surface and 
its edge.
For the sun only a radial variation in the fragment-distance check could be 
sufficient, since the suns' surface is not perceivable by eye.

Cleanup the whole class, revisit and optimize the shader.

If each star is refraction corrected in the vertex shader, scintillations can 
probably be applied to the optical depth and be expressed as wavelength 
dependent refraction variation.
The look-up in the starmap has to be refraction corrected too.

Use CPack in CMake to configure the archive. 

Depending on which options where set on project configuration, the package 
should contain all binaries from apps and required OpenSceneGraph and Qt 
binaries as well as all Resources (e.g. textures and 3d geometry) in a flat 
hierarchy.

This is highly useful, for interchanging builds for status reports, or 
generating tagged archives for the Downloads section. Until no install process 
is required, this should suffice.

http://zfx.info/viewtopic.php?f=11&t=8
and
http://zfx.info/viewtopic.php?f=5&t=1298
show how to get physical more correct intensity values for stars and glares...

Instead of compose the cloud maps per frame in a render to texture step, a 3D 
Texture with multiple slices representing different times could be used instead 
and would massively reduce texture access for cloud rendering.

Fix the movement in AbstractMappedHimmel::update().
If more time is available :D implement a nice interface for specifying the 
movement in a simple, elegant way.

Changing the scattering influence factor for the star map has no influence.
Scattering should be turned on and off, on off do not compile the scattering 
function.

Check the minimal sampling rate, in this case the minimal star diameter.

The fov invariation (u_q) is used in mutliple himmel geodes.
Encapsulate the few lines of code and provide them from a single location in in 
a unique way.
Probably move to Himmel and update there..

For simplicity, just add the sources from QtPropertyBrowser 
[http://qt.gitorious.org/qt-solutions/qt-solutions/trees/master/qtpropertybrowse
r here] to the apps/3rdp folder, build and link as static lib.

Currently each geode implements its own cattering weight and needs to 
recalculate the air mass over and over again. Optimize this function to a 
minium and apply scattering uniformly over all geodes.

apply the moons' resolution and fov independent antialiasing to the suns' disc.

If an texture is specified, this is used as tile for the ground. 
Additional to this, the tile mapping size could be specified and influence the 
perceived altitude of the viewer.

This however, requires anisotropic filtering of the ground texture.

If there is no dynamic time required, the static vertices list passed to the 
gpu could be optimized for a fixed date, time, and location by applying 
refraction correction and annual proper motions.