New SSC object classes and property

[chris]

There's been some discussion on the Celestia developers mailing list about introducing new object classes for SSC objects as well as some new properties.

Starting with the easy things . . . Cham has been requesting for some time the addition of a Clickable field for objects (for stars and deep sky objects as well as for solar system objects.) By default, this field is set to true: when a user clicks on the object, it will be selected. Setting Clickable to false will disable selection by clicking. The object would still be selectable through the Solar System browser and Find Object dialogs.

It can also be desirable to prevent objects from appearing in the Solar System browser. Selden mentioned complaints that his Hale add-on introduced so many Earth-orbiting objects into the Solar System browser that it became difficult to find any object other than a Hale component. One proposal for working around this is the addition of a 'Browsable' property: set it to false, and the object won't appear in the browser. I personally prefer a different approach: adding new object classes, and grouping objects in the browser by class.

One new object type might be "surfacefeature"; another useful one might be "component", for parts of a spacecraft or building. The new classes address several problems at once:

- There's no sensible way to tag an object like an volcanic or ground-based observatory (to pick two recent examples) right now. The two common choices are spacecraft and asteroid, neither of which are appropriate.

- It would be convenient to have objects distinguished by type in the solar system browser. As it is now, it's confusing to have the moon appear together with spacecraft and surface features in the list of child objects for the Earth.

- When moons, spacecraft, and asteroids occupy less than a pixel on screen, they're rendered as points of light, mimicking what we see in the sky. However, this behavior isn't appropriate for buildings and other surface features. Distinguishing them by specifying Class "surfacefeature" would let Celestia disable it.

What I'd like feedback on is:
- Does my description of the Clickable property match your own idea of how it should work? If not, what should be different?

- Would the new object classes and browser grouping solve the confusing mess of objects that you can see in the Solar System browser after installing add-ons?

- What do you think of the class names? Are there others that would be useful?

--Chris

[selden]

Clickability:
I think that if an object is not clickable, then it should allow "click-through"; that is to say, an object behind or inside the non-clickable object could be selected.

If the non-clickable object's Mesh is translucent, these other objects would be visible, but if it's opaque, they wouldn't be visible, which could be a confusion factor.

Questions regarding the suggested classes:

Could nested surfacefeatures or components be shown properly nested in the browsers? Building in City, for example, or Bird in Cage in Building in Zoo in City?

It does seem to me that surfacefeature and component are essentially synonymous so far as Celestia is concerned, although of course, they are likely to mean something different to a person. Might a more generic term for both be reasonable?

[ElChristou]

What about a class that could be used for the convenience of an addon but that should not appear in the browser or in the intern tree nor being clickable?

[ajtribick]

Barycentres should default to Clickable False... it's slightly disconcerting being able to click on a region of empty space and selecting the barycentre... even more disconcerting when the barycentre is in front of a visible object!

[BobHegwood]

For what it's worth, I really like the idea of using a "SurfaceFeature"
element. In fact, that's how my extras folder is classified now. I have
a "Spacecraft" folder, an "Asteroids" folder, as well as my very own
"SurfaceFeatures" folder for use with ungainly add-ons. In each of
these folders, I have separate models and textures folders too, so
that they are all related to the sub-category of my choosing.

I generally don't try to explain this setup to newbies, but that's how
I actually maintain various add-ons in the same version of Celestia.

Works for me.

[LordFerret]

For what it's worth, I really like the idea of using a "SurfaceFeature"
element. In fact, that's how my extras folder is classified now. I have
a "Spacecraft" folder, an "Asteroids" folder, as well as my very own
"SurfaceFeatures" folder for use with ungainly add-ons. In each of
these folders, I have separate models and textures folders too, so
that they are all related to the sub-category of my choosing.

I generally don't try to explain this setup to newbies, but that's how
I actually maintain various add-ons in the same version of Celestia.

Works for me.

That was a suggestion Selden gave to me (via his documentation) which has worked very well. I find using Windows Explorer to be easy and convenient, enabling me to click and drag addon folders in or out of my Extras tree. It would be nice however if one day Celestia could handle addons dynamically, without having to exit and restart Celestia each time addons are desired to be added or removed.

While not a developer, I do like the idea of these new classes, particularly in that they'll help eliminate the clutter in the browse function. It would be nice to see "parent" objects in the list, with the ability to either click on the parent or hover over it to bring up its associated "child" components. If such a thing is not possible currently, it would still be nice to see parents with their child components listed hierarchically beneath them in the list - and perhaps indented as well.

[Chuft-Captain]

Here are my suggestions:


PROPERTIES
1. Browse (true,false)
- determines whether the object appears in the Solar System browser.
2. Select (true, false)
- determines whether it appears in the ENTER-select
3. Click (opaque, transparent, transluscent)
- determines how a mouse-click interacts with the object
4. Visible (true,false)
- determines if object is visible
5. Label (true, false)
- determines if a label will be displayed when labels are enabled.

Some further explanation of the Click values is probably required...

opaque - a mouse-click will select the object.
transparent - a mouse-click will never select it.
transluscent - - a mouse-click will select the object only if there is no other "click-opaque" object located at the cursor position, either inside or behind the click-translucent object (or outside it, if the observer is inside the mesh), otherwise the opaque object will be selected in preference. (Equivalent to Selden's "click-through" I believe)

The most likely application of the click-translucent property is to allow spacecraft windows to be clicked-through.



CLASSES:
The classes implement some default combinations of these properties.
It is IMO very important for flexibility and creative freedom, that addon creators should be able to override the default property values for most, if not all of these classes. I think that the default values I suggest below would sufficiently lessen the clutter as long as addon creators make use of appropriate classes in the first place.

Class "Placeholder" (replaces "Invisible")
Rename the class "Invisible" to "Placeholder" (I've never liked the use of the name "Invisible" for a class (it should be a property in my mind, not a class ).
Placeholders are created for purely technical reasons eg. For placement of other object, but not required to be "known" to the user.
Of course Class "Invisible" declarations in existing SSC's would still be recognised (and the default properties of a placeholder would be assumed for these).
Default property values:

Code: Select all

Browse:  false
Select:  false
Click:   transparent
Visible: false
Label:   false

Class "Planet", Class "Moon", Class "Asteroid", Class "Spacecraft"
- No change to these
Default property values:

Code: Select all

Browse:  true
Select:  true
Click:   opaque
Visible: true
Label:   true

Class "Place" ** NEW **
These are effectively placeholders which have greater importance or usage, or which the addon creator wants to be made available to the user.
They are still invisible, and "Click-transparent", but will appear in browse and select menus. (A good example is Lagrange or Trojan points, or the central placeholder for a spacecraft model composed of several components)
Default property values:

Code: Select all

Browse:  true
Select:  true
Click:   transparent
Visible: false
Label:   true

Class "Component" ** NEW **
These are objects which are used to construct Spacecraft. They would generally create too much clutter if browsable or selectable.
Default property values:

Code: Select all

Browse:  false
Select:  false
Click:   opaque
Visible: true
Label:   false

EDIT: Perhaps "Click: transparent" would be a more appropriate default for the Component class, but an addon creator might override this default to allow the user to click on certain components in order to go in for a closer look.

If the non-clickable object's Mesh is translucent, these other objects would be visible, but if it's opaque, they wouldn't be visible, which could be a confusion factor.

IMO, the use of this property value does not need be limited to "visible-light translucent" objects.
(ie. It might be nice to allow the creation of addon "easter eggs" )

I personally prefer a different approach: adding new object classes, and grouping objects in the browser by class....
....It would be convenient to have objects distinguished by type in the solar system browser.

I think this is a good idea...perhaps some check-boxes could be added to the SS-browser to enable/disable the display of certain classes, Although I do believe that the hierachical structure should remain (as this is the only place where it can be seen and is a useful verification of the SSC code).

When moons, spacecraft, and asteroids occupy less than a pixel on screen, they're rendered as points of light, mimicking what we see in the sky. However, this behavior isn't appropriate for buildings and other surface features. Distinguishing them by specifying Class "surfacefeature" would let Celestia disable it.

I have had this discussion with dirkpitt, and I agree with you. However, from my experience, it does seem that the onset of this behaviour begins in a gradual way, somewhat before they get as small as a single pixel.

[ajtribick]

It would be nice if classes could be applied to ReferencePoint objects to specify whether their orbits get drawn... at the moment objects such as Pluto-Charon only get their orbits drawn when they are selected.

Could there be a class for dwarf planets added?

(Perhaps less important might be classes to distinguish major planetary satellites from minor ones, though perhaps the asteroid class might be useful for doing that)

[Chuft-Captain]

Class "Location" ** NEW **
These are effectively placeholders which have greater importance or usage, or which the addon creator wants to be made available to the user.
They are still invisible, and "Click-transparent", but will appear in browse and select menus. (A good example is Lagrange or Trojan points, or the central placeholder for a spacecraft model composed of several components)
Default property values:

Code: Select all

Browse:  true
Select:  true
Click:   transparent
Visible: false
Label:   true

I forgot that Celestia already has Location's, so to avoid confusion with these in any discussion that occurs, I will rename my proposed new class to something else. (Let's just call it a "Place" for the purpose of discussion)

** EDITED previous post **

[chris]

It would be nice if classes could be applied to ReferencePoint objects to specify whether their orbits get drawn... at the moment objects such as Pluto-Charon only get their orbits drawn when they are selected.

Could there be a class for dwarf planets added?

(Perhaps less important might be classes to distinguish major planetary satellites from minor ones, though perhaps the asteroid class might be useful for doing that)

Something definitely needs to be done about the clutter of all the minor moon orbits around the outer planets. A minormoon class could do the trick. Another idea is to use a features proposed by Cham that he calls custom classes and I call groups.

Groups can be assigned in one of two ways: 1) inside the object definition a with list of groups that the object is a member of, and 2) a separate group definition with a list of objects.

Inside the object definition:

Code: Select all

"Praxidike" "Sol/Jupiter"
{
    Class "moon"
    Groups [ "Ananke Group Moons" ]
}


Group definition:

Code: Select all

Group "Ananke Group Moons"
{
    InfoURL "http://en.wikipedia.org/wiki/Ananke_group"
    Objects [
        "Sol/Jupiter/Ananke"
        "Sol/Jupiter/Praxidike"
        "Sol/Jupiter/Thyone"
        ...
    ]
}


There's no consensus yet on how to make groups visible in the UI (though it should be possible to label, show orbits, and mark all objects in a group), or even on the details of how they should be specified in SSC files. But, a Minor Moons group could solve the problem.

There's potential for overlap between classes and categories. Since classes are built-in to Celestia, they can affect how objects are rendered, for example comet tails for objects of class comet, and the elimination of star-like rendering for objects of the proposed class surfacefeature. There's no such distinction between planets, moons, and asteroids, but these classes are fundamental enough that it seems appropriate maintain them.

Now after writing this tangent, I feel that minormoon should be a class not a user-defined group. We want the clutter of outer planet moon orbits gone, so we need some way to identify them as distinct from more significant moons. The asteroid class works, but it's a little unconventional to apply that label to objects in orbit around planets. Making it a group leaves the problem of how to disable the orbits. I envision operations on groups like 'Show Orbits' working by setting an 'always show orbit' bit for all objects in the group, with no corresponding bit to always hide the orbit.

--Chris

[Chuft-Captain]

Something definitely needs to be done about the clutter of all the minor moon orbits around the outer planets. A minormoon class could do the trick. Another idea is to use a features proposed by Cham that he calls custom classes and I call groups.

Groups can be assigned in one of two ways: 1) inside the object definition a with list of groups that the object is a member of, and 2) a separate group definition with a list of objects.

Inside the object definition:

Code: Select all

"Praxidike" "Sol/Jupiter"
{
    Class "moon"
    Groups [ "Ananke Group Moons" ]
}


Group definition:

Code: Select all

Group "Ananke Group Moons"
{
    InfoURL "http://en.wikipedia.org/wiki/Ananke_group"
    Objects [
        "Sol/Jupiter/Ananke"
        "Sol/Jupiter/Praxidike"
        "Sol/Jupiter/Thyone"
        ...
    ]
}


There's no consensus yet on how to make groups visible in the UI (though it should be possible to label, show orbits, and mark all objects in a group), or even on the details of how they should be specified in SSC files. But, a Minor Moons group could solve the problem.

There's potential for overlap between classes and categories. Since classes are built-in to Celestia, they can affect how objects are rendered, for example comet tails for objects of class comet, and the elimination of star-like rendering for objects of the proposed class surfacefeature. There's no such distinction between planets, moons, and asteroids, but these classes are fundamental enough that it seems appropriate maintain them.

Now after writing this tangent, I feel that minormoon should be a class not a user-defined group. We want the clutter of outer planet moon orbits gone, so we need some way to identify them as distinct from more significant moons. The asteroid class works, but it's a little unconventional to apply that label to objects in orbit around planets. Making it a group leaves the problem of how to disable the orbits. I envision operations on groups like 'Show Orbits' working by setting an 'always show orbit' bit for all objects in the group, with no corresponding bit to always hide the orbit.

--Chris

What about treating them as sub-classes,...?
ie. Allow the definition of display/click properties to the Custom-Groups in the Group definition, so that when specified it overrides the default behaviour of the parent class, ...and do the actual assignment of objects to groups inside the object definition.
(Perhaps the **NEW** classes I suggested above should actually be defined as Custom-Classes/Groups???).
This approach would I guess require that the parsing of Group definition(s) happens prior to the parsing of the object definitions.

eg1.

Code: Select all

Group "Ananke Group Moons"
{
    Class "Moon"
    InfoURL "http://en.wikipedia.org/wiki/Ananke_group"
   
    Browse=true
    Select=true
    Click=opaque
    Visible=true
    Label=true
    DisplayOrbit=false
}

"Praxidike" "Sol/Jupiter"
{
    Class "Ananke Group Moons"
}


eg2.

Code: Select all

Group "Place"
{
    Class "Invisible"
    InfoURL "http://en.wikipedia.org/wiki/Ananke_group"
   
    Browse=true
    Select=true
    Click=transparent
    Visible=false
    Label=true
    DisplayOrbit=true
}

"Moon-L2" "Sol/Earth/Moon"
{
    Class "Place"
}

eg3.

Code: Select all

Group "Component"
{
    Class "Spacecraft"
    InfoURL "http://en.wikipedia.org/wiki/Ananke_group"
   
    Browse=false
    Select=false
    Click=opaque
    Visible=true
    Label=false
    DisplayOrbit=false
}

"ISS-Solar-Panel" "Sol/Earth/ISS"
{
    Class "Component"
}



[BobHegwood]

Here are my suggestions:


PROPERTIES
1. Browse (true,false)
- determines whether the object appears in the Solar System browser.
2. Select (true, false)
- determines whether it appears in the ENTER-select
3. Click (opaque, transparent, transluscent)
- determines how a mouse-click interacts with the object
4. Visible (true,false)
- determines if object is visible
5. Label (true, false)
- determines if a label will be displayed when labels are enabled.

Methinks that this area needs to be a priority now that add-ons
like Selden's Hale Telescope and Runar's Buran simply obfuscate any
rational exploration of space when trying to use the right-click
planetary object menus.

Many, MANY unnecessary entries for various sub-structures and
individual pieces of these add-ons. Chuft-Captain's suggestions
here would eliminate this confusion and simplify life for everyone.

Just my Brain-Dead opinion...

[Fenerit]

It could be interesting if the visible propriety might applied to the model's .ssc in a manner in which a main .ssc specify the subparts of a complex object as is:

Group "My object group"

{

Objects [

"My_star/My_Planet/My Object part 1"

"My_star/My_Planet/My Object part 2"

"My_star/My_Planet/My Object part 3"

...
]
}

and then in each one specified .ssc be assigned the propriety Visible; so that, when this latter is setting to "false", each subpart will be invisible, but the "place" in which the main group is will be yet clickable. At this point should useful that the right click operation (or shortcut key) shows all the pieces unchecked (because visible = false) but when one piece is checked then the visible = true. In this manner it's possible build "modules" of add-ons and visualize it either altogether or single. Hope of not have been gone out of topic.

[Fenerit]

Perhaps should be:

Group "My object group"

{

Objects [

"My_star/My_Planet/My Object part 1"

Visible=false(or true, no matter)

"My_star/My_Planet/My Object part 2"

Visible=false

"My_star/My_Planet/My Object part 3"

Visible=false

...
]
}

And the group definition act, to say, as the Windows'.ini files does, where the "false" or "true" are changed by internal operations of checking (no matter which parts the users are need to shows, and which order).