New Celestia-1.4.0pre-FT1.1 Version for Download

[Malenfant]

Well if Toti's tool is a bit unpredictable then maybe we should consider the option of coming up with or using a different tool to get similar (but better/more controllable) results?

I don't know what such a tool would be, but it might be worth looking into.

[hank]

Given this fact, how might an interactive blob editor work? Anyone have any ideas?

I think it would be a nightmare. It's easy to code it in Blender's Python interface, but the "wireframe" of such a mess of 5000-9000 squared blobs will be extremely difficult to edit interactively. Also the final result has a strong dependence in the resulting overlap of blobs, which is also hard to control.

Well perhaps Toti can be convinced to make his tool available for people to practice (after its compilation). I don't want to interfer. It's Toti's code (I just found a few bugs) . Certainly questions referring to the tool should be forbidden in case it's made available.

Although I don't mind people playing with it, I don't think it is a good idea: the new tool is taking shape and its results are uncomparably better.

My idea is for a CELX script that could use Celestia itself to display the results of galaxy template generation and modification to provide more immediate feedback of the actual results. This could be useful for experimenting with both algorithmic and interactive procecedures. It would certainly shorten the turn-around time for Fridger's technique.

Would you mind sending me the source code for bmp2pts so I could get an idea about the feasibility of a Lua implementation?

- Hank

[Toti]

Would you mind sending me the source code for bmp2pts so I could get an idea about the feasibility of a Lua implementation?

Of course I don't mind, but I don't have those sources since a long time. Please ask Fridger for them. He also eliminated a few buggies here and there...

[Toti]

Here's a really quick test of the new WIP vectorizing tool:

I took the SBc galaxy image that Fridger posted in page 13 and made the following 5-minutes Gimp manipulations:
--Adjusted brightness/contrast
--Perspective correction
--Added alpha channel
--Recomposed it with blue channel->alpha channel
--Adjusted alpha curve to highlight detailed areas
--Rescaled to 300x221 pixels

Then I fed it to the vectorizer and started Celestia.

My alpha adjustments are entirely unsatisfactory: there are lots of blobs that should have been eliminated and the cutout is too drastic in some areas. There's also noticeable banding along the local z axis, because I chose a very low randomize value. You can clearly see all this if you crank the gamma all the way up.
Also, the WIP renderer doesn't yet correctly manage several things:

--Transparency: the edge-on view is too well defined and lacks the gaseous feel. The dust lanes should be darker and thinner.
--LOD: lots of extra (mostly subpixel) blobs are added lowering the performance significantly.

So there's a lot of work to be done before it's ready for a test release...

[t00fri]

Fridger:

Since you are going to be busy for the next 10 days or so and out of the country, I am (GULP! ) going to ask (Don't get upset) ... if you could post the edited FT 1.1 file that fixes the flickering nebula problem? It can be just a Windows file ... nothing fancy. You already have it done ... and it seems the number of bug reports coming in on FT 1.1 have dropped to background level ... could this qualify as a reasonable time to release FT 1.1.1



Frank

Sorry Frank,

I don't think this would be a good idea to release additional i.e. "intermediate" versions for certain people. I wrote this in many variations already.

While the flickering is indeed fixed, its Windows-specific origin is still poorly understood. But notably, there is another unpleasant bug: The Milky Way is also visible at daytime and the rendering of galaxies switches off /instantaneously/, rather than gradually, at the day-night border. We know the reason for this, but fixing of this bug will need some further work.

Bye Fridger

[hank]

Would you mind sending me the source code for bmp2pts so I could get an idea about the feasibility of a Lua implementation?

Of course I don't mind, but I don't have those sources since a long time. Please ask Fridger for them. He also eliminated a few buggies here and there...

Fridger?

- Hank

[t00fri]

Would you mind sending me the source code for bmp2pts so I could get an idea about the feasibility of a Lua implementation?

Of course I don't mind, but I don't have those sources since a long time. Please ask Fridger for them. He also eliminated a few buggies here and there...

Fridger?

- Hank

Here its only 5:30 pm local time so I am still working hard in the office for quite a while. Tonight I shall pack the sources together and put them onto the TextureFoundry for people to download.

Plese note: I shall have very little time for answering respective questions! For people experienced in C/C++ programming the code is pretty easy to understand.

I shall give the gcc command with libs to load for Unix as well, but everyone else will be on his own, as to compilation. Under Linux the compilation it entirely trivial.

Cheers,
Fridger

[Russ Mitchell]

Thank you, sir, I am a complete novice with this software (almost all of this thread has gone right over my head as an astronomical layman), but what I can determine so far is very nice.

[t00fri]

Hi all,

here you may download Toti's galaxy template generator 'bmp2pts' as source code. This is only for experienced people who know how to compile C++ code!

++++++++++++++++++++++++
http://www.shatters.net/~t00fri/celestia/Bmp2pts.zip
++++++++++++++++++++++++
I have packed it as zip file (rather than tar.gz) such that both UNIX and Windows people may easily unpack it. The code still uses the UNIX line ending [\lf] (rather than Windows one: \cr \lf ) You may want to convert it e.g. with Word to Windows.

In the file 'Readme' you find the command to compile the source with the gcc compiler under Linux. If you want to compile it under Windows you are on your own, but it might well work easily.

You need a 128x128 grayscale .bmp image as input and then call the program as

bmp2pts <image.bmp> <threshold> <randomness>

I recommend you start with threshold = 0.5..0.6
and randomness ~ 0.03..0.05. If the printed number of points is below 5000, decrease the threshold slowly until the number of points is between 5000 and 9000, say.

If the number of generated points is too small the code SEGFAULTS. In this case either increase the brightness of the bmp input image or decrease the threshold parameter.

Good luck,
Fridger

[Malenfant]

I dunno if this has been mentioned, but when I press < or > in FT1.1 the field of view changes as usual, but I also get a message on the screen telling me the magnitude limit has changed too. The magnitude limit shown seems to vary between a limit of 9.02 (when at 120 degrees) and 16.97 when zoomed in as far as possible.

And when I press [ or ] instead of the magnitude limit changing, I get "Auto Magnitude Limit at 45 degrees" changing, which ranges from 5.9 to 12.00.

Why were these changes made? They don't seem to serve any more useful purpose than what was there before (in fact, they seem to just confuse things instead).

[t00fri]

I dunno if this has been mentioned, but when I press < or > in FT1.1 the field of view changes as usual, but I also get a message on the screen telling me the magnitude limit has changed too. The magnitude limit shown seems to vary between a limit of 9.02 (when at 120 degrees) and 16.97 when zoomed in as far as possible.

And when I press [ or ] instead of the magnitude limit changing, I get "Auto Magnitude Limit at 45 degrees" changing, which ranges from 5.9 to 12.00.

Why were these changes made? They don't seem to serve any more useful purpose than what was there before (in fact, they seem to just confuse things instead).

Indeed I have activated by default the "auto-magnitude" scheme that I have implemented into Celestia a long time ago. Could it be that you did not quite understand yet what it does and what it is good for??

It is quite a useful/sophisticated scheme, as soon as one has understood it.

If you don't like it, just comment the setting out in start.cel.

The auto-mag scheme works best with star data extending down to very dim stars, like the 2m star data base. It gives a great effect if you zoom in/out fast via SHIFT+Mouse L (who uses < and >??) . Do this alternatively after toggling CTRL+y on and off!

The idea is roughly speaking that the density of /visible/ stars on the screen stays /constant/ at all fields of view (FOV), i.t. when zooming in or out. The limiting magnitude for displaying stars /increases/ with decreasing FOV (i.e. zoom level) . So stars are moving out of the field because it becomes narrower, yet new ones come in, since the limiting magnitude increases.

This is a classical feature of professional level ephemerides programs (like e.g. XEphem), and I am surprised that you are not aware of its existence...

Bye Fridger

[Malenfant]

The idea is roughly speaking that the density of /visible/ stars on the screen stays /constant/ at all fields of view (FOV), i.t. when zooming in or out. The limiting magnitude for displaying stars /increases/ with decreasing FOV (i.e. zoom level) . So stars are moving out of the field because it becomes narrower, yet new ones come in, since the limiting magnitude increases.

Oh OK, I figured it might have something to do with that goal... as long as I can turn it off if I don't like it (and it seems like I can) then that's OK . Though now you mention it, it does sound kinda useful.

This is a classical feature of professional level ephemerides programs (like e.g. XEphem), and I am surprised that you are not aware of its existence...

I haven't heard of it, since oddly enough I have never used a professional level ephemerides program (I don't know why you'd assume I would have either).

[t00fri]

The idea is roughly speaking that the density of /visible/ stars on the screen stays /constant/ at all fields of view (FOV), i.t. when zooming in or out. The limiting magnitude for displaying stars /increases/ with decreasing FOV (i.e. zoom level) . So stars are moving out of the field because it becomes narrower, yet new ones come in, since the limiting magnitude increases.

Oh OK, I figured it might have something to do with that goal... as long as I can turn it off if I don't like it (and it seems like I can) then that's OK . Though now you mention it, it does sound kinda useful.

This is a classical feature of professional level ephemerides programs (like e.g. XEphem), and I am surprised that you are not aware of its existence...

I haven't heard of it, since oddly enough I have never used a professional level ephemerides program (I don't know why you'd assume I would have either).

Since you don't seem to be too familiar with the zoom in/out feature via SHIFT+Mouse L, let me mention the best: I am sure you have a wheel mouse. Clicking on the wheel toggles between the last zoom level and the default zoom level. Also something I implemented years ago...

Bye Fridger

[Malenfant]

Since you don't seem to be too familiar with the zoom in/out feature via SHIFT+Mouse L, let me mention the best: I am sure you have a wheel mouse. Clicking on the wheel toggles between the last zoom level and the default zoom level. Also something I implemented years ago...

Huh. I didn't know that, no. Thanks!

[hank]

Indeed I have activated by default the "auto-magnitude" scheme that I have implemented into Celestia a long time ago. Could it be that you did not quite understand yet what it does and what it is good for??

It is quite a useful/sophisticated scheme, as soon as one has understood it. ;-)

If you don't like it, just comment the setting out in start.cel.

The auto-mag scheme works best with star data extending down to very dim stars, like the 2m star data base. It gives a great effect if you zoom in/out fast via SHIFT+Mouse L (who uses < and >??) . Do this alternatively after toggling CTRL+y on and off!

The idea is roughly speaking that the density of /visible/ stars on the screen stays /constant/ at all fields of view (FOV), i.t. when zooming in or out. The limiting magnitude for displaying stars /increases/ with decreasing FOV (i.e. zoom level) . So stars are moving out of the field because it becomes narrower, yet new ones come in, since the limiting magnitude increases.

This is a classical feature of professional level ephemerides programs (like e.g. XEphem), and I am surprised that you are not aware of its existence...

Bye Fridger

Is there any particular reason why the magnitude limit adjustment is based on FOV rather than magnification?

- Hank

[t00fri]

Indeed I have activated by default the "auto-magnitude" scheme that I have implemented into Celestia a long time ago. Could it be that you did not quite understand yet what it does and what it is good for??

It is quite a useful/sophisticated scheme, as soon as one has understood it.

If you don't like it, just comment the setting out in start.cel.

The auto-mag scheme works best with star data extending down to very dim stars, like the 2m star data base. It gives a great effect if you zoom in/out fast via SHIFT+Mouse L (who uses < and >??) . Do this alternatively after toggling CTRL+y on and off!

The idea is roughly speaking that the density of /visible/ stars on the screen stays /constant/ at all fields of view (FOV), i.t. when zooming in or out. The limiting magnitude for displaying stars /increases/ with decreasing FOV (i.e. zoom level) . So stars are moving out of the field because it becomes narrower, yet new ones come in, since the limiting magnitude increases.

This is a classical feature of professional level ephemerides programs (like e.g. XEphem), and I am surprised that you are not aware of its existence...

Bye Fridger

Is there any particular reason why the magnitude limit adjustment is based on FOV rather than magnification?


- Hank

Increasing magnification in a telescope IS equivalent to decreasing its FOV, of course..

There's a whole theory behind the auto-mag scheme. But in a nutshell, it just emulates telescope mode.

Bye Fridger

[hank]

Increasing magnification in a telescope IS equivalent to decreasing its FOV, of course..

Well, yes, of course, but in Celestia you can also change the FOV by resizing the window. The magnification remains the same, but the magnitude adjusts. To me it would make more sense to base the magnitude adjustment on the magnification, and control it by specifying the magnitude limit at a magnification of 1, rather than at a 45 degree FOV.

- Hank

[t00fri]

Increasing magnification in a telescope IS equivalent to decreasing its FOV, of course..

Well, yes, of course, but in Celestia you can also change the FOV by resizing the window. The magnification remains the same, but the magnitude adjusts. To me it would make more sense to base the magnitude adjustment on the magnification, and control it by specifying the magnitude limit at a magnification of 1, rather than at a 45 degree FOV.

- Hank

The automag scheme was implemented already very long ago. At that time we did not yet /compute/ the FoV in terms of the users distance from the screen and the window size (<-> resolution), as we do now. That's why automag is (still) normalized to a fixed FoV of 45 degrees rather than a monitor-dependent value.

Apart from that, let me add that the FoV variation has an /exponentially large range/ via SHIFT+Mouse L, for example, while it is /in practice/ very small in terms of varying the window size. Why should we want to modify the latter anyway?

In fact, I don't really understand what exactly you are advocating. Do you want the flash output modified?

Like when pushing [ and ]:

Instead of

Auto magnitude limit at 45 degrees: 7.0

rather

Magnitude limit at magnification 1: 7.0


We preferred to use FoV instead of magnification, since we are /actually/ decreasing or increasing the FoV. Nowadays, I would prefer to normalize the AutoMag limiting magnitude on the /default/ FoV (whatever that is), rather than 45 degrees.


Bye Fridger

[t00fri]

Incidentally, I just learned that ElChristou managed to compile the bmp2pts tool on his Mac without problems...

So others might try, too...

Bye Fridger

[abramson]

Incidentally, I just learned that ElChristou managed to compile the bmp2pts tool on his Mac without problems...

I compiled ok on Linux, but failed with the Visual C++ under XP. No time to try, though.
Guillermo