Board index FlightGear Development Effects and shaders

Implementing moonlight (or not)

An exciting "new" option in FlightGear, that includes reflections, lightmaps, the particle system etc.. A lot is yet to be discovered/implemented!

Re: Implementing moonlight (or not)

Postby bugman » Mon Jan 11, 2016 2:09 pm

Thorsten wrote in Mon Jan 11, 2016 11:50 am:
I am however starting to get the impression that some parts/operations in common to many shaders that could be shifted out of this and into FGLight::update() and encoded directly into the GL light source settings.


The function called is indeed the same for many shaders and all pixels, but the values in the function call are different for every pixel.

The reason I put light computations to the shader in the first place is that doing it on the CPU is insufficient.


That's true. But do all mathematical lighting operations -absolutely all- need to be per pixel per frame? Surely some base computational operations do not need to be run at this frequency. Have you considered shifting anything in the ALS framework from the shader into a much lower frequency updated CPU operation? For example calculating the moon lighting intensity once per second is perfectly fine - this looks very smooth in sim. Hence my current code does this on the CPU in non-FPS limiting code paths, and not GPU (also allowing this to be shared with the default renderer and Rembrandt, once I hook it up). Though this may become noticeable when I start modelling moonrises and moonsets when the sun zenith > 115 deg.

Is ALS not in any way already bound by the GL light source, which is updated - position and settings - once a second?


It is, and watching the terminator during a sunrise in the tropics where the sun moves fast, you see it.


I have the following in my ~/.bashrc file:

Code: Select all
alias fgfs_tropical_sunset="fgfs --aircraft=ufo --altitude=100 --lat=0 --lon=0 --timeofday=dusk"


Do you mean the gradient lines in the sky that move and tick like clockwork? I thought about it but I haven't seen a way to send an OpenGL light source on a smooth trajectory.

All rendering pipelines should aim to follow the real life illumination models, so there will be many common illumination concepts.


I guess I disagree. I'm not attached to any particular illumination model but to what looks most realistic. For instance, it by and large makes no sense to render a specular channel for our terrain, because while the triangles are nominally flat, the real terrain they're supposed to represent is not. Allowing a specular channel gives you bad results then. It makes no sense to render much directional light on trees, because while the quads are flat, the tree they're supposed to represent is a complex arrangement of leaves pointing in all directions and being partially translucent. So whether a surface of the quad is nominally shaded is a bad proxy for whether the tree would be shaded.

If 'the usual way' doesn't work for me, I do it differently. The whole point of programmable shaders is to allow this freedom and go away from operations and model assumptions hard coded by the GPU manufacturer.

I'm not disagreeing with your general approach here, but I strongly suspect the directional moonlight needs a custom job in ALS shader by shader to mesh with the rest.

Which still is worth doing I think.


I know that we will need to customise the shaders one-by-one, and ALS will be rather special. However I do intend to set ambient, diffuse and specular values on the GL light source number 0 for the moonlight and have this updated on the CPU once per second. This can then be used as needed in the shaders. It will remove the need for reading the value of "/environment/moonlight", and I suspect that pulling it out of gl_LightSource[0].ambient, gl_LightSource[0].diffuse, and gl_LightSource[0].specular will be much quicker that accessing the property tree. I also intend to shift the following repetitive shader operation onto the CPU side:

Code: Select all
vec3 moonLightColor = vec3 (0.095, 0.095, 0.15) * moonlight;


The value of moonlight is updated via "/environment/moonlight" once per second, so the vector operation can benefit from also running at this non-FPS critical frequency. The resultant vector can be encoded into gl_LightSource[0].ambient for the shader to read. I still have a lot to investigate. For example gl_LightSource[0].ambient is used in some ALS shaders. But this value is multipled by _fog_color in the FG Viewer. But _fog_color is multiplied by the square of sky_brightness. But at night, sky_brightness in $FG_ROOT/Lighting/specular is zero for sun zenith angles > 115 degrees. I have to look at all these algorithms and what is in the end used in the default and ALS shaders. There are a few ALS shaders which appear to use the resultant ambient light value:

Code: Select all
[edward@localhost Shaders (directional_moonlight)]$
  BRANCH: directional_moonlight  (cce6c58) / 3 uncommitted changes                                                                                                                                                 
$ grep "gl_LightSource\[0].ambient" *ALS*
building-model-ALS-ultra.vert:                                    * (gl_LightModel.ambient + gl_LightSource[0].ambient);
model-ALS-ultra.frag:    //vec4 ambient = gl_LightModel.ambient + gl_LightSource[0].ambient;
model-ALS-ultra.vert:                                     * (gl_LightModel.ambient + gl_LightSource[0].ambient);
model-ALS-wingflex-organic.vert:                                          * (gl_LightModel.ambient + gl_LightSource[0].ambient);
space-ALS-ultra.vert:                                     * (gl_LightModel.ambient + gl_LightSource[0].ambient);


In any case, the inconsistencies between all the shaders means that this will take a long time to properly integrate. I'm starting to wonder if I should make FGLight::update() ALS-aware so that the fog-handling can be made rendering pipeline specific.

Regards,
Edward
bugman
Moderator
 
Posts: 1525
Joined: Thu Mar 19, 2015 9:01 am
Version: next

Re: Implementing moonlight (or not)

Postby Thorsten » Mon Jan 11, 2016 4:17 pm

Surely some base computational operations do not need to be run at this frequency.


The nature of operations somewhat restricts what you can pass to a shader to uniforms (constants per draw) or uniform tables (i.e. textures).

There is a cost for looking up n-dimensional tables per frame, it is not a cheap operation, and often it's cheaper to re-compute the table if the involved functions are simple enough (polynomials, exponentials,... ) Also, the number of textures you can pass to a shader is limited, and for the more complex effects we are at the limit.

If you look at the shader structure, whatever is slowly updating and can be cast in the form of uniforms is computed outside GLSL ((by property rules or AW) and simply passed - for instance the whole model how the atmosphere and clouds block light vertically is computed outside the shaders.

Doing graphically relevant operations not once per frame but at a slower update rate opens a whole new can of worms, because you get uneven frame spacing - if you do lots of work once per second, you get a noticeable delay every second. Most people perceive that as worse than a lower but uniform framerate. So if you start getting into this, you need to carefully stagger computations such that you still do roughly the same amount of work per frame (unless you have a very predictable case, like updating the Shuttle displays where we know that one display is going to be pretty much 1/11 of all displays) it's a bad idea to do it.

Do you mean the gradient lines in the sky that move and tick like clockwork?


Yeah, those as well. They'd smoothly morph with a smooth position update.

I also intend to shift the following repetitive shader operation onto the CPU side:


It pre-supposes we want in fact the same moonlight color in all rendering frameworks. Which we do not, because the perception model used by ALS is different from what Rembrandt and default use. Nights in default and Rembrandt are much brighter, so to make moonlight illuminate anything you will have to set values which are wildly too bright in ALS.

In any case, a multiplication costs so little we can add a few hundred more before you can measure the effect. Not what makes a graphics card sweat.

There are a few ALS shaders which appear to use the resultant ambient light value:


Good catch, but they actually don't. It used to be the high quality model shader shared vertex shader with default, so the vertex shader still computes stuff for default. When Emilian split the shaders, he didn't remove these computations. I guess I'll clean this up. The rest is copy/paste by yours truly without doing the cleaning.

In any case, the inconsistencies between all the shaders means that this will take a long time to properly integrate.


There is no inconsistency between the shaders - a ton of work has gone into making them all one consistent framework. There's usually a lot of thinking and experiments involved in how light is treated in the different shaders to make it that consistent.

If you want to entertain yourself, work out what the color of a fog pixel in general should be - given that the fog you see is not at the position of the object fogged but somewhere in between, and given that the light might be low and might illuminate the fog differently from the object being fogged and given that upper fog layers shadow lower fog layers :-)

I don't know how much of this you want to do yourself, but I can simply write the lighting functions for one shader and you can generalize this if you're after the learning experience. For me, it's probably the work of an afternoon or two to do all once I have the moon position as a uniform vec3, but you don't need to work out all the intricacies of ALS yourself (you still can if you like...) since I know them already.
Thorsten
 
Posts: 9921
Joined: Mon Nov 02, 2009 8:33 am

Re: Implementing moonlight (or not)

Postby bugman » Mon Jan 11, 2016 5:36 pm

Thorsten wrote in Mon Jan 11, 2016 4:17 pm:
Surely some base computational operations do not need to be run at this frequency.


The nature of operations somewhat restricts what you can pass to a shader to uniforms (constants per draw) or uniform tables (i.e. textures)...


I'm thinking for the illumination via sunlight and moonlight, and a series of functions to transition the lighting for all scenarios, including a switch of light source position. These are fast enough that it is no problem on the CPU. And the values are encoded directly into gl_LightSource[0]. It has the additional advantage of only having a single code path, no code will be duplicated, aiding in debugging and future-proofing if changes are made. From my long experience with the default renderer, the setting of all lighting via FGLight::update() never seemed to be a problem, even on much, much slower computers. Hence why I wonder about performing some of the ALS lighting calculations there and modifying the GL light source directly (as the default renderer does).

Do you mean the gradient lines in the sky that move and tick like clockwork?


Yeah, those as well. They'd smoothly morph with a smooth position update.


Hmmm, maybe this one should be looked into.

I also intend to shift the following repetitive shader operation onto the CPU side:


It pre-supposes we want in fact the same moonlight color in all rendering frameworks. Which we do not, because the perception model used by ALS is different from what Rembrandt and default use. Nights in default and Rembrandt are much brighter, so to make moonlight illuminate anything you will have to set values which are wildly too bright in ALS.

In any case, a multiplication costs so little we can add a few hundred more before you can measure the effect. Not what makes a graphics card sweat.


I'm aware of these differences, hence why I mentioned making FGLight::update() ALS-aware. I can set up constant value lighting vectors specific for each framework. This is more a code and design consolidation in one centralised location, where there will be no GPU or CPU limitation. This will simplify an implementation of full scene directional lighting of sunlight, moonlight, and no light, and the transitions in between these.

In any case, the inconsistencies between all the shaders means that this will take a long time to properly integrate.


There is no inconsistency between the shaders - a ton of work has gone into making them all one consistent framework. There's usually a lot of thinking and experiments involved in how light is treated in the different shaders to make it that consistent.


Maybe inconsistency was the wrong word. The way the shaders treat the lighting to obtain the consistent result is not always the same. It's not the same block of code using gl_LightSource[0] in all shaders. Hence if I hook up the moonlight to gl_LightSource[0], I will have to go through each shader one-by-one and modify and adjust as needed.

If you want to entertain yourself, work out what the color of a fog pixel in general should be - given that the fog you see is not at the position of the object fogged but somewhere in between, and given that the light might be low and might illuminate the fog differently from the object being fogged and given that upper fog layers shadow lower fog layers :-)


It's complicated, that's for sure :) I'll at some point try to work out the differences between the default renderer and ALS. Along these lines, is sunlight reflected from the ground taken into account in the fog backscatter lighting?

I don't know how much of this you want to do yourself, but I can simply write the lighting functions for one shader and you can generalize this if you're after the learning experience. For me, it's probably the work of an afternoon or two to do all once I have the moon position as a uniform vec3, but you don't need to work out all the intricacies of ALS yourself (you still can if you like...) since I know them already.


I'd like to give it a go and see what happens. It might be more productive, in the long run, just to point me in a direction so you end up with something you'd find useful. I'm currently looking at graphically mapping out the illumination transitions vs. sun zenith angle that occur in both the default and ALS pipelines. This is starting with the basics - diffuse, ambient, specular - but I'll generate graphs of all lighting effects to allow integration with everything. This will help with integrating the moonlight and planning and testing a seemless transition of the light source position between the sun and the moon. I already have some "interesting" observations. Anyway, I currently prefer to avoid introducing a 3rd light source as I have a feeling that the FPS cost will be far too high, seeing how the lighting is handled in all of the shaders.

Regards,
Edward
bugman
Moderator
 
Posts: 1525
Joined: Thu Mar 19, 2015 9:01 am
Version: next

Re: Implementing moonlight (or not)

Postby Thorsten » Mon Jan 11, 2016 6:14 pm

For the renderer, gl_LightSource[n].xxx is just a particular collection of uniforms. The performance footprint on the GPU is no different from using 'normal' uniforms. The only difference is that the 'standard' uniforms exist in any case - which is why you'll frequently find stuff encoded in them which isn't really what the name says (for trees and clouds, nominal color channels actually encode position)

Hence why I wonder about performing some of the ALS lighting calculations there and modifying the GL light source directly (as the default renderer does).


The problem is that gl_LightSource is a uniform, which means it's constant per draw, which means it's useless for something that's different pixel by pixel.

It seems you're still struggling with the concept that the light is not the same color at every position in the scene - so you need to compute it for every position.

(this holds to a lesser degree for moonlight, so we can probably cut some corners - even so, terrain below a cloud layer won't be illuminated by moonlight as much as the cloud tops or mountains reaching above the clouds).

Edit: Also, don't assume that doing it on the CPU is necessarily faster. The GPU works massively parallel and has hardware support for many vector operations which are much faster than the software emulated functions the CPU runs- which means it rules for what you typically do for rendering, You really need to learn to think differently about optimization (was a long learning curve for me....)
Thorsten
 
Posts: 9921
Joined: Mon Nov 02, 2009 8:33 am

Re: Implementing moonlight (or not)

Postby bugman » Mon Jan 11, 2016 6:36 pm

Thorsten wrote in Mon Jan 11, 2016 6:14 pm:It seems you're still struggling with the concept that the light is not the same color at every position in the scene - so you need to compute it for every position.


Or maybe I'm just thinking in a different way ;) I'm first considering the global illumination model. For the moonlight, I've so far used the scientific literature. How the global model effects each rendering pipeline and each pixel is a downstream question that I will get to. Anyway, here are the lighting models for ambient, diffuse, specular, and sky lighting tables, as used as initial input into the default renderer:

Image

Yes, these are the values actually used, taken directly from $FG_ROOT/Lighting/*.

Regards,
Edward
bugman
Moderator
 
Posts: 1525
Joined: Thu Mar 19, 2015 9:01 am
Version: next

Re: Implementing moonlight (or not)

Postby Thorsten » Tue Jan 12, 2016 7:05 am

Or maybe I'm just thinking in a different way


It's math. Something can either be a time-dependent constant vec3 like (rgb)(t) or a vector-valued function of the full coordinate quadruplet (rgb) (x,y,z,t).

If you need the vector-valued function, you can't write it down as constant. I don't think there's so many ways you can think about this :-)
Thorsten
 
Posts: 9921
Joined: Mon Nov 02, 2009 8:33 am

Re: Implementing moonlight (or not)

Postby bugman » Tue Jan 12, 2016 10:00 am

What if you think of it as an illumination pipeline, whereby a series of filters are applied to an original set of vectors and constants? The original components could be a RGB colour vector for the sun, a RGB colour vector for the sky lighting of the scene, and a RGB colour vector for the moon (outside the atmosphere, and directly in front of the moon). Some ideas for filters are:

    A sun intensity scaling factor based on the sun zenith angle (apparent due to refraction, rather than real).
    A moon intensity scaling factor based on the moon zenith angle and moon phase.
    A moon step filter function which is set to 1 for moon zenith angles < 90 degrees, and 0 for angles > 90 degrees (moon visibility).
    A multi-colour filter based on sun zenith angle.
    A multi-colour filter based on the moon zenith angle (matching the sun, but likely unnecessary due to human eye effects in low light).
    A sun step filter function for the ambient lighting, set to 0 when the moon ambient lighting is greater than that of the sun, and 1 otherwise.
    A moon step filter function for the ambient lighting, set to 0 when the sun ambient lighting is greater than that of the moon, and 1 otherwise.
    A filter for sun reflections (specular or otherwise), based on the sun zenith angle.
    A filter for sky reflections (specular or otherwise), based on the sky colour.
    A filter for moon reflections (specular or otherwise), based on the moon zenith angle and phase.
    A filter for sun diffuse lighting (or equivalent directional lighting), based on the sun zenith angle.
    A filter for moon diffuse lighting (or equivalent directional lighting), based on the moon zenith angle and phase.
    A Rayleigh scattering colour filter based on the zenith angle, air mass, and fog/hazes.

The intensity scaling vs. zenith angle filters are based on atmospheric extinction and air mass. The current ALS moonlight shaders essentially perform some of these filtering steps - the constant colour vector hardcoded into the shader is "vec3 (0.095, 0.095, 0.15)" and the filter is the "moonlight" value ranging from 0 to 1. The fog effects on object lighting intensity and colour could also be considered a set of filters based on the sun or moon zenith angle (at least in the default renderer).

I intend on using such a pipeline of filters and step functions to fully and seamlessly integrate the moonlight into the FlightGear scene. From what I have seen of the default renderer and its lighting tables, this will work and most filters could be directly encoded into the OSG LightSource, as is already successfully done. A series of filters applied as a pipeline using simple multiplication and addition can be incredibly fast when well constructed, only requiring a few ms on a CPU. This is probably why I've never noticed problems with the default renderer and its per second CPU-based lighting updates. The filters can either be interpolated tables of numbers or mathematical functions. After that I'll see how much of this pipeline can be used in the ALS framework, or if subsets of the above filters must be hardcoded into each and every ALS shader.

Regards,
Edward
bugman
Moderator
 
Posts: 1525
Joined: Thu Mar 19, 2015 9:01 am
Version: next

Re: Implementing moonlight (or not)

Postby Thorsten » Tue Jan 12, 2016 12:50 pm

I'm not sure where you're driving at. Perhaps you're somehow thinking too much rendering models, and I am thinking too much physics of light. So let me describe a real situation to you, and you tell me how the filters apply to it?

Suppose I'm flying over the ocean at 36.000 ft with a thin scattered cloud cover at 25.000 ft. It's night and the moon is at an elevation of 45 degrees - right ahead. I see its reflection in the water as well as how it illuminates the clouds.

Now, in reality the light of the reflection passed through 10 km of dense atmosphere once under 45 deg to reach the water and then again under 45 deg to reach my eye, so it has a grand total of 28 km through the lower atmosphere. It'll almost certainly show Rayleigh color shifts as a result, i.e. the reflection will appear yellowish, and I might see a very faint silvery haze over the ocean (it'll really be blue, but so faint that the eye doesn't perceive any color). At the same time, the light reaching the clouds has passed just a few thousand meters through thin atmosphere, i.e. it will have seen a factor 10 less scattering and appear undistorted white.

What kinds of filter functions do you propose to render this difference?
Thorsten
 
Posts: 9921
Joined: Mon Nov 02, 2009 8:33 am

Re: Implementing moonlight (or not)

Postby bugman » Tue Jan 12, 2016 3:00 pm

I'm thinking more of the local object surface illumination rather than the distant reflection of the water shaders. In any case, maybe the following could be pre-computed and used for all effects, including the water shader:

    - Atmospheric refraction filter to correct the light source from the real to apparent zenith position (might be useful for changing the disk diameter and intensity).
    - Sun visibility step function based on apparent zenith angle, or similar with a non-linear ramp as the sun disk is hidden.
    - Moon visibility step function based on apparent zenith angle, or similar with a non-linear ramp as the moon disk is hidden.
    - Moonlight phase-based illumination scaling filter (the moonlight illumination formula outside of the atmosphere).

This is probably a crazy idea, but maybe the pipeline could be forked into a local frame and sea-level based light source (with the information stored in a new OSG LightSource which has no position and is turned off, simply for shader access). For the two pipes, the following could be applied:

    - Sunlight and moonlight zenith-based illumination scaling factor (based on one of the air mass interpolative formula, as used in the moonlight modelling paper referenced earlier).
    - Sunlight and moonlight zenith-based color filter (lamba^-4 wavelength scaling due to Rayleigh scattering light losses).

Elevation-based corrections would be part of these filters, to decrease the air mass. Then maybe Rayleigh and Mie scattering and fog effects could be applied to modulate the light path from the local object to the local aircraft frame. I still need to understand how this is done in the default and ALS frameworks.

For the colour changes to the reflection from the water shader, for non-calm water there is no single angle of reflection. Rather this should be a range of angles, each with a different pathlength from the sun->water->eye (the differences maximised at sunrise and sunset as the pathlength for the bottom and top of the sun disk are different). Therefore the colour of the reflection should be different for different parts - so I guess you would do this per-pixel in the shader rather than in any shared light source processing pipeline. Anyway, I still have a lot to look up and understand before I even start to integrate the moonlight as a directional light source into the FG scene.

Regards,
Edward
bugman
Moderator
 
Posts: 1525
Joined: Thu Mar 19, 2015 9:01 am
Version: next

Re: Implementing moonlight (or not)

Postby Thorsten » Tue Jan 12, 2016 6:12 pm

I'm thinking more of the local object surface illumination rather than the distant reflection of the water shaders.


Seems like, but the fact of the matter is that most of what you see from 36.000 ft is anything but a local surface :-)

- Atmospheric refraction filter to correct the light source from the real to apparent zenith position (might be useful for changing the disk diameter and intensity).


Yep, prime example of what should be done outside the shader.

- Sun visibility step function based on apparent zenith angle, or similar with a non-linear ramp as the sun disk is hidden.


I thought I put that into the sun code to hide the disc when it's below horizon.

(with the information stored in a new OSG LightSource which has no position and is turned off, simply for shader access).


Aka dump it into properties and pass it as a uniform collection :-)

Elevation-based corrections would be part of these filters, to decrease the air mass.


That gives you a function filter (terrain elevation, zenith angle) = filter (z,t). That's a 2d texture that's needed to pass this to the shaders. You can do quite some math for the price of looking up such a texture runtime. But it's not accurate enough in low light, because points in the direction of the sun get more light than points away from the sun due to Earth's curvature - something you do see well from 36.000 ft. So you'd need at least a 3d texture. Per filter you want to use.

We don't have that many texture units left in the effects.
Thorsten
 
Posts: 9921
Joined: Mon Nov 02, 2009 8:33 am

Re: Implementing moonlight (or not)

Postby Hooray » Tue Jan 12, 2016 6:36 pm

I'll see how much of this pipeline can be used in the ALS framework, or if subsets of the above filters must be hardcoded into each and every ALS shader.

FWIW, I do like bugman's whole "pipeline" thinking/approach because it would nicely map to the original idea of coming up with a framework for modeling/supporting different celestial bodies at some point, but I think it would be over-engineering to actually make the whole thing work with the existing shebang of effects/shaders and all the different rendering frameworks we have (aka, standard, ALS and Rembrandt).

Otherwise, I do agree with Thorsten in that it is unlikely that moving multiplications like vec3 moonLightColor = vec3 (0.095, 0.095, 0.15) * moonlight;
out of the GLSL code into C++ code is going to be noticeable - even if it only changes once every 60 frames.

That is exactly what GPUs are good at, and most GLSL compilers will be using the LLVM back-end anyway, which has rock-solid support for optimizing away redundant code (if it is even redundant to begin with) - i.e. the compiler may even recognize repetitive instructions and use constant folding (depending on how the kernel is structured) - if in doubt, you could use an #define (or move the calculation out out of the function) to see if just shuffling around the instruction makes much of a difference (I doubt it) - moving things to C++ space should however be pretty straightforward, and if you don't want to use a propertyObject<> you could probably even use a property rule.


(Also, keep in mind that Zakalawe, Mathias and Tim have been wanting to come up with separate renderers exactly because of these challenges)
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11165
Joined: Tue Mar 25, 2008 8:40 am

Re: Implementing moonlight (or not)

Postby bugman » Fri May 20, 2016 2:28 pm

Just a quick update, I have sent another message to the mailing list to have the directional moonlight branches looked at so the initial work can be merged.

Regards,
Edward
bugman
Moderator
 
Posts: 1525
Joined: Thu Mar 19, 2015 9:01 am
Version: next

Re: Implementing moonlight (or not)

Postby Hooray » Sat May 21, 2016 12:18 pm

Referring to the C++ changes you asked about, once they're merged, it may make sense to revisit the idea of using a PropertyObject<> instead of tied properties for all the reasons we previously discussed, if in doubt, get in touch with James to discuss that specifically.

Besides, from a code organization standpoint, it would actually be "cool" to be eventually able to re-use these FGLight objects elsewhere.

Note that the whole tie() approach is kinda problematic and meanwhile obsolete, and that even SGSubsystem and SGPropertyChangeListener have a higher level wrapper available, in the form of the PropertyBasedMgr: http://api-docs.freeflightsim.org/simge ... edMgr.html

The PropertyBasedMgr could be used to implement a property-based subsystem for creating and maintaining arbitrary "celestial bodies", while providing a built-in property tree API for easily adding new bodies, and light sources, i.e. to help generalize and unify the sun/moon vector handling code by reusing a single method that will update the x/y/z properties.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11165
Joined: Tue Mar 25, 2008 8:40 am

Re: Implementing moonlight (or not)

Postby bugman » Tue Nov 08, 2016 11:44 am

Just a quick update, the automated moonlight and moon position code has been pushed and will be a part of the 2016.4.1 release.

Regards,
Edward
bugman
Moderator
 
Posts: 1525
Joined: Thu Mar 19, 2015 9:01 am
Version: next

Re: Implementing moonlight (or not)

Postby wkitty42 » Tue Nov 08, 2016 11:52 am

i saw that just a little bit ago... new binary built and looking forward to testing... east coast USA is currently seeing roughly 1/2 lit moon in evening... anxious to see how the scenery looks at that time... this is a rough time to be outside doing visual satellite spotting with the moon being bright :)
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 4739
Joined: Fri Feb 20, 2015 3:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 14.04.5

PreviousNext

Return to Effects and shaders

Who is online

Users browsing this forum: abassign and 2 guests