Stars, planets and point sprites

[Fenerit]

As different experiment I've "hotted" the exo-planet TYC-3727-1064 (XO-3) with rotating randomized point sprites:



Naturally, the parameters are casual, in the sense that I don't know how this planet can be similar to brown dwarf, but surely someone of yours know what that can be the optimal. The video below show the animation:

http://fenerit.webng.com/album/Celestia/xo3_test.avi 1.41Mb 720x480 1.19 min Xvid

The texture can be improved with more appropriate protuberance-like or brilliament-like shape, of course. Now my problem is how to do for applying this effect at one star, to say, Antares, because an orbital parameter is required before to set the UniformRotation, otherwise nothing happen. Even though in my attempts I had to be choosed a star without OrbitBarycenter and I had to be tried ReferenceFrame, BodyFixed and OrbitFrame, they seems doesn't works. Not only, but with orbit data took from planets, altought with neglegible SemiMajorAxis, the result does show a strange effect (depth-sort problem?). Thus, if someone know how to do...

The add-on with which I've made the video is here:

http://fenerit.webng.com/files/xo3_test.zip

[Fightspit]

Wow (not World Of Warcraft ), it is pretty cool

[danielj]

I tested it,put in Extras of Celestia 1.5.1,but the effect wasn?t the same.I don?t know why...
See the pictures below

[Fenerit]

danielj, me too, don't know why this happen on your computer. I've noted that in 1.5.0 release the point sprites desappeared when one did bookmarked the exo-planet, for then reappear when date was setted in real time. The new Celestia's patch avoid this behaviour even with old bookmark date. I do not think this is your case, so I'm waiting for others with the same problem. Not only, often the point sprites desappear when one right toggle the planet until it returns in front of the star, meanwhile when one go to the planet from every place in the space, the point sprites there are. Nevertheless, in front of the star they MUST BE!

[BobHegwood]

Massimo,

Sorry, but I don't understand what the problem is here. I installed your package under my Celestia\extras\Stars directory
and it works beautifully on my Celestia 1.5.1 system.

The planet is properly "hotted" and the atmosphere moves around it regularly. What am I missing?

Thanks, Bob

EDIT:
I do see the flares going around the planet too, but if I select one and go to it, I do not see a specific image. Is this important?

[Fenerit]

Massimo,

Sorry, but I don't understand what the problem is here. I installed your package under my Celestia\extras\Stars directory
and it works beautifully on my Celestia 1.5.1 system.

The planet is properly "hotted" and the atmosphere moves around it regularly. What am I missing?

Thanks, Bob

Thanks for the feedback, Bob. Surely it's not scientifically accurate but I love to think that something in the universe may be so red (just FYI, it's my dream vision of a neutron star... ). For what concern danielj seem that he has a few problems with point sprites nor directly related with this add-on (seems that they slow down the performances of it's computer).

[Fenerit]

EDIT:
I do see the flares going around the planet too, but if I select one and go to it, I do not see a specific image. Is this important?

Sorry, I see this just now.
No, indeed; because if you select the flares from the menu or from "enter > name_of_the_flare", you select a group of 16 points sprites altogether and the camera goto the their virtual centers, where there isn't nothing. Hope of having understood your question.

[BobHegwood]

Sorry, I see this just now.
No, indeed; because if you select the flares from the menu or from "enter > name_of_the_flare", you select a group of 16 points sprites altogether and the camera goto the their virtual centers, where there isn't nothing. Hope of having understood your question.

Okay, in that case then, there is nothing wrong with this add-on. It works beautifully on my system.
Thanks very much for this addition. I like it very much.

[Fenerit]

Hi there, just to warming once more this "poor boy" XO3 planet, I've add the chromosphere's crispation.



The video is here (about 1 min, 720 x 576 Xvid, 2.3 Mb):

http://fenerit.webng.com/album/Celestia/crisp.avi

Note: in order to display this faintest effect against the compressor's degradation processing, the CMOD's opacity has been set to 0.5, but a value of 0.3 / 0.35 is better and the diffuse color must be the same of the lower atmosphere; meanwhile the crisps' height can be reduced by changing the .SSC's crisp model radius value. Moreover, one can multiply the SSC's instances of the crisp model with different Inclination(s) and Meridianangle(s) for more crispes. However, be caution with the radius, because the 3ds' limitation in polys has costrained the hollow (the shelling operation on the furred sphere for reducing polys) close to the border, hence highest radius'values will displace the model out of
the planet.
Once one has played a bit with the model's values, I suggest to convert it in binary for smaller file size and quick loading.

Crisp CMOD model and the crisp.ssc are here (nothing else is required in addition except the above XO3 add-on):

http://fenerit.webng.com/files/crisp.zip

Extract the crisp.ssc in the main ..\XO3_test\ folder and crisp.cmod in the relevant XO3_test\models\ folder. If you have changed the atmospheric values, simply assign to the CMOD model's diffuse color the your personal lower atmosphere color values, as well as - IMHO - an opacity of 0.3. Suggested, optimal radius, are commented in the crisp.ssc.

I think that all these solutions will be obsolete when the new particle system engine will be embedded; in particular the point sprites, which are very CPU intensive when moved. Their use is purely static, indeed.

EDIT LATER:
Being CMOD and OBJ files pretty similar, does an OBJtoCMOD converter could be made to avoid the 3ds limit or...?

[BobHegwood]

Fenerit,

Thanks again for this add-on.
The revision makes for a rather more interesting (and properly "hotted") planet.

Dunno if it means anything to you or not, but I converted the ASCII CMOD to the binary format,
and saved approximately 4MB with the use of the binary model. Still a very interesting conjecture
on what a planet this close to its star might look like.

Thanks again, Bob

[Fenerit]

Fenerit,

Thanks again for this add-on.
The revision makes for a rather more interesting (and properly "hotted") planet.

Dunno if it means anything to you or not, but I converted the ASCII CMOD to the binary format,
and saved approximately 4MB with the use of the binary model. Still a very interesting conjecture
on what a planet this close to its star might look like.

Thanks again, Bob

Tx for the feedbacks, Bob. Indeed, binary is best. Anyhow, all these effects are truly thought with the stars in mind: this planet is just a "place" in which apply it. Unfortunately. I've problem with point sprites on stars. They shows a strange "fish eye blob" at poles when the camera is parallel to the axis, while it desappear and all work fine when the camera is ortogonal and depend on radius: more is great more that effect is accentuate.

[Fenerit]

Hi! I resume this thread as consequence of a private discussion amongst me and Michael (MiR) concerning the way in which exoplanets can be "warmed" through the point sprites' method. Stimulated by Cham's point sprites based nebulae and after the Michael's request of refining the prototype above, the discussion dealt with how spheric shells of point sprites encompassing the planets could be achieve the purpose. He was in search of a method to warm its 51Pegasi b, so I've developed this:

51Pegasi hot (88 kb)

so that all the sussequent discussion, if any, will be treated here.

P.S.
Michael, try the sprites without the Mie parameters: they looks best.

[MiR]

wow, Massimo... looks great. very well done!

Bildschirm008.jpg

Bildschirm007.jpg

Bildschirm006.jpg

this technique should be a standard part of Celestia...

Thanks a lot, it's a good work and a good idea, too
Michael

[Fenerit]

I'm happy you like the "warmth". Of course I'm absolutely unaware about what should be its color, so I've arbitrary supposed lighten on high strata (white-yellow, first sprite, more radius, high speed) and darken on low strata (yellow-maroon, second sprite, lesser radius, low speed).

HOW TO CUSTOMIZE THE SPRITES:

If one take a look inside the CMODs he will see that the "blend add" propriety is disabled. If enabled, the sprites will appears like black squares on screen. Even if the "opacity" is set lesser than 1, the black squares will be shown. In order to avoid such behavior, if one KNOWS which colors be assigned to the sprites and WANT lesser opacity for the points, he must do so:

1) open the CMODs within a good text editor (for "a good text editor" I mean an editor in which there is a tabular columns insertion; Notepad++ does that); he will see something like this:

#celmodel__ascii

material
diffuse 0.5 0.45 0.35
opacity 1
texture0 "blob.png"
#blend add
end_material

mesh
vertexdesc
position f3
pointsize f1
end_vertexdesc

vertices 2700
0.327129 -0.723509 -0.607882 0.05
0.585920 -0.673630 0.450466 0.05
-0.088855 0.577892 -0.811261 0.05
....

in which the white color of the "blob.png" image borrow the "diffuse" color.

2) disable the string: "diffuse" (add the sign "#" before);
3) enable the string: "blend add" (remove the sign "#");
4) after "pointsize f1", which is the last row numbers on right side (0.05), add the string: "color0 f4"
5) cut & paste within a new document all the remains parts after the last row of point at the BOTTOM

...
-0.782988 0.278220 0.556348 0.05
-0.237384 0.856517 -0.458288 0.05
0.434608 0.093929 -0.895708 0.05

sprites 0 2700
0
1
2
3
4
5
6
.
.
.
end_mesh

(from "sprites ...." to "end_mesh" included, must be cut & paste within a new document)

6) posit the text editor's cursor on the right side of first row of points (after 0.05) and press TAB a couple of times. This avoid possibly mixing amongst the new insertion and the preexistent ones);
7) start the columns editor of Notepad++ (ALT+C) or similar program, type in there your RGBA values and press OK. The new values will be inserted like columns, toward the end of document;
(8) take up from the new open document the data previously pasted, and append it within the main document (in short, rebuild its structure). Save, start Celestia and take a look.
If one is unsatisfied about sprites' opacity, now it can be set-on like he want.

[Cham]

In the near future, I may try building some protuberence and mass dejection sprite based models. I already made some magnetic field models for the sun in the past, so it should be easy to dress them with sprites to blur the field lines and get something like this :

sol.jpg

Unfortunately, the model will be static only (no motion).

[Fenerit]

That's a good idea. BTW, after a bunch of experiments, the most sensible part for sprites' performance is the pointsize propriety. The lesser is the pointsize the better are the performances, even with thousands of points.

[MiR]

Thank you for your little tutorial about "customizing the sprites", I've saved this page for to "play" later with those parameters.
Currently I'm very satisfied with the heat-performance for Pegasi/b you've made.

On the other hand; I'm a-little surprised about the low response. I'm really fascinated by this point-sprites-technique. Now we have an option to show nebulae, solar-corona and other cosmic events closer to reality. And hardly any one takes notice of it ... But eventually I see it a bit too unilaterally and subtile...

Michael

[Fenerit]

Thank you for your little tutorial about "customizing the sprites", I've saved this page for to "play" later with those parameters.
Currently I'm very satisfied with the heat-performance for Pegasi/b you've made.

On the other hand; I'm a-little surprised about the low response. I'm really fascinated by this point-sprites-technique. Now we have an option to show nebulae, solar-corona and other cosmic events closer to reality. And hardly any one takes notice of it ... But eventually I see it a bit too unilaterally and subtile...

Michael

To avoid "low response" when the sprites are animated, it is important to lower as much as possible the pointsize attribute. I've never tried before, but with a pointsize of 0.0000000000001 I wonder how many the point sprites technique be different, in terms of performances, respect to a particle system.

[MiR]

Massimo, with "low response" I meant the lack of interest in "point sprites" by our community
Michael

[Fenerit]

Massimo, with "low response" I meant the lack of interest in "point sprites" by our community
Michael

Ah, ok.

Maybe because vertex points or point clouds meshes are not so easy to handle. I do not know whether free 3D modelers like Anim8tor or Blender can manage the point clouds. The most easy way to get points with 3D modelers which doesn't handle them, is to export a mesh as .OBJ file without normals and textures and then do remove faces within a text editor; that is, by deleting all the faces' strings and to hold just the vertex. Its main problem is that points' distribution does resemble the meshes' shape; there isn't enough "randomization" into such a method. The basic meshes must be "randomized" for themselves, before to do that. Preliminary "chaotic" sculpting of the meshes can help. I use Perl scripts to handle points from OBJ, and for OBJ to CMOD conversion as well.