I understand. Another local light question which I brought up earlier: is there any way to get rid of the fogginess of local lights using the metalness shader? I've attached a photo from STS-133 with a comparison screenshot taken from a similar position and angle. As you can probably tell, the lights in D3D9Client has a very foggy look to them, while the ones in the real photo are clear.
Do you mean the camera at the end of the robotic arm ? That's a result from the "Light Glow" post processing. The purpose is to make the light look brighter but in that particular case it doesn't work too well, so, some shader calibrations are required. What would happen if the light attenuation parameter att0 is set somewhere between 0.25 and 1.0 that should make the light less bright from a such a close range.
Well, that and the PLB flood lights. If you look closely, you can see the detail of the PLB vent filter screens and the PLB itself is almost washed out. I think the attached screenshot shows it pretty well.
I think the washed-out effect is from the light beams simply adding together where they are overlapping. This addition doesn't seem to be gamma-correct (I think it's gamma, correct me if I'm wrong). To our eyes, two overlapping lights of the same brightness don't look twice as bright, but more like 1.5 times as bright. Something like that.
No such luck as shown by the attached screenshot where only one light is active.
Are the vent filter screens supposed to be black under normal lighting?
You mean the grey rectangles that are on each side of the bay? Then no, normal color is silver grey. You can see them in this panorama from inside the PLB of Endeavour: http://nasatech.net/TREndeavour/TREndeavourCargoFrwd120406/
If you play around with the material setup does it remain unlit ?
Yes. Just to clear up any confusion, both the airlock (illuminated bottom part) and the ODS (unilluminated part) itself are using the exact same settings and shader (Metalness).
), so an additional API would be needed.
clbkCreateReentryStream(...) callback (the logic when it is called is handled by Orbiter core)clbkCreateBowshockStream(...), but that is something the core has to provide,clbkCreateParticleStream(...) etc. would be the preferred way for now.
enum GeneralShape {
CYLINDRICAL, ///< like "regular" rockets (e.g. Saturn V)
SPHERICAL, ///< like e.g. Soyuz
WEDGE, ///< like the e.g. the DeltaGlider or the Space Shuttle Orbiter
CUBOID ///< like a brick ;)
};
/// Interpolation between start and end:
enum Timing { LINEAR, LOGARITHMIC, SQUARE, CUBICAL };
struct ShockParam {
GeneralShape shape; ///< mainly for "cross section" in direction of travel
VECTOR3 offset; ///< offset from Vessels CoG (default to {0,0,0})
double dynPressureStart; ///< dynamic pressure [Pa] when effect should start
double dynPressureEnd; ///< dynamic pressure [Pa] when effect should stop (bigger than 'start')
Timing progress; ///< "Timing" is not the right word here, but...
short osc; ///< oscillating frequency [Hz] for pulsing effect (default: 0 a.k.a "off")
//...
};
// To be called once at initialization
HANDLE CreateDynamicPressureEffect(ShockParam p);
// Called every Nth timestep
void RenderDynamicPressureEffect(const OBJHANDLE hVessel, const HANDLE &sph);
// ...
// which does something like:
// if ( !isInAtmosphere(vessel) || standsStill || ... ) return; // quickly deduce if we can return as soon as possible
//
// if (vessel->GetDynPressure() BETWEEN (dynPressureStart, dynPressureEnd) )
// {
// InterOrExtrapolate(progress) => call whatever is needed to render nicely ;)
// }Yes, I noticed that too. Will look into it.
