Got an Idea for a Celx Utility Script?

[don]

I'm looking for some new utility script ideas to challenge both myself and Celx/Lua. Maybe something that used to be done by hand, like calculations for Celestia data, or ???

Celestia's implementation of Lua (Celx) does not allow it to read or write files, and does not allow it to access system information (like window sizes, font sizes, etc.). Thus, keep these things in mind when requesting new utility scripts.

Please post your ideas here. Thank you!

[maxim]

No problem, here are some challenging:

Scripts that allow to run flyby/swingby manoeuvres by one function call with parameter settings...
- parabolic swingby
- hyperbolic swingby
- circle arc flyby
- inverse hyperbolic flyby
- inverse parabolic flyby
- asymptotic orbit entering

maxim

[Toti]

Here are some ideas:

1] Simple gravitational simulation: activate gravity for the (viewer-selected body) pair only if they are close enough. You can use a LUA dictionary to store body masses. If you are inside the atmosphere you can add drag to the calculation (you will need to define a shape for the "Ethereal Celestia Viewer", though)

2] A function that tests if the next goto() call will take the viewer through a body. This will be very useful to avoid unpleasant effects.

3] Rough Spline/Bezier support: a function that takes a list of points in space and builds a vectorial Bezier-polinomial trajectory (f(t), g(t), h(t)) with them, and a function that takes current time and the mentioned trajectory and returns an spatial position. Inside a loop, this latter function's return can be passed to a goto() to produce smooth, elegant movements.

4] A Tour Director mode: a table (inside a LUA dictionary, for example) :

Code: Select all

Body        Location         Time  TravelMethod  InfoText

Jupiter/Io  Loki Patera      12    GotoSpinning  "This is...(10 lines of text)"
Mars        Valles Marineris 18    Appear        "We are over... (25 lines of text)"
...         ...              ...   ...           ...
...         ...              ...   ...           ...


and a set of functions that take the viewer to Body-Location in Time seconds using TravelMethod and displays Text using your already available text-fomatting functions.

5] A function that calculates speed and acceleration (radial, tangential, angular, etc.) for certain body relative to another (example: Galileo-Sol)


Some are more difficult to implement than others. Some need a small bit of math background: the internet is a good source of information.

Bye

[don]

- parabolic swingby
- hyperbolic swingby
- circle arc flyby
- inverse hyperbolic flyby
- inverse parabolic flyby
- asymptotic orbit entering

Nice ideas, but I'm afraid these are over my head. I still don't understand how to compute the vectors required by the gotoloc parameter in Cel scripting, let alone doing fancy fly-bys. ... I'm just not there yet, but I'm sure other folks are.

[don]

Here are some ideas:

Wow, you guys definately have some great ideas.

However, my math skills are basically limited to simple algebra, and don't get into 3-D math or celestial mechanics. Hopefully, some other folks more adept at math will grab some of of these ideas and code them.

I think your idea #4 (Object info table) would best be done with read-a-file support, which is not currently available in Celx. It wouldn't be much fun to try and maintain a table full of data like this from within program source code.

Keep those ideas coming!

[Toti]

I think your idea #4 (Object info table) would best be done with read-a-file support, which is not currently available in Celx. It wouldn't be much fun to try and maintain a table full of data like this from within program source code.

This was an idea that I had in mind from some time ago (I even posted it on the forums). I was going to start coding a CSV reader function for it, when I came to this thread and got alerted about Celx LUA current limitation...your post save me a lot of work

However, my math skills are basically limited to simple algebra, and don't get into 3-D math or celestial mechanics. Hopefully, some other folks more adept at math will grab some of of these ideas and code them.

In principle, some of the above ideas shouldn't need complex math devices. For example, the speed calculation one only assumes some low level knowledge of vectors and basic operations like dot product (only a couple of equations). There's a lot of web tutorials on this.
For the Bezier support idea you should be familiar with a little more complicated tools, though.

Here is another idea. A simpler one:
6] You have already coded a very useful function that flashes a marker. How about one that starts drawing a big marker and makes it smaller (in 10 or 15 steps) and repeats the whole task for three times? It should result in another good way to draw the viewer's attention to certain point.

Bye

[don]

Hi Toti,

Glad I could save you some time (file I/O stuff). Hopefully, Celx will have *some* functionality in this realm in the future (fingers crossed).

However, my math skills are basically limited to simple algebra, and don't get into 3-D math or celestial mechanics. Hopefully, some other folks more adept at math will grab some of of these ideas and code them.

In principle, some of the above ideas shouldn't need complex math devices. For example, the speed calculation one only assumes some low level knowledge of vectors and basic operations like dot product (only a couple of equations).

At this point, I don't understand vectors, (as they are implemented in Celestia) or how to use them in scripts to orient the camera, move from point A to point B, etc. To understand these things, one must understand coordinate systems, which I still do not fully understand in Celestia either.

So, I'm a bit "behind the 8-ball" in these areas (scripted movement in any direction, rotations, etc.). Web pages have not helped with relating these specific topics to Celestia. I've even read several "Introduction to 3-D programming" tutorials <sigh>.

However, there is a new set of French-only web pages that describes Celestia's coordinate systems as relates to keyboard commands, but does not provide any scripting examples.

There's a lot of web tutorials on this.

Could you post links to a couple that you think could be understood by folks like me (no math degree), and also be fairly easy to translate into use within Celestia scripts?

For the Bezier support idea you should be familiar with a little more complicated tools, though.

The only thing I can say about Bezier, is that I know what a Bezier curve *is*, and how to use them in graphics programs -- but wouldn't know how to program one in a script.

Here is another idea.

Thanks Toti. This is one I *should* be able to write.

[Toti]

There's a lot of web tutorials on this.

Could you post links to a couple that you think could be understood by folks like me (no math degree), and also be fairly easy to translate into use within Celestia scripts?

I was referring to simple vector operations. This two links have info:
http://www.physics.uoguelph.ca/tutorials/vectors/vectors.html
http://www.math.hmc.edu/calculus/tutorials/vectoranalysis/

Don't feel intimidated by the mathematical notation: both tutorials are fairly understandable. The most important subjects are:

* vector addition
* vector substraction
* vector multiplication by an scalar
* vector lenght
* dot product

On coordinate systems: I think that it will be very difficult to find Celestia-useful info on this subject. I don't know the details of how Celestia handles coordinate systems. Most probably it involves the usual Affine Transformation approach. In any case, this is a fairly heavy topic, but the good thing is that Celestia does all the job for you, so you don't need any knowledge on this.
This weekend, I expect to be able to code a small vectorial application in LUA: I will fill it with explanations and documentation, so -hopefully- it will make things easier for everyone else.

Bye

[don]

I was referring to simple vector operations. This two links have info: ...

Thank you Toti. I'll have a look later tonight.

On coordinate systems: ... but the good thing is that Celestia does all the job for you, so you don't need any knowledge on this.

Really? In Cel, you need to specify 3-value vectors, XYZ rot, angle, base, offset, axis, etc., for commands such as goto, gotoloc, gotolonglat, move, orbit, rotate, setorientation, and setposition. In other words, you can't simply "center" an object and then apply thrust, like you can in the keyboard navigation mode.

For example, trying to get the camera to move in a straight line, towards the center of the screen, has been a futile attempt of many folks -- in both, Cel and Celx.

This weekend, I expect to be able to code a small vectorial application in LUA: I will fill it with explanations and documentation, so -hopefully- it will make things easier for everyone else.

Jumping up and down with anticipation!

[Toti]

On coordinate systems: ... but the good thing is that Celestia does all the job for you, so you don't need any knowledge on this.

Really? In Cel, you need to specify 3-value vectors, XYZ rot, angle, base, offset, axis, etc., for commands such as goto, gotoloc, gotolonglat, move, orbit, rotate, setorientation, and setposition. In other words, you can't simply "center" an object and then apply thrust, like you can in the keyboard navigation mode.

For example, trying to get the camera to move in a straight line, towards the center of the screen, has been a futile attempt of many folks -- in both, Cel and Celx.

I think that I haven't explained myself very well...sorry. I was referring to the fact that you don't need to pre calculate and enter a 4x4 matrix (or whatever math device is implied) to do a coordinate system conversion. Of course that you will need a more or less defined idea on how the coordinate systems work (at least at interface level)



A very brief explanation of coordinate systems:

You are walking on the street. Somebody asks you where is certain building. Some possible answers are:
a) 'Two blocks ahead, turn to the left and do two more'
b) '48.8632 S 2.332 E'
c) 'r=28 kly. RA=17:45.7 deg. DE=-28:56 deg.'

All of them are correct (let's assume they are). But you choose the first one. Why? Because it is the most appropriate: it's understandable, short, simple and effective. What your brain is doing is a surprisingly clever thing: it's choosing the best coordinate system for the occasion.
In an almost subconcious way, you are making some suppositions:
1] This floor tile (where I am standing) is the center of the universe
2] Up is above my head, forward is along this street in the direction of traffic, and the street that crosses this one at right angle gives me the remaining direction.
3] The unit of distance is 'a block'
That is in fact the soul of coordinate systems:
1] where is its center placed (the mathematicians call it 'origin of coordinates')
2] how are the three coordinates oriented in space? That is: where is 'up'?, which direction can I call 'ahead'?, etc.
3] in which units can I measure things?

In your room, look at the corner where two walls meet each other and the floor.
There are three ridges that join together in a central point (the origin of coordinates). You can think of this as a natural coordinate system. Let's name each coordinate: the vertical ridge with a Y, and the other two with an X and a Z.
Now you can say, for example: the geometrical center of my computer is 3 meters in the X direction, 2 meters in the Z direction and 1.5 meters in the Y direction from the origin of coordinates. In fact, you can measure the whole room's content (and the universe) using this coordinate system.
But you may find more comfortable to use another system, like your computer CRT display: the new origin of coordinates would be in the top left point of the screen, the X would be horizontal, the Y vertical (both parallel to the surface), and the Z would be perpendicular to the display's glass cover.

Now you might say: let's change to this newer coordinate system: it's closer to me and more intuitive. You'd start measuring all things in the room in relation to the new system (let's suppose this is important for you ), as you did before with the older one... but you don't have to: you only need to measure the position of the new system in relation to the older one (or vice versa), and then, using some linear algebra, you can compute all objects positions in relation to the new system, without need of additional work!
In short terms, coordinate systems are transformable: you can change from one to another, when you think that it will make your work easier.
We do this all the time: in the initial example, choosing the referred system allows us to forget about Earth trajectory (polar measuring from the galaxy's center (answer c) would not achieve this: Earth's own motion would leave this spatial point behind very soon). It also allows us to forget about the fact that our planet is of course an spheroid, so technicaly speaking, 'ahead' wouldn't be signalling a surface point, but a 'floating on air' one, etc.

In fact, one of the main goals of linear algebra is to find the coordinate system where that seemingly impossible to resolve math problem turns to be absurdly trivial...


To illustrate a little bit the topic, here is a script that rotates the viewer around the Earth. It's a small modification of Harald Schmidt's Around the Earth, with added comments.
It works in universal coordinates.

Code: Select all

--******************************************************
--******************************************************
--  This script is a modification of Harald Schmidt's
--         "Around the Earth"
--
--
--******************************************************
--******************************************************

--************************************************
--UCS   = Universal coordinate system
--************************************************


function around(body, pos, r)
   -- this function puts the viewer in 'pos' of body. All is done in UCS:

   -- this two equations look rather complicated, but they are only a 2D polar-cartesian conversion,
   -- that is, given a (radius,angle) = (r,pos), convert it to (x,y) values. They are a "classic":
   local x = r * math.cos(math.rad(pos))
   local z = r * math.sin(math.rad(pos))

   -- keep the up pointing coordinate on the UCS "horizontal" plane:
   local y = 0

   -- let's create a vector with the above coordinates. We create a vector because they don't need to be
   -- that precise (they are pretty small coordinates, with lenght = r at most):
   local offset   = celestia:newvector(x,y,z)
   
   -- obtain a vector that is the center of 'body' in UCS. This is a 'position' vector, so it is very precise. Why is this?
   -- Because universal coordinate system places its center at about 200 AU from sol. If we do not assure enough precision,
   -- our 'rel_pos' would not be placed on 'body' but a few thousand km. from it.
   local rel_pos   = body:getposition ()

   -- viewer's position: let's go to center of body and then go to offset (that is what a vector addition does, really).
   -- This adds a 'common vector' to a 'position vector', so the maximun precision is retained. We want that, because we
   -- want to place the viewer exactly where it's needed (and not a few thousand km. around)
   local rel_pos2   = rel_pos + offset

   -- let's place the observer there:
   local obs       = celestia:getobserver()
      obs:setposition (rel_pos2)

   -- look at earth center with upvector as "ceiling". This is complex... close your hand. Extend your thumb.
   -- Then extend the first finger, and point it to this -> x. (Keep the angle between both fingers fixed.)
   -- This behaves like the viewer: your thumb is the 'up' axis. Your first finger is the viewer's 'look_at' axis.
   -- When you point it to the 'x', you are transforming the 'up' vector (your thumb moves with your hand),
   -- but it doesn't matter, because you have already defined where it is in relation with the rest of your hand.
   -- I believe that Celestia does this same thing that you have done with your hand: First creates an "abstract" viewer,
   -- then defines where is 'up' and last, moves/rotates the viewer to point its "camera" to the selected body.
   -- The 'up' vector signals the viewer's "ceiling" BEFORE Celestia rotates it in order to look at some place.
   obs:lookat (rel_pos, upvector)

   -- print the viewer's position (in UCS):
   celestia:flash("Viewer pos.: " .. rel_pos2.x .. " " .. rel_pos2.y .. " " .. rel_pos2.z , 1)

   -- return control to Celestia for a moment (to refresh screen, etc.):
   wait(0.0)
end


--************************************************
--      Now call the function
--************************************************

-- define which direction we should call it 'up'.
-- since this is only a rough direction, we can use a 'common vector'. We don't need precision here:
upvector   = celestia:newvector (0,1,0)

-- select body:
celBody   = celestia:find("Sol/Earth")

-- get its position (remember, since it's a body position relative to a center of coordinates 200 AU far from us,
-- we will need precision here):
zeropos   = celBody:getposition()

-- our orbit will take only 60 seconds:
t0 = 0
t1 = 60

-- and we will complete one orbit:
rot_speed = 360 / t1

-- let's fix the viewer's distance to the body's center:
R = 0.005

-- loop for 60 seconds:
while t0 < t1 do
   t0 = celestia:getscripttime()

   -- this will be the longitude that we will pass to the function.
   -- It's in function of time, like many parameter trajectories like:
   a = rot_speed * t0 * 5

   -- call the function:
   around(celBody, a, R)
end 


Run it. What do you notice? We wanted to rotate around Earth, and we did it: our viewer now orbits Earth. But there is a small "problem": Earth is tilted, because we are rotating roughly on an UCS "horizontal" plane (we fixed y = 0, and we never changed the default coordinate system: 'universal').
I said roughly horizontal because Earth is moving, and the plane of this movement (the ecliptic plane) is not parallel to the UCS horizontal plane. Hence the need for an "ecliptic" coordinate system. So Earth is going slightly "down" in its movement with respect to the UCS horizontal plane. (you can clearly see this in the middle coordinate value that is printed by the script). If Earth was still, or if the ecliptic plane was parallel to the UCS horizontal one, this value would be constant.
But you can forget about this details (for now).

What happens if we want to rotate on Earth's equator plane? We could try doing some trigonometrics in order to find a function that could replace the y = 0 line. A properly derived function will give an up and down movement to the viewer, making it follow the equatorial plane.
But there is another way to do it, and it is much simpler: we can change the coordinate system, so:
1] our origin will be at Earth's center.
2] our system will be properly oriented as Earth is: the new 'up' (y coordinate) won't be "vertical", but tilted (following the N-S earth's line), and the x and z coordinates will be on the equatorial plane, pointing 90 degrees apart.
Now mathematical description of the y coordinate becomes easier: where is the equator plane? At y=0 (remeber that in UCS y=0 wasn't the equatorial plane). On this new coordinate system, the fact that the planet is inclined isn't important at all, because the system is inclined with the planet. We have eliminated the importance of tilt, and made a fairly complex problem a lot easier.
I will add this new script on another post.

Bye

[don]

Thank you very much Toti!

I assume that "y=0" is how the code defines the Universal coord system, right? If not, would you add code to show the specific newframe and setframe commands showing us where the UCS is being set?

Where would code go to change the coordinate system, to say equatorial?

[Toti]

I assume that "y=0" is how the code defines the Universal coord system, right?

No. Frames are defined by the method celestia:newframe(). But you don't have to create the UCS frame. It's the default one. When you create a vector (or get an object's position) they are returned in reference to UCS. Always. If you need to work in other coordinate system (CS) you will need to convert them (using the coord_frame:to() method)
In other words, if you create a vector:
myVector = celestia:newvector(3,5,7)
It will start on the UCS origin, and it will end in the point that is (3 units on X axis, 5 units on Y axis, 7 units on Z axis) from this origin of coordinates.
If you want to convert it to myFrame CS (let's assume that it was already created), you will need to write:
myVector_rel = myFrame:to(myvector)


Another key:
earth_position = earthbody:getposition()
will return how many x, y and z units Earth's center is from the UCS origin.
If you have created a Earth geographical coordinate system (let's call it myGeoFrame), and you add:
earth_position_rel = myGeoFrame:to(earth_position)
The new vector will mean "how many (x,y,z) units is the Earth's center from the new frame (myGeoFrame) origin of coordinates"
But since myGeoFrame is centered on Earth, its origin will be at Earth's center (buh!)
So the above sentence can be translated into:
"how many (x,y,z) units is the Earth's center from the Earth's center"
As you may guess, this is (0,0,0). That is, using myGeoFrame, all objects of the universe are measured from Earth's center.


Back to your question, the lines:
local x = r * math.cos(math.rad(pos))
local z = r * math.sin(math.rad(pos))
local y = 0
only create the coordinates of a vector. The vector itself is then created by the line:
local offset = celestia:newvector(x,y,z)

I could have written it this way:
local offset = celestia:newvector(r * math.cos(math.rad(pos)), r * math.sin(math.rad(pos)), 0)
that is the same.
These lines are only responsible of the circular movement around Earth. the first two do the circular motion itself.
The third one says: don't change height (Celestia's UCS height is determined by the second coordinate). Fix it on 0 (y = 0)
The circular motion is composited from two vectors offset and rel_pos:
offset gives us a changing position around UCS origin of coordinates (0,0,0) point (note that this vector depends on two parameters: the latter is constantly changed (radius r and angle pos), hence the motion.
rel_pos gives us the position of Earth in UCS (look for the code line where it is created)
the addition of both gives us a rotation around Earth.

You can try this (but don't do it yet, it doesn't work):
change the line: rel_pos = rel_pos + offset
to this: rel_pos = offset
Now we won't be rotating around Earth, because we destroyed the vector that places us in its position.
But we kept the offset vector in its place, so a rotation will happen... around the default origin of coordinates.

Why doesn't it work? It's because there is a small Celx problem: offset is a vector. And you can't set positions using vectors: you need positions.
But the workaround is more interesting:
Change the CS of rel_pos to "equatorial", using Earth as center. rel_pos is the Earth's center position, so if we change this to a Earth centered CS, it will point to Earth's center from Earth's center, so it will be (0,0,0). I've already wrote about this.
But it will be still a position, not a vector, so it will be really useful.
When added to offset:
offset + rel_pos = offset + (0,0,0) = offset
That's because if you add (a1,a2,a3) + (b1,b2,b3) = (a1+b1,a2+b2,a3+b3). If the first vector is (0,0,0), when you add it to another you get the second vector untouched.
All this is done this way:

In the above code, add this:

Code: Select all

local obs_frame   = celestia:newframe("equatorial",body)
local rel_pos   = obs_frame:to(rel_pos)

After this:

Code: Select all

local rel_pos   = body:getposition ()

And that's all


I hope this helps.

[don]

Hi Toti,

Thank you for your explanation. This will require some "quiet time" when I can clear my mind and focus on what you wrote and test different things in code. Hopefully Monday.

[don]

-------
For a continuation of Toti's explanation script, please go to this topic: A brief introduction to Celx vectors -- http://www.shatters.net/forum/viewtopic.php?t=4952
-------

If you have ideas for a Celx utility script, please post them here...

[Toti]

Back on topic, here is another idea:
a script that puts you on the surface of a body, gets its rotational period (is it accesible from LUA?), and calculates its day's lenght (dl). If the required data can't be obtained by LUA, you could manually put it on a table:
Then, it enters a loop where:
1) The value [dl] is added to current time (a constant time jump)
2) Keeps normal time going on for a few seconds (this lapse can be set by a parameter)
3) If requested takes a screen shot (a boolean parameter)

We will able to see the varying position of the Sun on Earth's sky for one year, or the movement of Jupiter from one of its moons, etc.
The same approach can be done with orbital period.

Is this already implemented?

Bye

[Harry]

Not what you described, but it has some similarities:
http://www.shatters.net/forum/viewtopic.php?p=33651

Harald

[maxim]

Another try

A script that computes the (real) local time for a surface location. 'Real local time' means the sun time, not the timezone time. Starting from the current time for the 0-meridian, the actual longitude gives the actual local time. Only problem is that I have no idea how to get the current 0-median time for a planetary body.

An extension would be to detect if the location currently is on the dayside, the nightside, at dusk or at dawn.


Ok, another one:

The reason for the previous is the idea for a script that takes a set of surface locations and visits them in successive movements NOT going throught the body. If the currently visited location is on the nightside, ambient light is dimmed up to a certain amount, to make the location visible.

maxim

[Toti]

Harald:
many thanks for the link. That script is EXTRAORDINARY.

To the casual reader:
One way to use the script:
1] select Earth (hit 3)
2] gotoSurface (ctrl-g)
3] sync to Earth's rotation (hit y)
4] search for the sun and align your view with it
5] accel time until it is 20-30 degrees over the local horizon
6] realign your view with sun
7] increase your FOV to about 70 degrees [hit .]
8] be sure Earth is still selected
9] run the script
10] jump n solar days (keep key d pressed)

Watch the lemniscate-sort of curve that the sun draws on the sky. Look at the planets' movement, some progress and then retrogress... really intriguing
Finally, try changing your latitude and repeat the experiment.
You can also do sidereal day and sidereal year steps. (a, s keys resp.)


Bye

[don]

...a script that puts you on the surface of a body, gets its rotational period (is it accesible from LUA?), and calculates its day's lenght (dl). ...

Sounds pretty much like Harald's script, yes?

That script can definately show you some AMAZING things. Reminds me of the original movie of H.G. Wells "Time Machine" (not the remake).

[don]

Another try

I'm still thinking about your first suggestions.

A script that computes the (real) local time for a surface location [current 0-median time].

Not sure if this time is available, or if it can be calculated. But, based on what I've seen between Harald and Toti, I'll bet one of them could determine the position of the sun relative to the camera's current position and determine if the sun would be shining on that part of the object or not. Probably a simple task for either of them. Harald? Toti?

An extension would be to detect if the location currently is on the dayside, the nightside, at dusk or at dawn.

If time can actually be calculated, then this is what the time would tell us.

The reason for the previous is the idea for a script that takes a set of surface locations and visits them in successive movements NOT going throught the body. If the currently visited location is on the nightside, ambient light is dimmed up to a certain amount, to make the location visible.

Ahhhhh, an excellent idea! Thanks maxim. This way, the sunny parts of the object would not be TOO bright, due to a higher ambient light setting. The script would automatically adjust the ambient light to the current conditions.