New object class: diffuse

[chris]

Cham reported a bug with the new planetshine code that I think is best resolved by introducing a new object class. The problem occurs in add-ons with objects like accretion disks and dust clouds. Celestia has no way to tell that these things aren't really planets, and thus tries to compute the effect of planetshine from them. Since these objects tend to be extremely large and surround stars and other planets, the simplified lighting calculations that Celestia uses for planetshine will not work for them. Thus, I propose a new object class called 'diffuse' for accretion disks, dust clouds, volcanic and geyser plumes, etc.

In order to run in real-time, Celestia has to use simplified equations that work well for physically plausible solar systems, but not necessarily for an arbitrary arrangement of geometry. Celestia isn't expecting to see 'planets' that are several AU across and intersecting other planets. The diffuse object class would give add-on creators a way to tell Celestia that these big clouds aren't in fact planets and that they should be disregarded when computing planetshine (and probably also for shadowing, when shadows for non-ellipsoidal objects are implemented.)

--Chris

[Cham]

Just to tell everybody that I agree totally with this proposition !

Can we agree that a magnetic field is also a "diffuse" object ?

[buggs_moran]

Sounds good but should you use a different word? Or even, perhaps a boolean since we may have other objects that are not "diffuse" that we may not want to receive planetshine. For instance adding a boolean to the ssc like,

Planetshine True

or something always false so we aren't changing every object in every ssc.

NoPlanetshine True

I would think specularity and diffusion are material properties more than whole object properties. And since one cmod can contain many "materials" you might want some of those parts to receive the planetshine and some not. In a cmod I have the option to turn down/off specularity, thereby making a part more reflectively diffuse... I could be getting this all wrong though...

[chris]

Sounds good but should you use a different word? Or even, perhaps a boolean since we may have other objects that are not "diffuse" that we may not want to receive planetshine. For instance adding a boolean to the ssc like,

Planetshine True

or something always false so we aren't changing every object in every ssc.

NoPlanetshine True

I would think specularity and diffusion are material properties more than whole object properties. And since one cmod can contain many "materials" you might want some of those parts to receive the planetshine and some not. In a cmod I have the option to turn down/off specularity, thereby making a part more reflectively diffuse... I could be getting this all wrong though...

Regarding the name confusion: I was using the word diffuse to refer not to diffuse (i.e. non view dependent) lighting, but rather to a state of matter: gaseous and spread out. That confusion is an argument against using diffuse as the name for the new object classification. Perhaps 'gaseous'? Personally, I still favor diffuse.

Planetshine could still be a separate property; setting the class to diffuse just affects the default value of the property. There's precedent for this already: invisible objects aren't clickable by default, component and surface feature aren't visible as point by default, etc. Here's the table, including the proposed diffuse class:

Code: Select all

               Planet  Moon  Spacecraft  Component  Invisible  Diffuse
Visible         yes     Yes    Yes         Yes        No         Yes
VisibleAsPoint  yes     Yes    Yes         No         No         No
Clickable       yes     Yes    Yes         Yes        No         No(?)
Planetshine     yes     Yes    No          No         No         No


The idea of these object class defaults is to free add-on creators from having to think about the different flags. The add-on author chooses the class that matches the type of object they're creating and doesn't need to understand what 'VisibleAsPoint' means. But, experienced authors could still override the default if they saw need to.

To slightly simplify the use of classes, we could even add some new SSC syntax that would allow definitions like this:

Code: Select all

"Solar Panel" "Sol/Earth/ISS"
{
    Class "component"
    Mesh "panel.cmod"
    ...
}


to be written as:

Code: Select all

Component "Solar Panel" "Sol/Earth/ISS"
{
    Mesh "panel.cmod"
    ...
}


This is consistent with how ReferencePoint works now, and is also more in line with dsc file syntax.

--Chris

[Chuft-Captain]

Chris,

As you're discussing new Classes and Properties here, is it still your intention to extend the Clickable property to add the ClickTranslucent behaviour discussed a while ago.
The Clickable property would need to be ternary valued rather than binary (true,false).

CC

[buggs_moran]

Diffuse as in gaseous makes perfect sense...

[duds26]

Will nebulae and nebulae billboards also be diffuse?

[chris]

Will nebulae and nebulae billboards also be diffuse?

This change isn't relevant for nebula; it only affects ssc objects.

--Chris

[duds26]

OK

Mayby dusty is a good name because of the confusion that might occur with diffuse.

[happywoman50]

duds26 said
Mayby dusty is a good name because of the confusion that might occur with diffuse.

I think there is a sense to use the name “dusty” for the new object class.