Orbital Rendering light blue space instead of dark

[wlbragg]

I've tried the Orbital Rendering a few times and never was able to get the beautiful, sharp pictures that you see in the news letter. Then I finally figured it out, I was too low. I have to get up above 200,000 ft or so before you get any kind of definition.

My problem is at 300,000 ft the black space around the globe starts to shrink towards the globe until you have only an inch or so of black space around the globe and the rest of space is light blue. I can show you a picture if you need to see what I'm talking about. What am I doing wrong? Do I have some settings wrong?

[zlsa]

Exact same issue here. I'll upload screenshots soon.

[wlbragg]

Just in case this is an issue and not user error my specs are

Win7-Home Prem/64
nVidia GeForce GT640
FG3.2rc

[wlbragg]

Here's what it's doing in sequence as you gain altitude.

[Philosopher]

See? the earth isn't round, that's just a fake picture laid on top of the sky...

SCNR

[Thorsten]

Just looking into the Earthview thread would have given you the explanation and the patch you need to apply.

At 100 km altitude you're exiting the skydome, so you don't see black above, you see the color FG chooses as default background, which is fog-grey, because ages ago FG used to unload the skydome in poor visibility - so then you'd want to see a foggy background. We don't have to do this any more because it'd screw up ALS in poor visibility, so there's no particular reason the BG color couldn't be set to black these days, and I've been nagging core devs three or four times so far to make the change, but no success.

[wlbragg]

Just looking into the Earthview thread would have given you the explanation and the patch you need to apply.

I did, I just didn't think to start at the beginning.

For anyone else that looks at this thread, don't go to the end of the Earthview thread and work backwards to find the information about this patch like I did. You'll end up combing through about 8 pages of work product and a few of trash talk.

Why we are including great features but not fixing the little things that are wrong with them is beyond my comprehension!

Thank you Thorsten for pointing out the patches that need applied to make Orbital Rendering work correctly. After reading the pertinent info in the thread I can't believe any of those issues still persist. I had completely forgot about them it was so long ago that I look at the subject and such progress has been achieved since then. I would have thought those patches would have long been applied.

[TheTom]

Just looking into the Earthview thread would have given you the explanation and the patch you need to apply.

I've just pushed the patch for a black clear color. Are there more patches missing?

[Thorsten]

Thanks.The atmosphere definition patch is done - TorstenD committed that a while ago.

There's a bunch of potential patches to the Vostok, but that's all FGData. The rocket is probably unmaintained at the moment, but since aircraft will go to SVN anyway, I think there's no need to do anything now.

[Hooray]

thanks for pushing this - note that not everybody seems happy with the patch: https://gitorious.org/fg/flightgear/com ... 1a12d05dfb
Like I said previously, I'd suggest to make those colors properties - that can be affected at run-time or at the very least while initializing

[Johan G]

...I'd suggest to make those colors properties - that can be affected at run-time or at the very least while initializing

That is probably a very good idea.

[wlbragg]

Yes, it seems there was more than meets the eyes here.

Expose the color properties. Orbital rendering should control the color change when activated. This seems to be the correct fix to make all happy. Almost sorry I brought this up. But there is no "good" reason why we can't have it all in this case.

Edit:

Simplest fix is to check for orbital-rendering being enabled (and even viewer altitude very close to the skydome 'top), and then override ClearColor with black (with alpha 1).

Same difference, yes?

[Thorsten]

To the best of my knowledge and ability to test, since at least a release cycle, possibly two, we do no longer unload the skydome in any visibility, because doing so screws ALS over unconditionally which needs the skydome to paint on.

The original objection against the patch that you get to see black fog in bad visibility is then no longer valid - you never ever see clear color in FG unless you customize it.

The original justification for unloading the skydome, i.e. saving performance, is obsolete since possibly a decade - compared to a typical scene in modern FG, the skydome takes so little performance to render in default that you can't possibly measure it.

So at some point, asking to make a color customizable which a normal user can't ever see and which is there because of a feature which became obsolete 10 years ago seems a bit too much for my taste. We should /not/ unload the skydome under any circumstances, and as of now we actually do not. So maybe we just go with the obvious solution?

[Hooray]

Personally, I don't care at all - I was just trying to come up with a solution for something that is obviously a controversial change for a few people.
Obviously, this change is not as simple if that code can possibly be accessed from multiple threads, because it would require synchronization then - but otherwise, it's really just 5-10 lines of SGPropertyNode->getNode("/foo").getValue() - i.e. the equivalent of getprop() in C++
But I am not familiar with the code, so I've passed on the question to the person objecting ...

[wlbragg]

Change works great as far as I am concerned, thank you to all involved.