New object flags

Discussion forum for Celestia developers; topics may only be started by members of the developers group, but anyone can post replies.
Topic author
chris
Site Admin
Posts: 4211
Joined: 28.01.2002
With us: 22 years 9 months
Location: Seattle, Washington, USA

New object flags

Post #1by chris » 02.02.2008, 23:00

Cross-posted from the developers list...

I've created a new patch that adds some new objects attributes,
similar to the Clickable patch:

http://www.celestiaproject.net/~claurel/celest ... s/objflags

This folder contains a patch file and two test scripts.

The new flags are:

visible - true if the object is visible, false otherwise
visibleAsPoint - true if the object should be visible as a starlike
point when it occupies less than a pixel on screen
orbitColorOverridden - true if a custom orbit color should be used for
the object

The first attribute is accessible via a setvisible script method. The
usage is straightforward. Here's a sample script that toggles the
visibility of Earth:

Code: Select all

earth = celestia:find("Sol/Earth")
earth:setvisible(not earth:visible())


There is no script method for visibleAsPoint (though it's easy to add
if it's necessary for some reason.) This attribute is set
automatically based on the object class. Objects of the new classes
component and surfacefeature (and the existing class invisible) have
this attribute set to false; for all other objects it is true.

Finally, orbitColorOverridden exists so that the default object class
orbit colors may be overridden with custom orbit colors. This is
useful in educational and trajectory visualization applications of
Celestia. In the current version of the patch, the orbit color may
only be set via script, as in this example:

Code: Select all

obj = celestia:find("Sol/Earth")
obj:setorbitcoloroverridden(true)
obj:setorbitcolor(r, g, b)


It may be useful if orbit colors could also be set in ssc files.

--Chris

Avatar
Cham M
Posts: 4324
Joined: 14.01.2004
Age: 60
With us: 20 years 9 months
Location: Montreal

Post #2by Cham » 02.02.2008, 23:08

In my opinion, the orbitColorOverridden should be accessible in the SSC. Also, I think that the name is too long for nothing. I suggest to use orbitColor instead, since it means the same.

For the moment, I don't see the usefulness of the other options.
"Well! I've often seen a cat without a grin", thought Alice; "but a grin without a cat! It's the most curious thing I ever saw in all my life!"

Topic author
chris
Site Admin
Posts: 4211
Joined: 28.01.2002
With us: 22 years 9 months
Location: Seattle, Washington, USA

Post #3by chris » 02.02.2008, 23:27

Cham wrote:In my opinion, the orbitColorOverridden should be accessible in the SSC. Also, I think that the name is too long for nothing. I suggest to use orbitColor instead, since it means the same.

Thank you for the feedback . . .

It's necessary to have two functions: one to specify that whether the orbit color should be overwritten, and another to specify what the orbit color should be. However, in an SSC file, just adding a single property OrbitColor would do the trick--the ssc parser would automatically set the orbitColorOverridden flag if this were present.

For the moment, I don't see the usefulness of the other options.


Being able to hide objects is very useful--Selden's Hale telescope is one add-on that will benefit. The new object classes surfacefeature and component are useful for logical categorization of objects--there's simply no appropriate class for the buildings and spacecraft components in many add-ons. Not showing the star-like disc for such objects means that the albedo=0 trick is no longer necessary.

--Chris

Avatar
Cham M
Posts: 4324
Joined: 14.01.2004
Age: 60
With us: 20 years 9 months
Location: Montreal

Post #4by Cham » 02.02.2008, 23:31

chris wrote:Not showing the star-like disc for such objects means that the albedo=0 trick is no longer necessary.


I understand the usefullness of the new classes (we need more), but what is the problem with the albedo trick ? If it was working, why adding another function which is doing the same ?
"Well! I've often seen a cat without a grin", thought Alice; "but a grin without a cat! It's the most curious thing I ever saw in all my life!"

Topic author
chris
Site Admin
Posts: 4211
Joined: 28.01.2002
With us: 22 years 9 months
Location: Seattle, Washington, USA

Post #5by chris » 02.02.2008, 23:46

Cham wrote:
chris wrote:Not showing the star-like disc for such objects means that the albedo=0 trick is no longer necessary.

I understand the usefullness of the new classes (we need more), but what is the problem with the albedo trick ? If it was working, why adding another function which is doing the same ?


Two reasons: first of all, it's sensible behavior for objects of the new classes to not appear as star-like discs. Second, even though the albedo trick works, it's a little ugly and non-obvious. The albedo of the objects is not in fact zero, so what should an add-on creator have to fake it just to get the right appearance? I'm trying reduce the number of such Celestia idiosyncrasies that an add-on creator needs to learn.

--Chris

Avatar
Cham M
Posts: 4324
Joined: 14.01.2004
Age: 60
With us: 20 years 9 months
Location: Montreal

Post #6by Cham » 02.02.2008, 23:55

chris wrote:I'm trying reduce the number of such Celestia idiosyncrasies that an add-on creator needs to learn.


While I'm one of the add-on creators which is already asking for more options at the SSC/DSC level, I don't see how it would help with more "esoteric" options to remember. The albedo trick is pretty "natural" to me, since it's already a measure of the amount of light an object should reflect. Maybe Selden could say something about this.

By the way, please, I strongly suggest that you also add the possibility to use the Clickable option on the DSC level too. This option is simply too important.
"Well! I've often seen a cat without a grin", thought Alice; "but a grin without a cat! It's the most curious thing I ever saw in all my life!"

ajtribick
Developer
Posts: 1855
Joined: 11.08.2003
With us: 21 years 2 months

Post #7by ajtribick » 03.02.2008, 00:14

Cham wrote:While I'm one of the add-on creators which is already asking for more options at the SSC/DSC level, I don't see how it would help with more "esoteric" options to remember. The albedo trick is pretty "natural" to me, since it's already a measure of the amount of light an object should reflect.

But it is physically nonsense. The albedo is not zero, so it's a hack, despite how much you may be used to it. Since it is physically nonsense, it is non-obvious for a new add-on creator, who hasn't had experience in dealing with the quirk that requires the hack.

Avatar
Cham M
Posts: 4324
Joined: 14.01.2004
Age: 60
With us: 20 years 9 months
Location: Montreal

Post #8by Cham » 04.02.2008, 02:02

Chris,

since you added new SSC options in SVN, we need an explicit example of the way we should use them.
"Well! I've often seen a cat without a grin", thought Alice; "but a grin without a cat! It's the most curious thing I ever saw in all my life!"

Topic author
chris
Site Admin
Posts: 4211
Joined: 28.01.2002
With us: 22 years 9 months
Location: Seattle, Washington, USA

Post #9by chris » 04.02.2008, 05:31

Cham wrote:Chris,

since you added new SSC options in SVN, we need an explicit example of the way we should use them.


Note that everything that I'm describing in this message only works with the very latest code from SVN.

To use the new surfacefeature or component classes, simply specify:

Code: Select all

Class "surfacefeature"

or

Code: Select all

Class "component"


in the SSC object definition. To override the default orbit color, add this line to the object definition:

Code: Select all

OrbitColor [ red green blue ]


...where red, green, and blue are floating point values between 0 and 1. Finally, to make an object not visible, add this line:

Code: Select all

Visible false


This is different than setting the class to invisible--it indicates that not being hidden is a temporary state, not a fundamental attribute of the object. All of the uses that I can think of for the Visible flag involve scripting.

For an example of what's possible with the new object attributes with scripts, have a look at my Jovian satellites script:

http://www.celestiaproject.net/~claurel/celest ... moons.celx

It lets you highlight the orbits of six different families of Jupiter's moons.

--Chris

Avatar
Cham M
Posts: 4324
Joined: 14.01.2004
Age: 60
With us: 20 years 9 months
Location: Montreal

Post #10by Cham » 04.02.2008, 10:55

Isn't there another option : OrbitVisible ?

EDIT : I tested the script. it works (and it's interesting !). But it's a bit slow. The orbit toggling appears to be jerky in some way : the orbits in a single group do not draw at once, some orbits are "late" when drawing themselves. Is this a normal behavior of the script ?

Hmm, using the keys (1, 2, ...6) repeatedly gives some odd things. Pressing "1" few times, and I got Mercury selected (the script was still working). Pressing "4" several times, and the script forgot Iocaste, until it reselected that moon.
"Well! I've often seen a cat without a grin", thought Alice; "but a grin without a cat! It's the most curious thing I ever saw in all my life!"

Avatar
Cham M
Posts: 4324
Joined: 14.01.2004
Age: 60
With us: 20 years 9 months
Location: Montreal

Post #11by Cham » 04.02.2008, 11:22

... and what about the moons label ? Can they be in the same color as their orbit ? I'm not sure if it would be usefull, though.

EDIT : that jupiter moons script is definitely interesting...
"Well! I've often seen a cat without a grin", thought Alice; "but a grin without a cat! It's the most curious thing I ever saw in all my life!"

Topic author
chris
Site Admin
Posts: 4211
Joined: 28.01.2002
With us: 22 years 9 months
Location: Seattle, Washington, USA

Post #12by chris » 04.02.2008, 17:53

Cham wrote:... and what about the moons label ? Can they be in the same color as their orbit ? I'm not sure if it would be usefull, though.

EDIT : that jupiter moons script is definitely interesting...


I think it might be useful to be able to change label colors for highlighting. For instance, I think the Jovian moons scripts might be improved by having label colors that match the orbit colors.

--Chris

Topic author
chris
Site Admin
Posts: 4211
Joined: 28.01.2002
With us: 22 years 9 months
Location: Seattle, Washington, USA

Post #13by chris » 04.02.2008, 17:54

Cham wrote:Isn't there another option : OrbitVisible ?

EDIT : I tested the script. it works (and it's interesting !). But it's a bit slow. The orbit toggling appears to be jerky in some way : the orbits in a single group do not draw at once, some orbits are "late" when drawing themselves. Is this a normal behavior of the script ?

Hmm, using the keys (1, 2, ...6) repeatedly gives some odd things. Pressing "1" few times, and I got Mercury selected (the script was still working). Pressing "4" several times, and the script forgot Iocaste, until it reselected that moon.


The script should work instantaneously . . . I think that there may be some trouble with keyboard event handling in Lua.

--Chris

Guckytos
Posts: 439
Joined: 01.06.2004
With us: 20 years 5 months
Location: Germany

Post #14by Guckytos » 04.02.2008, 18:23

chris wrote:

Code: Select all

OrbitColor [ red green blue ]


...where red, green, and blue are floating point values between 0 and 1.



Nice idea, just 2 short remarks.

How long can/should the floating point values be, that are entered into the definition?
And wouldn't it perhaps be easier to use instead of the floating point integers values from 0-255? Easier in the way that a lot of programs give you color values in that coding?

Just my 2 cents.

Regards,

Guckytos

MKruer
Posts: 501
Joined: 18.09.2002
With us: 22 years 1 month

Post #15by MKruer » 04.02.2008, 18:30

chris,

Don't mean to disturb your developers thread. But I was wondering if another tag that should be added would be for a POV overlay for an object. This special class would be for a standardized way to render the interior of a planet, regardless of viewing angle or distance, See more information at http://celestiaproject.net/forum/viewtopic.php ... &start=180

Topic author
chris
Site Admin
Posts: 4211
Joined: 28.01.2002
With us: 22 years 9 months
Location: Seattle, Washington, USA

Post #16by chris » 04.02.2008, 18:42

Guckytos wrote:
chris wrote:

Code: Select all

OrbitColor [ red green blue ]


...where red, green, and blue are floating point values between 0 and 1.


Nice idea, just 2 short remarks.

How long can/should the floating point values be, that are entered into the definition?

Internally, colors are stored as 8-bit values, so no more than three digits of precision should be required.

And wouldn't it perhaps be easier to use instead of the floating point integers values from 0-255? Easier in the way that a lot of programs give you color values in that coding?


This is how colors are specified everywhere else in ssc files. While the orbit color is in fact stored as three 8-bit values, not all colors necessarily will be. More precision may be required to support high-dynamic range rendering--not necessarily for the orbit color, but for other colors. The floating point representation has the big advantage of being independent of whatever precision is used internally: 0.5 still means half brightness, whether we're using 8 or 16 bits per channel.

--Chris

Avatar
Cham M
Posts: 4324
Joined: 14.01.2004
Age: 60
With us: 20 years 9 months
Location: Montreal

Post #17by Cham » 04.02.2008, 18:47

Guckytos wrote:And wouldn't it perhaps be easier to use instead of the floating point integers values from 0-255? Easier in the way that a lot of programs give you color values in that coding?


floating point values are easy : 245 (from Photoshop, say) should be divided by 255, for Celestia. That's all there is to do.
"Well! I've often seen a cat without a grin", thought Alice; "but a grin without a cat! It's the most curious thing I ever saw in all my life!"

Topic author
chris
Site Admin
Posts: 4211
Joined: 28.01.2002
With us: 22 years 9 months
Location: Seattle, Washington, USA

Post #18by chris » 04.02.2008, 18:54

MKruer wrote:chris,

Don't mean to disturb your developers thread. But I was wondering if another tag that should be added would be for a POV overlay for an object. This special class would be for a standardized way to render the interior of a planet, regardless of viewing angle or distance, See more information at http://celestiaproject.net/forum/viewtopic.php ... &start=180


I'd rather keep this thread on the topic of the new orbit flags. But if you want to a discussion on how to render planetary interiors, go ahead and start a new topic in the Celestia Developers forum.

--Chris

Avatar
Cham M
Posts: 4324
Joined: 14.01.2004
Age: 60
With us: 20 years 9 months
Location: Montreal

Post #19by Cham » 04.02.2008, 20:35

Chris,

you didn't described the OrbitVisibility option (I'm not sure of the correct syntax). It's not obvious from the code (Oh, and is that a typo on lines 920 and 923 of body.cpp ? "NeverVisibile" and "AlwaysVisibile" ??).
"Well! I've often seen a cat without a grin", thought Alice; "but a grin without a cat! It's the most curious thing I ever saw in all my life!"

Topic author
chris
Site Admin
Posts: 4211
Joined: 28.01.2002
With us: 22 years 9 months
Location: Seattle, Washington, USA

Post #20by chris » 04.02.2008, 20:45

Cham wrote:Chris,

you didn't described the OrbitVisibility option (I'm not sure of the correct syntax). It's not obvious from the code (Oh, and is that a typo on lines 920 and 923 of body.cpp ? "NeverVisibile" and "AlwaysVisibile" ??).


OrbitVisibility is available only from script, not via the SSC file. I'm having second thoughts about this option. I'm adding more general orbit plotting features (with selectable reference frames and time windows). The OrbitVisibility flag could be though of as a special case, and may not be necessary at all.

--Chris


Return to “Ideas & News”