moardv / distantobject Goto Github PK

Not visible in stock, but small bodies can cause the scale of the body flare to explode (due to negative scaling). Adding a clamp on the body flare's brightness value should fix the problem.

It looks like the flares are positioned relative to the camera, not the vessel. Look at that code and see what's going on.

It looks like my attempt to fix the app launcher bar still has a problem - a second icon appears underneath one of the stock icons. Looks like that code needs more work.

As reported in the forum thread, I also experience a strange visual artifact with DOE 1.5.2 while zooming out. I'm using ATM Basic and -force-opengl under Windows running KSP 0.90 32bit.

The artifact looks like a white oval/disc quickly emerging from the vessel symbol, running towards the observer to disappear. The whole thing takes < 0.5s, but it's very annoying since it happens on every scroll wheel action.

The artifact looks like the image below:

Can DoE show the names of bodies that are rendered, not just body flares? Probably, but it'd need to be something close to the middle of the body, not just anywhere the mouse intercepts it.

For the flyover text, at least.

ScaledSpace == map view. When in map view, we should be able to draw the flare right on top of the planet position.

Per forum user darthrion, parts using MODEL nodes do not show up in the vessel renderer impostor. I've never used that feature, nor have I looked closely at the code, so I don't know off-hand what will be involved in fixing it.

It looks like vessel flares (maybe planets, too?) are showing up in the wrong spot.

Some of the check box-style buttons change captions when pressed, and it's unclear what's going on. This need to be refactored to follow basic usability rules.

And refactor that OnGUI callback - new Rect and new GUIStyle per draw is not great.

Most obvious orbiting Kerbin - the flare for Minmus is visible alongside the scaled space model. xEvilReeperx provided a code snippet that will help me fix that.

With the KSP1.0 update, I seem to have introduced ghost flares - flares that show up for no good reason. It almost looks like they're duplicates of planetary flares (?), but closer to the camera. Need to investigate what's going on.

Well, actually, it says "obsolete". This only matters because of VesselDraw. I guess I need to figure out if I want to keep using baling wire and duct tape on that code, or punt it.

Well, not broken, but I didn't look closely at the RGB->HSL conversion algorithm, and it incorrectly drives all grayscale colors to (0,0,0), instead of (0,0,L).

On a 720p screen size, it falls of the bottom of the screen. See if I can find a way to do a tabbed interface or something like that.

It's particularly noticeable with Jool and its moons right at the start of the game with saturation turned up to max. Jool appears to flicker due to the flares stomping on one another. Maybe I can find a way to adjust relative Z positions for body flares.

They've been too dull for a while - something I did in 1.6.x?

A few changes needed...

Master list of bugs in DistantObject with KSP 1.0:

1. Name mouseover doesn't work.
2. Multiple instances of the toolbar object.

I can generate a simple quad mesh. There's no reason to include a model.

Utils.cs : 141
if (skyboxBrightness.HasValue("debrisBrightness"))
{
SkyboxBrightness.maxBrightness = float.Parse(skyboxBrightness.GetValue("maxBrightness"));
}

should be

if (skyboxBrightness.HasValue("maxBrightness"))

Hi,

with KSP v1.0.4 using OpenGL and DOE v1.6.1, I get the strange ghost flares again, this time hovering the vessel after a standard parachute landing, as seen in the screenshots below. This happened two times in a row now, I think it's reproducable. Strange enough, I had flares deactivated in the DOE settings the whole time.

Thanks for your efforts!

It seems like only some flares show labels. Need to understand that code and figure out why.

Sarbian mentions here: http://forum.kerbalspaceprogram.com/index.php?/topic/111978-part-105-anatid-robotics-mumech-mechjeb-autopilot-v255-dec-3rd/&do=findComment&comment=2361328

a couple of things that could help - smooth.foundations and Unity toolbag. I may want to look into those one of these days when I have time to spend on code tinkering

I see Jool on the face of the Sun, when it's actually around the back side (ca. Year 1 Day 84).

Currently the only ways to add configs for the planetary bodies are:

• Remove the config shipped with DOE and replace it with a selected one.
• Create a new config with the same structure and place it somewhere under the GameData folder.

The second option works fine but since it adds new flare definitions "on top" of the DOE (and custom) ones it is possible that duplicates may occur. I do not know if it is good or bad (probably bad) to have duplicate flare definitions for a single body but i can assume that the one that loads last will have the priority over the others.

To conclude, i am asking if for the next version(s) a new config loading system could be implemented. Since it will be modified once there will be no problems with MM rebuilding it's database on each KSP launch.

Per this post from Gordon Dry, there are problems with sky dimming in 1.4.x.

• DOE alone: must disable Dynamic Sky Dimming to see the stars from the surface at night.
• DOE + scatterer: Can not see the sky.

PlanetShine is also installed, so it could be a factor.

To cut computations costs, we'll do the visibility test against only the body the current vessel orbits.

The original DOE process for sizing a vessel flare created a "luminosity" value that was a proxy for vessel size/brilliance. This luminosity value was the sum of the squares of the individual parts' mass, and it was used later as input to a Log10 equation that ultimately resized the vessel's flare.

One problem that arose with this method is that small craft could have a luminosity < 1, which would lead to the size being negative (and, furthermore, a large negative value). I initially added a clamp to keep the luminosity at 1, but that still leads to a resize to 0 (effectively invisible).

Clamping LUM at 10 instead leads to a base resize of 1, and it allowed me to see a small satellite at long distance. While not strictly realistic, it does make the night sky more interesting.

It's not clear yet that I can get the ship dimensions that are used for restricting VAB and launch pad usage, but maybe I should look at other methods to compute the luminosity proxy.

Parsing the situations string results in:

[WRN 19:57:45.178] Distant Object Enhancement v1.6.3 -- Unable to find situation 'ORBITING' in my known situations atlas
[WRN 19:57:45.179] Distant Object Enhancement v1.6.3 -- Unable to find situation 'SUB_ORBITAL' in my known situations atlas
[WRN 19:57:45.180] Distant Object Enhancement v1.6.3 -- Unable to find situation 'ESCAPING' in my known situations atlas
[WRN 19:57:45.180] Distant Object Enhancement v1.6.3 -- Unable to find situation 'DOCKED' in my known situations atlas

A recompile hopefully will solve it, although I think it's time to remove that from the configs, anyway.

Several issues that could be improved or outright redone:

a) scaledTransforms is searched every update for every world. These transforms should simply be cached away by their respective BodyFlare objects.

b) Might be able to do away with the planet color configs by importing the values from OrbitDriver (by way of Planetarium.fetch.orbits). Provided add-on orbits set these colors, that is. A couple of alternatives - look at atmosphere color, and look at seeing if there's a way to get a value from the planet renderer in ScaledSpace?

c) Don't apply dimFactor to alpha - instead, pre-multiply the color (and cache the color in the BodyFlare / use white for the VesselFlare), so only atmosphere affects alpha.

d) Figure out what can be moved to FixedUpdate, instead of leaving it in Update.

And make Blizzy's Toolbar optional. Look at how KAC does it to get an idea of the path to implement.

Apparently, per http://forum.kerbalspaceprogram.com/index.php?/topic/89214-130-distant-object-enhancement-bis-v191-8-july-2017/&do=findComment&comment=3127452 , Kopernicus overrides skybox dimming. Maybe DOE should finally take over that functionality, so dimming control is consistent.

Blue Dot from Sigma Binary / Distant Object Enhancement conflict.

Spawns from craft, single-sided texture invisible when viewed from any other direction. Not collidable, static once spawned.

The issue only presents itself when there is a binary system loaded and Distant Object Enhancement is installed.

Already posted this to the Sigma Binary Github issue tracker as well

KSP 1.7.3
Kopernicus - 1.7.3.2
ModularFlightIntegrator - 1.2.6.0
Sigma Binary - 1.7.2
Distant Object Enhancement - 1.9.1.1
SigmaDunaIke

KSP.log