I'm about to implement mutiple views in my script and I wanted to make sure I understood the basic idea.
celestia: getobserver() creates a new observer-object. (I was confused by the "get" rather than "new.")
<observer-object>:singleview() can switch to another observer object in a single view.
If I want to sychronize the position of both objects I must do that in my code. They're otherwise independent.
Does this sound about right?
Henry
Check on understanding of multiple observer objects
Re: Check on understanding of multiple observer objects
hharris wrote:I'm about to implement mutiple views in my script and I wanted to make sure I understood the basic idea.
celestia: getobserver() creates a new observer-object. (I was confused by the "get" rather than "new.")
<observer-object>:singleview() can switch to another observer object in a single view.
If I want to sychronize the position of both objects I must do that in my code. They're otherwise independent.
Does this sound about right?
Henry
No, that does not sound right.
celestia: getobserver() returns the observer of the currently active view.
<observer-object>:singleview() deletes all the views except that of the indicated observer.
The CELX functions are documented in Harald Schmidt's CELX scripting guide.
- Hank
-
Topic authorhharris
- Posts: 79
- Joined: 23.02.2006
- With us: 18 years 8 months
- Location: Pasadena, CA 91104
Mmmmm... Then I'm totally confused. Before writing the message, I of course went though the scripting guide you referred to specifically looking for a "new observer" method and this was all I could come up with by process of elimination. That's why I wrote the message. As you point out, it doesn't seem quite right.
"GetObserver" is the only method I could find that returned an observer object. I guess I'm stumped as to what the unnamed methods you refer to could be.
I must be missing something important.
Henry
"GetObserver" is the only method I could find that returned an observer object. I guess I'm stumped as to what the unnamed methods you refer to could be.
I must be missing something important.
Henry
-
- Posts: 164
- Joined: 18.03.2004
- Age: 63
- With us: 20 years 7 months
- Location: Victoria, BC Canada
hharris wrote:"GetObserver" is the only method I could find that returned an observer object. I guess I'm stumped as to what the unnamed methods you refer to could be.
I think the call you are looking for is splitview()
The following is a list of the methods that return observer objects:
celestia:getobserver() - returns the current observer (the active view)
celestia:getobservers() - returns a table of all valid observers (all views)
obs:splitview() - creates a new view occupying a portion of the screen used by the observer object obs. Returns the observer associated with the new view.
The following are related to working with observer objects, but do not return observer objects:
obs:singleview() - removes all views except the view associated with the observer object obs
obs:deleteview() - removes view associated with the observer object obs
(note: I have found that singleview does not work unless called for the currently, active view. That is nonactiveobs:singleview() causes problems)
Clive Pottinger
Victoria, BC Canada
Victoria, BC Canada
-
Topic authorhharris
- Posts: 79
- Joined: 23.02.2006
- With us: 18 years 8 months
- Location: Pasadena, CA 91104
Thank you. These are the methods I came up with also, but there seems to be an inconsistency in the documentation and the methods themselves and I'm trying to resolve the two.
The documentation for splitview doesn't mention it's returning anything, but what I would assume from what you're saying is that:
(1) the program is initialized with a single obsever object. That object can be accessed through celestia:getobserver().
(2) observer: splitview() can be called on that object to create another object which is returned. There are now two observer objects and a table of these can be created by celestia:getobservers()
Okay, so far so good. I would further assume that although the screen has been split (by splitview) only one of those segements is the "active view" even though both are showing. The active view can be returned by calling getobserver() again.
Here are my questions:
(1) The documentation states that the active view can be changed but I can't find a method for doing this. What is the method?
(2) Is there a way to show only one view at a time? It looks like one would have to create a multiple segmented screen and collapse that into a single view. Not really a problem, I guess, but I need a way to change the active view so I can switch between them with singleview().
(3) Am I correct in my assumption that these views (objects) are totally independent? For example if I change the position of one, the others are unaffected?
Thanks for your help.
Henry
The documentation for splitview doesn't mention it's returning anything, but what I would assume from what you're saying is that:
(1) the program is initialized with a single obsever object. That object can be accessed through celestia:getobserver().
(2) observer: splitview() can be called on that object to create another object which is returned. There are now two observer objects and a table of these can be created by celestia:getobservers()
Okay, so far so good. I would further assume that although the screen has been split (by splitview) only one of those segements is the "active view" even though both are showing. The active view can be returned by calling getobserver() again.
Here are my questions:
(1) The documentation states that the active view can be changed but I can't find a method for doing this. What is the method?
(2) Is there a way to show only one view at a time? It looks like one would have to create a multiple segmented screen and collapse that into a single view. Not really a problem, I guess, but I need a way to change the active view so I can switch between them with singleview().
(3) Am I correct in my assumption that these views (objects) are totally independent? For example if I change the position of one, the others are unaffected?
Thanks for your help.
Henry
hharris wrote:The documentation for splitview doesn't mention it's returning anything, but what I would assume from what you're saying is that:
(1) the program is initialized with a single obsever object. That object can be accessed through celestia:getobserver().
(2) observer: splitview() can be called on that object to create another object which is returned. There are now two observer objects and a table of these can be created by celestia:getobservers()
Okay, so far so good. I would further assume that although the screen has been split (by splitview) only one of those segements is the "active view" even though both are showing. The active view can be returned by calling getobserver() again.
Here are my questions:
(1) The documentation states that the active view can be changed but I can't find a method for doing this. What is the method?
(2) Is there a way to show only one view at a time? It looks like one would have to create a multiple segmented screen and collapse that into a single view. Not really a problem, I guess, but I need a way to change the active view so I can switch between them with singleview().
(3) Am I correct in my assumption that these views (objects) are totally independent? For example if I change the position of one, the others are unaffected?
celestia:getobserver() returns the observer for the active view, whatever it may be. The user can change the active view at any time by clicking in the view. I don't see a way to change the active view using CELX. I don't think it's needed.
observer: splitview() "splits" the view of the specified observer. The height or width of the original view is adjusted, and a new view is created in the remaining space. The new view has a new observer, which is initially a duplicate of the specified observer. The documentation does not indicate that the new observer is returned. You probably have to use celestia:getobservers() to get it.
observer:singleview() deletes all views except the view of the specified observer. That is how you would show a single view. You don't need the active view for this.
The observers for separate views are independent.
- Hank
-
Topic authorhharris
- Posts: 79
- Joined: 23.02.2006
- With us: 18 years 8 months
- Location: Pasadena, CA 91104
Okay, I think I'm getting the gist of this. I was thinking I would be creating several observer objects and switching between them. But a simpler way is to just reset the orientation of a single observer object for different "views." I was making this a harder problem than it really is.
And I see the point of "active" views now. It's a way to tell your script that the user has clicked on part of a segmented window. I can see how that would be useful.
Thanks!
Henry
And I see the point of "active" views now. It's a way to tell your script that the user has clicked on part of a segmented window. I can see how that would be useful.
Thanks!
Henry
-
Topic authorhharris
- Posts: 79
- Joined: 23.02.2006
- With us: 18 years 8 months
- Location: Pasadena, CA 91104
Wait a minute
Oh, wait... I just remembered how I got to this point in the first place. The real problem is that if you have only one observer and you change orientation, then you change your velocity vector. If I were to change the orientation to look backwards, not only would the view change, the velocity would reverse (as set by setspeed)).
I was going to multiple objects to avoid this problem. One object was going to be the view and the other was going to be the direction of travel.
Surely there must be a simple solution to this. I suppose I could adjust the velocity with orientation e.g. make it negative for an aft view? But for anything but aft it wouldn't work.
Would the method LookAt be appropriate here? Or does it change the velocity vector too?
Henry
I was going to multiple objects to avoid this problem. One object was going to be the view and the other was going to be the direction of travel.
Surely there must be a simple solution to this. I suppose I could adjust the velocity with orientation e.g. make it negative for an aft view? But for anything but aft it wouldn't work.
Would the method LookAt be appropriate here? Or does it change the velocity vector too?
Henry
-
- Posts: 164
- Joined: 18.03.2004
- Age: 63
- With us: 20 years 7 months
- Location: Victoria, BC Canada
Re: Wait a minute
First,
For hharris, note: splitview() does not change the active view, so getobserver() won't gain you access to it. You can access the new observer by performing a celestia:getobservers() call - the new view is last entry in the returned table.
I have not seen any celx call (except setspeed()) have any affect on the observer's speed or direction as set by the F1-F7 keys.
Thanks hank, my mistake - splitview does not return an observer object.hank wrote:celestia:getobserver() returns the observer for the active view, whatever it may be. The user can change the active view at any time by clicking in the view. The documentation does not indicate that the new observer is returned. You probably have to use celestia:getobservers() to get it.
For hharris, note: splitview() does not change the active view, so getobserver() won't gain you access to it. You can access the new observer by performing a celestia:getobservers() call - the new view is last entry in the returned table.
I have only seen this happen with the keyboard arrows are used to change the orientation. For instance - go to Earth, centre Jupiter, set velocity to c (F4) so you are moving towards Jupiter. Press * and you will see that you are moving away from Earth; your direction of travel does not change.hharris wrote:The real problem is that if you have only one observer and you change orientation, then you change your velocity vector. If I were to change the orientation to look backwards, not only would the view change, the velocity would reverse (as set by setspeed)).
I have not seen any celx call (except setspeed()) have any affect on the observer's speed or direction as set by the F1-F7 keys.
LookAt should be fine - as far as I can tell, from within celx, any command to change your orientation should work without affecting speed or direction.hharris wrote:Would the method LookAt be appropriate here? Or does it change the velocity vector too?
Clive Pottinger
Victoria, BC Canada
Victoria, BC Canada
-
- Posts: 17
- Joined: 25.09.2006
- With us: 18 years 1 month
- Location: Munich / Germany
getobserver and getorientation commands
I have a similar question and could also not find the answer: I suggest the two commands dont need any argument...:
getoberserver { }
getorientation { }
But I would like to give them an argument, namely to turn the screen view for 90 degrees- while the program orbits any planet or moon.
It makes a better view, more realistic in 4D environment ( some may know these camera turns from 2001- A Space Odyssee) while celestia is orbiting around any planet and gets closer to its surface, if the rotation axis is turned horizontal . and if leaving the orbit moves back to the default position ( ecliptical level in the horizontal direction
so I would move in an vertical position along its equator, while the planet on the screen rotates during the orbital manoevre around its axis that appears on the screen then in horizontal position.
So if that is possible:
setorientation { angle 90 [ 1 1 0 ]} or
getoberserver { angle 90 [ 1 1 0 ]}
did nt effect the requested way. Is there any command at all and what is its complete code?
Thanks!
getoberserver { }
getorientation { }
But I would like to give them an argument, namely to turn the screen view for 90 degrees- while the program orbits any planet or moon.
It makes a better view, more realistic in 4D environment ( some may know these camera turns from 2001- A Space Odyssee) while celestia is orbiting around any planet and gets closer to its surface, if the rotation axis is turned horizontal . and if leaving the orbit moves back to the default position ( ecliptical level in the horizontal direction
so I would move in an vertical position along its equator, while the planet on the screen rotates during the orbital manoevre around its axis that appears on the screen then in horizontal position.
So if that is possible:
setorientation { angle 90 [ 1 1 0 ]} or
getoberserver { angle 90 [ 1 1 0 ]}
did nt effect the requested way. Is there any command at all and what is its complete code?
Thanks!
Anyway we are never satisfied. and we always search for more? Note: When visiting my homepage you will will probably need Internet Explorer that reads its cfm code
- Chuft-Captain
- Posts: 1779
- Joined: 18.12.2005
- With us: 18 years 10 months
Mystery,
I may be misunderstanding what you're trying to do, but it sounds to me like the effect you want would be largely achieved by "tracking" the object.
I may be misunderstanding what you're trying to do, but it sounds to me like the effect you want would be largely achieved by "tracking" the object.
"Is a planetary surface the right place for an expanding technological civilization?"
-- Gerard K. O'Neill (1969)
CATALOG SYNTAX HIGHLIGHTING TOOLS LAGRANGE POINTS
-- Gerard K. O'Neill (1969)
CATALOG SYNTAX HIGHLIGHTING TOOLS LAGRANGE POINTS
-
Topic authorhharris
- Posts: 79
- Joined: 23.02.2006
- With us: 18 years 8 months
- Location: Pasadena, CA 91104
You might try using the function "transform." Here's how I get a "backwards" view.
backVector = celestia:newvector(-1 , 0, 0)
upVector_b = celestia:newvector(0, -1, 0)
rot = obs:getorientation()
bVector = rot:transform( backVector )
up = rot:transform( upVector_b )
newPos = myPos:addvector( bVector )
obs: lookat( myPos , newPos , up) --[[ changes observer's orientation ]]
But in my case, to achieve what I wanted, I also have to reverse the velocity vector. That's because, as far as I can figure out, the look direction and velocity vector are never independent.
Henry
backVector = celestia:newvector(-1 , 0, 0)
upVector_b = celestia:newvector(0, -1, 0)
rot = obs:getorientation()
bVector = rot:transform( backVector )
up = rot:transform( upVector_b )
newPos = myPos:addvector( bVector )
obs: lookat( myPos , newPos , up) --[[ changes observer's orientation ]]
But in my case, to achieve what I wanted, I also have to reverse the velocity vector. That's because, as far as I can figure out, the look direction and velocity vector are never independent.
Henry