Anybody considering to work on this, may want to check out
http://wiki.flightgear.org/The_FlightGe ... g_Pipeline
While it's not much more than a stub currently, we could certainly extend the whole thing accordingly
class FGLightSourceUpdateCallback : public osg::NodeCallback {
public:
/**
* @param isSun true if the light is the actual sun i.e., for
* illuminating the moon.
*/
FGLightSourceUpdateCallback(bool isSun = false) : _isSun(isSun) {}
FGLightSourceUpdateCallback(const FGLightSourceUpdateCallback& nc,
const CopyOp& op)
: NodeCallback(nc, op), _isSun(nc._isSun)
{}
META_Object(flightgear,FGLightSourceUpdateCallback);
virtual void operator()(osg::Node* node, osg::NodeVisitor* nv)
{
assert(dynamic_cast<osg::LightSource*>(node));
osg::LightSource* lightSource = static_cast<osg::LightSource*>(node);
osg::Light* light = lightSource->getLight();
FGLight *l = static_cast<FGLight*>(globals->get_subsystem("lighting"));
if (!l) {
// lighting is down during re-init
return;
}
if (_isSun) {
light->setAmbient(Vec4(0.0f, 0.0f, 0.0f, 0.0f));
light->setDiffuse(Vec4(1.0f, 1.0f, 1.0f, 1.0f));
light->setSpecular(Vec4(0.0f, 0.0f, 0.0f, 0.0f));
} else {
light->setAmbient(toOsg(l->scene_ambient()));
light->setDiffuse(toOsg(l->scene_diffuse()));
light->setSpecular(toOsg(l->scene_specular()));
}
osg::Vec4f position(l->sun_vec()[0], l->sun_vec()[1], l->sun_vec()[2], 0);
light->setPosition(position);
traverse(node, nv);
}
private:
const bool _isSun;
};
Including its two seemingly permanently on light sources, both positioned at the location of the sun!
Thorsten wrote in Wed Dec 16, 2015 6:26 pm:I actually suspect we can just pass the exposed coordinates as uniforms and do the rest in the shader. Dependent on what local aircraft frame is... I hope it's not body coordinates but z up, x north and y east (or the last two swapped...).
Do you want to try this, or really install it as a light source?
Including its two seemingly permanently on light sources, both positioned at the location of the sun!
My wild guess is that one is the colored sunlight illuminating terrain and the other the white sunlight illuminating the moon.
I'm now looking at replacing all instances of "/environment/moonlight" with "/ephemeris/moon/phase" in the FGData effect
Turning one or the other off has devastating results on the FG scene.
you will almost certainly want to refrain from using tied properties
The current solution seems to me to be a little 'hacky', in that it only works in the ALS framework and that every last object in the FG scene needs to have an effect added to be illuminated by moonlight.
Thorsten wrote in Thu Dec 17, 2015 10:31 am:The current solution seems to me to be a little 'hacky', in that it only works in the ALS framework and that every last object in the FG scene needs to have an effect added to be illuminated by moonlight.
Won't work - moonlight will only illuminate anything if you explicitly instruct the shader to do so. Regardless of what you do on the C++ side, default won't use it until you add it to every shader.
The shaders really are the last word in rendering - all you set up before is just a potential set of things the shaders can use, but each shader decides what of it it does use.
Thorsten wrote in Thu Dec 17, 2015 10:31 am:I know, hard to accept for a C++ programmer
You should give it a go - if you can handle Nasal and GLSL, modifying existing C++ code will not be too hard. That'll give you a lot more power to set up awesome effects!
MIG29pilot wrote in Thu Dec 17, 2015 2:24 pm:I missed something--are we implementing the moon so that the computer thinks of it like the sun?
You should give it a go - if you can handle Nasal and GLSL, modifying existing C++ code will not be too hard. That'll give you a lot more power to set up awesome effects!
Tim Moore wrote:it would be nice
one day to have better comments in the code, but this code has accreted over
many years, starting long before my involvement with FG. At a very high
level, when a model is loaded, its OSG subgraph is copied, except for its
textures and geometry. This is not-optimal, but it allows animation of all
models without a complicated optimizer.
In the monster function sgLoad3DModel_internal, effects mentioned in the
.xml file are gathered, along with any created implicitly by animations. An
effect is associated with named objects in the model. The .XML file can also
specify a default effect for the whole file; by default that is
Effects/model-default.eff. The model itself is transformed by
instantiateEffects, which uses MakeEffectVisitor. For each named object in
the model, this MakeEffectVisitor sets the appropriate effect as a "parent"
effect, and then creates a new effect for any osg::StateSet found,
inheriting from the parent. osg::Geode objects are replaced with
simgear::EffectGeode objects that will apply the effect at runtime. There is
quite a bit of hair to share effects and avoid creating new ones where
possible.
The dependency on .ac exists at this level in MakeEffectVisitor. The visitor
expects to find osg::StateSet objects only in osg::Geode objects i.e., near
the leaves of the scene graph. It only works with the simple attributes
created by the .ac loader (see makeParametersFromStateSet): osg::Material
properties, smooth vs. flat shading, polygon culling, blending (for
transparency), and one texture binding. Any other attributes are ignored.
If you want to apply effects to other kinds of models, you would need to
generalize MakeEffectVisitor "in both directions." StateSet objects can
appear in any scene graph node and also in the Geometry nodes that sit below
osg::Geode. A more general effects visitor needs to track the graphics state
as it traverses the scene graph and also needs to examine the geometry.
Effects sit at the Geode level.
Alternatively you could ignore any state attributes in the model and specify
it all in the .xml file, but this would quickly get tiresome.
I recommend you use the osgconv program to dump out the .osg representation
of our .ac models and the models that interest you and get an idea of the
differences you are up against. For .ac you should use our Optimizer options
found in ModelRegistry.cxx; you can set them with the OSG_OPTIMIZER
environment variable.
I'll try to write more comments in the code over the next few weeks. In the
mean time, keep hitting me with questions. I don't have the bandwidth to
answer basic OSG questions
Users browsing this forum: No registered users and 1 guest