Celestia Forums

Forward: This is an open discussion on better ways to render planetary interiors; for potential integration on future versions of Celestia.

Before we begin, please read the original thread at http://celestiaproject.net/forum/viewtopic.php?t=10901

Current the way that planet interiors are created is via a 3d model with its own textures for the various layers. This has been successful, but there I think better ways of doing this.

My idea is for the creation of a new class of object specifically for planet interiors. The code would looks something like this

Example code:
[code]Interior ?€?EarthInterior.png?€

I'm not sure about your method. Another method could be to add an "alternate model" sub-menu, like we already have the alternate texture sub-menu (when we right-click on the planet). Selecting the model in that sub-menu could replace the default sphere with a model.

Cham wrote:I'm not sure about your method. Another method could be to add an "alternate model" sub-menu, like we already have the alternate texture sub-menu (when we right-click on the planet). Selecting the model in that sub-menu could replace the default sphere with a model.

I agree that something like this seems like a better idea. For one thing, it's a very general capability that's useful for much more than just planetary interiors.

--Chris

This brings me to a related idea I had last year : equatorial coordinates grid on the Earth (or any planet). The model sub-menu could be used to show a 3D ball around the Earth (spherical grid), without replacing the Earth itself. I'm not satisfied with the grid overlay texture, since it's becoming all blurry at short range. The model sub-menu could read an SSC file, with all options to replace the Earth with a model, or to add a grid model around it (I'm not sure of the way we could achieve this, though).

EDIT : And there may be a conflict with the texture sub-menu, which shouldn't be used while another model is selected from the model sub-menu !

I'd certainly make use of an "alternate model" menu for my Hale Telescope Addon. While the new Visible option can be used for this capability, it requires more work by the author of the Addon and is more cumbersome for the user.

I personally don't see any problem with the idea of using the "alternate surface texture" menu to apply different textures to these alternate models. I am assuming that the implementation of the SSC texture directives can be extended to substitute the other types of textures (emissive, specular & normalmap) and not only a model's diffuse surface texture as now.

The reason why i was recommending the overlay vs the model was because the overlay would not be affect by the model and visa versa. so from the user perspective you could have the plant still spinning in the background, and going on its merry way.

If you opted for the model, then I would recommend having default build in models with 1/8, 1/4 and 1/2 cross section. Those tend to be the ones that show up the most. or some built in way to render an incomplete sphere. We could take an onion approach to the model and render it on the fly. Code like this could be used to describe each layer.

[code]interior {
layer {
name ?€?Core?€

selden wrote:I'd certainly make use of an "alternate model" menu for my Hale Telescope Addon. While the new Visible option can be used for this capability, it requires more work by the author of the Addon and is more cumbersome for the user.

I personally don't see any problem with the idea of using the "alternate surface texture" menu to apply different textures to these alternate models. I am assuming that the implementation of the SSC texture directives can be extended to substitute the other types of textures (emissive, specular & normalmap) and not only a model's diffuse surface texture as now.

I could see the use of an "alternate texture", but an "alternate model" seems pretty slim. I suppose you could use it between low and high res models of ships, but I don't think a planet would be a good use or resources. I was trying to keep it simple with the overlay. I like the idea of adding it into the SSC structure as the seems the best place for it.

There's a problem with my model sub-menu idea : most of the time, the model that we would want to use has several parts : one non-emissive part (declared in some SSC file), and an emissive one (declared as a separate object in the same SSC file). How should we select both of them in a single mouse selection, in that sub-menu ?

Premise that I see this thread only now. This question is interesting because the only solution is the manual editing of the CMOD's emissive proprieties; and this latter operation seems behave diversely, as far as the rendering paths changes, when the values are between 0 and 1.

For the "onion approach" there is an incovenience. As long as the cross-sections made with boolean operations on the sphere's diameters have to be congruent in values with the object's feature, if in the 3d modeller's scale all work fine, the things stands diversely when that values are assigned as .ssc's radius to the cross-sected meshes; the cross-sections toward the core tends to "lower" themselves, and the blinks or flicks does appear.

Fenerit,

there's a very simple solution to the problem you described, within the modeler itself. First : **don't use the boolean functions**. Run away from them as if they were infected with the plague ! They simply sucks in most modelers and may introduce many defects to your models. I'll try to show how I make my models, later today. Scale isn't a problem either.

Fenerit, see the message I posted in the planet's interior forum, for a small tutorial on how I make my models, without the boolean functions :

http://www.celestiaproject.net/forum/viewtopic ... &start=195

Playing a bit with celx code, stimulated by Imy and others about how to place these addons side by side in the SS without affect the common use, I've adopted the toggleearhtvisibility Vincent's example to hide the planetary interiors inside the current planets, and it seem work quite well. For this type of addons the "layer" event - as stated here:

http://shatters.net/forum/viewtopic.php?f=9&t=12702

doesn't seem suitable (as long as it involve addons which are "above" and not "beneath" a planet, since the very planet would interfere with the cross-section); moreover, at least for Celestia 1.5.0, I obtain also an error concerning the setvisible propriety just at start, with the result of crashing Celestia.

The steps that I've followed in the case of Mars are below, but they are relatively the same for the rest of the planets:

- renamed the .stc file as .stc.bak, in order to unload the external system;

- substituted "Mars' Interior" "Sol" as first string in mars_interior.ssc, the rest of the data must be the same of the SS' planets;

- changed the Mars' Interior radius in 3395 instead of 3396 (no flicks visible, otherwise change it in 3394.8; the shape's jump is neglegible);

- renamed mars.png as mars.png.bak in the relevant addons' ..\texturs\medres folder since it essentially doesn't need at all;

- added the following lines to the start.celx (or add it in a separate script):



Thus, my problem now is to find a function which can assign the normal status to a planet when one press any other key, because when one stay in "interior mode" and surf across the universe for then come back to the planet, the Celestia's camera run inside the interior in search for the very planet which have now a small radius due to the function. I'm not have idea how to make such a function.

Mind how in the case of Io, one should toggle even the volcanic addons (plume and sprite) because some calderae are in front of the cross-section (not too invasive, indeed).

If someone has already experienced some solutions...

selden wrote:I'd certainly make use of an "alternate model" menu for my Hale Telescope Addon. While the new Visible option can be used for this capability, it requires more work by the author of the Addon and is more cumbersome for the user.

I personally don't see any problem with the idea of using the "alternate surface texture" menu to apply different textures to these alternate models. I am assuming that the implementation of the SSC texture directives can be extended to substitute the other types of textures (emissive, specular & normalmap) and not only a model's diffuse surface texture as now.

An alternate appearance for objects where modmakers can change all parameters for all characteristics would be very handy seems to me.

This code cycle with just one keys' combination through interior-not interior, the .ssc's interior radius now can be the same and no .stc is required. The code is rough and unelegant but work.



As explained in the previous post, be sure of not to be in "interior" mode before press the 1 - 9 planet's number key and go!

Because one could to wish the interiors just in the point of him location, and a good center is at gotolonglat {time 3.0 distance 6.0 longitude -42.00 latitude 35.00} one either edit the Orientation directive in the .ssc (this made me fool, I'm unable to match the forementioned values) or insert further strings in the code.

Just to recall for customizations, one can edit the binary CMOD model by convert it in ASCII with the 3DStoCMOD converter. Open the original CMOD binary file and rename it as you wish (not the extension), then check the "Fix" radiobutton as well as the "Output as Ascii". Once converted, one can manually edit the values (i.e, some specific emissivity) for then re-convert it in binary again.

As far as I'm concerned with programming, this code escape from interior mode whenever but ctrl-i keys is pressed. The code is the same with the exception of the lines added in handlekey(k)'s function. Now the problem of "go inside" is avoided.