SDK Question Advice for Calculating if Vessel is in Sunlight

Mr Martian

Orbinaut/Addon dev/Donator
Addon Developer
Donator
Joined
Jun 6, 2012
Messages
279
Reaction score
62
Points
28
Location
Sydney, Australia, Earth, Sol
Website
www.orbithangar.com
Hi All,

Hopefully a quick question here:

I have a function which returns true if a vessel is currently in sunlight.... sort of... Essentially I am calculating if the local reference body is obscuring the sun, this is simple enough. However the issue arises if my vessel is say orbiting one of Jupiter's moons for example. Obviously the local reference body will be whichever moon I am orbiting, but the sun may still be obscured by Jupiter. I could iterate through each body in the solar system one-by-one, but I am really not keen to do this, especially since I will probably be calling this function each time step, and that starts to get pretty expensive.

Does anyone have any suggetsions how to go about this? If the only realistic way is to iterate though each body I think I'll just say the local reference body is good enough!

Thanks all!

MrMartian
 

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,156
Reaction score
1,892
Points
188
Website
github.com
Filter the objects so you have a list of what is near you. 1M Km is probably a good limit, as you shoudn't get much shadow from something at that distance. You probably would only need to update that list every day or 2... unless you have a warp drive and can move really fast.
You can them run the math to check to check for shadow only in those bodies near you. Not sure it would work, but knowing the size of the Sun and distance to it, you can find the angular size of it. Then for each body you would need to check if they are inside that cone from the vessel to the Sun. This quickly get complicated with partial obstructions... maybe start simple, and then improve. This part could also only run every 1 minute or so.
 

martins

Orbiter Founder
Orbiter Founder
Joined
Mar 31, 2008
Messages
2,430
Reaction score
417
Points
83
Website
orbit.medphys.ucl.ac.uk
Realistically, the only situation where this is an issue is the one you described: when orbiting a moon, the sun may be obscured by the parent planet. For sibling bodies (other moons of the same planet, or other planets when orbiting a planet), the distances will be too large and the apparent sizes too small to make this a relevant issue.
To find the parent celestial body, use the oapiGetGbodyParent function. If the returned body is not the Sun, it means that you are orbiting a moon, and the returned body is the parent planet. (If the returned body is the Sun, then you are orbiting a planet, and there is nothing more to check).

So at most you would have to check one additional body, rather than scanning all the solar system bodies.

The other thing to look out for is that it's not a binary obscured/not obscured decision. The Sun's disc has a finite aperture, so can be partially obscured (meaning that you are in the planet's or moon's penumbra). This becomes even trickier if the planet or moon has an atmosphere, which additionally affects the amount and spectral distribution of the light received.
 

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,156
Reaction score
1,892
Points
188
Website
github.com
I was thinking a bit more about this, and maybe this already exists in the Orbiter core, or more likely in the graphics engines, as this kind of information is needed to know how much to light the meshes. Maybe this could be exposed in the API by having a function that returned "actual solar radiation" for the calling vessel, so that everyone could have this info and thus implement their own solar panels, with different charecteristics that had their output go up and down as the vessel moves to and from the Sun, and down to 0 in the shadow of a body.
 

n72.75

Addon Developer
Addon Developer
Tutorial Publisher
Donator
Joined
Mar 21, 2008
Messages
2,350
Reaction score
918
Points
128
Location
Biddeford ME
Website
mwhume.space
Preferred Pronouns
he/him
This is how NASSP does it's calculation to check if the moon is in the way of a ground station:


You could do something similar with the a vector to the sun. If you draw a picture of that equation, it's checking if the vector to the sun is less than the solid angle subtended by the planet (or moon's) limb.

For the partially obscured case you can use a similar technique to get the aparent disc size and relative angle, and feed it into some general form of three arbitrary intersecting circles. This is almost certainly the hard part.
 

Gondos

Active member
Joined
Apr 18, 2022
Messages
135
Reaction score
137
Points
43
Location
On my chair
As said in your other thread, looks like the function vVessel::ModLighting (LPD3DLIGHT7 light) in OVP/D3D7Client/VVessel.cpp is doing just that.
Look at how lfrac is computed (there is also code for when the sunlight is interacting with an atmosphere).
If you fear it's too taxing to do the computation for several bodies, the code also does some tricks to update the value only at 10Hz (search for tCheckLight).
 

Linguofreak

Well-known member
Joined
May 10, 2008
Messages
4,634
Reaction score
764
Points
138
Location
Dallas, TX
Realistically, the only situation where this is an issue is the one you described: when orbiting a moon, the sun may be obscured by the parent planet. For sibling bodies (other moons of the same planet, or other planets when orbiting a planet), the distances will be too large and the apparent sizes too small to make this a relevant issue.

I'm not sure that this would always be the case WRT, e.g, the Galilean moons, especially the inner three. It might also fail for plausible extrasolar arrangements.

But one could filter objects based on angular size as observed from the vessel's location, compared to that of the Sun. You'd be iterating over every object, but only to determine if its angular size is great enough to potentially obscure a significant amount of sunlight, only if it was would you then check for actual obscuration.
 
Top