Astrodynamically Correct Shadows at Altitudes Much Greater than Z=0

geolocation
georeference

#1

Hi, I’ve been experimenting with satellite renderings in low earth orbit where the eclipse period changes with altitude. Using the API, we can control the latitude, longitude and time to accurately position the satellite along a realistic ground track, but the sunset and sunrise appear to be calculated based upon a datum of Z=0. I’ve toyed with several altitude and datum tricks to position the model at the correct altitude in SU, but the shadows are still rendered as though my model is on the earth’s surface. Any ideas how to override this from the API? Essentially, we need shorter eclipse periods as the altitude increases.


Shadow Analysis possible with this free software?
#2

Since all the sun calculations are done inside the compiled app, I doubt this is possible. We don’t even know for sure what method they use!


#3

This is setting a Geo location of “Confusion Corners” in Stuart, Florida:

This setting a Geolocation of Pikes Peak, Colorado:

Looks like the values are in inches. Divide by 12 and the “corners” come out about 11 ft, and the peak ~ 14,095’. Does that sound correct ?

So after picking your spot try to change the Z:
Sketchup.active_model.set_attribute("GeoReference","ModelTranslationZ",value)

It’s worth a shot…


Geolocation has wrong elevation
Find the Z value (elevation) of an object already drawn
Set and measure elevation above sea
#4

@tt_su or @bugra Can someone confirm whether altitude is used or not ?


#5

Well I tried this. Changing the Z attributes in the model’s “GeoReference” attribute dictionary appears to have no effect.


#6

Presuming you geo-located via Add Location, which interoperates with Google Earth…
My guess is the ModelTranslationZ value controls where (in Z) the model will appear when placed in Google Earth.

I also notice the GeoReferenceNorthAngle varies between the “Confusion Corners” and Pikes Peak.
Why GE terrain doesn’t come into SU with its true north perfectly aligned with Y still baffles me.


#7

Yes I did. I believe the same. What I was hoping was that SketchUp would pick up on the change in the Z value.


#8

[quote=“DanRathbun, post:7, topic:11760”]…
What I was hoping was that SketchUp would pick up on the change in the Z value.
[/quote]
Didn’t you prove that already with the two locations and different Z values as a result?


#9

No. That was just showing the OP that the Z value did come in from Google Earth. I choose two locations I know of and have been to,… a location near sea level, and one at high altitude. (As a youngster, I worked for the Cable TV company and drove through that Stuart intersection a zillion times. As a baby only days old my parents brought me up top of Pikes Peak. We have the picture. I turned blue! They skedaddled back down right quick.)

Anyway, to prove anything, I’d have to watch the ShadowInfo["SunDirection"] vector for a change.

But as Geo notes, the angle change is not likely to be much. The sun is like 93 million miles away or something ? And the change in altitude is only under 3 miles.

The difference for the OP, comes in when the sunrise strikes the model object. This occurs sooner for high altitude objects. In other words the sun hits the mountain top some minutes before it hits the valley floor at the base of the mountain. The opposite for sundown.