New object flags

[chris]

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

[Cham]

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.

[chris]

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

[Cham]

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 ?

[chris]

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

[Cham]

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.

[ajtribick]

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.

[Cham]

Chris,

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

[chris]

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

[Cham]

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.

[Cham]

... 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...

[chris]

... 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

[chris]

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]

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]

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

[chris]

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

[Cham]

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.

[chris]

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

[Cham]

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" ??).

[chris]

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