- Mar 28, 2008
- Reaction score
I played around a little bit with the LensFlare.hlsl file some time ago and ended up removing the diffraction spikes altogether and thought it looked really good IMO to the point where i just replaced the usual sun texture (Star.dds) with a blank transparent one (not really viable beyond the asteroid belt region tho as it pretty much disappears altogether at that distance unlike the standard sun texture).The lens flare should be re-implemented. Personally I don't really like it due to being too bright and large. Also, it's mathematically heavier that everything else we have all together. With the time used for that effect we could have SSAO running. Also, the sun and other light sources are usually visualized as sharper and spikier not as a smooth "flowers". I suppose we could use simple textures for flares and glares. and some math to control size and intensity. That's what most games do.
It is just too smooth, it looks more like a comet than a star. I have attached three photos of the sun taken during various ISS and shuttle missions.I played around a little bit with the LensFlare.hlsl file some time ago and ended up removing the diffraction spikes altogether and thought it looked really good IMO to the point where i just replaced the usual sun texture (Star.dds) with a blank transparent one (not really viable beyond the asteroid belt region tho as it pretty much disappears altogether at that distance unlike the standard sun texture).
View attachment 26091
One minor thing i'd like to point out tho for future reference is that the current lens flare implementation has this somewhat contrary effect on the stars as well as the celestial sphere background where they both seem to be considerably brighter when they're overlaid by any of the lens flare elements; but then again i'm completely ignorant on how this would actually behave in reality so it might just be a misconception on my behalf.
I'll give Orbiter Beta a thorough test with the update and make sure it doesnt break anything in NASSP.New "stable" Build for Orbiter 2016 is available
New build for Orbiter Beta is also available
I haven't done much testing with Orbiter Beta due to limited time, so, it might be good idea to run some tests with the Metalness shader to see if everything is working properly.
Due to nature of the problem I can't imagine how a driver update could make things worse. Does there exists a version of the client where the seams won't exists ? I tried revision 787 which is the oldest we got for Orbiter 2016 (September-2016) and it did have the seams. As far as I can remember the seems have been there.Terrain editing is very much welcome, but the current terrain seams bug is pretty nasty.
I know it's not your fault but it got worse today after updating Nvidia drivers.
I just tried the Alps 2016 scenario and the black seams become visible as soon as the terrain loads....
If I recall it should set the threshold where vessel self shadows appear. The math that controls the shadows may have changed and the comment is outdated.Quick Q: What does SHADOW_THRESHOLD in Common.hlsl do? Currently it is set to 0.1 but the comment suggests the lowest limit is 0.3 and the highest limit is 7.0.
Possible but problematic. We should have an official way to do something like that. Client side hack doesn't sound like a good idea. It's getting too messy. Lot of things are already too messy.I was wondering though, is it possible to set the elevation of an area, without having it rendered?
Replacing the libs, casting DLGPROC and refactoring the CPU context logging was all I had to do (besides adding an x64 target, of course). Very well crafted code-base!We probably should create a branch for Orbiter r.90 and repurpose the trunk for Orbiter x64. I tried to compile the client as x64 and the amount of errors was much less than I feared.