New Celestia-1.4.0pre-FT1 (galaxies) for Testing

[hank]

I noted already that indeed in Windows (only) I do not see the MilkyWay arms from inside (distance to center < Radius), although the name is completed and selected on the command line. Next I selected SMC and went there (G). Then I typed again Milky Way and centered it. From SMS I could see the MilkyWay from a distance as a nice barred spiral as it should be. So for some mysterious reason rendering has been switched off if the observer is located /within a galaxy/, here the Milky Way.

So it must be something in winmain.cpp, since in the KDE GUI program everything works fine. Wuff...I only changed 1 line in winmain.cpp rather unrelated with this ;-)

Fridger,

I'm also seeing this problem on Mac OS X, so it's probably not something in winmain.cpp :-)

- Hank

[hank]

So for some mysterious reason rendering has been switched off if the observer is located /within a galaxy/, here the Milky Way.

Fridger,

I think the problem may be in DSOOctree::processVisibleObjects at line 103 in dsooctree.cpp where the distance to the object for detemining its apparent magnitude is calculated with respect to the bounding sphere:

Code: Select all

            double distance    = obsPosition.distanceTo(_obj->getPosition())
                               -_obj->getRadius();


This gives a negative value when the observer is inside the bounding sphere. Forcing the distance to be non-negative seems to fix the problem (at least on Mac OS X):

Code: Select all

            double distance    = obsPosition.distanceTo(_obj->getPosition())
                               -_obj->getRadius();
            if (distance<0) distance = 0;


(I don't understand why this isn't a problem on Linux also.)

- Hank

[abramson]

One idea that came to my mind: do the people who get the crashes perhaps have add-ons in extras? I dont have ANY...

Zero addons. Version 1.4.0 installed in a separate directory, with nothing extra installed (besides Ft1).

Cheers,

Guille


EDITED: Oh, just read the rest of the thread. I'm glad the problem has somehow been pinned down.

BTW: does any of the VCC knowledgeable programmers here have an idea of how to solve the error I got when compiling? (.\res\celestia.rc(226) : error RC2104 : undefined keyword or key name: DTS_RIGHTALIGN). Unfortunately I do all my scientific programming in Fortran, I know less C than I do German...

Tchuss,

Guille[/b]

[Toti]

Fridger,

I think the problem may be in DSOOctree::processVisibleObjects at line 103 in dsooctree.cpp where the distance to the object for detemining its apparent magnitude is calculated with respect to the bounding sphere:

Many thanks! This is a leftover from a few experiments I made on the dso octree. I'll see what happens with the modified code...

Bye

[Toti]

I just fixed the splitView keys and menu calls (for KDE).

Presumably it should work for every other platform.

[maxim]

That's the first time I looked at the galaxy stuff, and I'm deeply impressed.
Not only MUCH better than the old representation, but also MUCH faster, even on my small MX card. And much more realistic of course.

VERY NICE!

So, as every time when I'm impressed, my brain starts bubbling and wildly generating ideas on the stuff. So here they are (ignore them if you find them idiotic):

- How about letting the code choose randomly from a /number/ of hubble class models, so the galaxies don't all look the same inside one class?
- How about letting the code interleave 2 or 3 'half-models' so the galaxies apear really unique, even within one type?
- How about allowing the 'deepsky.dsc' entries to contain a reference to a specific .pts file, so that a talented and ambigious modeler can model an exact .pts version of a certain galaxy without beeing bound to the now oldfashioned billboard method?
- As I understand, every line in the .pts file correspondents to the coordinates of a small glowing blob of the viewed model - it may be x,y,z and size/brighness. So how about allowing a negativ forth value, indicating a /dark/ blob, so dark bands of matter could be also modeled inside galaxies?
- Theoretically, having galaxies represented as a bulk of particles with defined coordinates, it should be possible to build an educational showing for example the evolution of a galaxy - streching and thinning of arms while it is rotating - /if/ the coordinates could be manipulated via script access. Any chance?

Well, so far about some brainstorming.

maxim

[t00fri]

That's the first time I looked at the galaxy stuff, and I'm deeply impressed.
Not only MUCH better than the old representation, but also MUCH faster, even on my small MX card. And much more realistic of course.

VERY NICE!

So, as every time when I'm impressed, my brain starts bubbling and wildly generating ideas on the stuff. So here they are (ignore them if you find them idiotic):

- How about letting the code choose randomly from a /number/ of hubble class models, so the galaxies don't all look the same inside one class?
- How about letting the code interleave 2 or 3 'half-models' so the galaxies apear really unique, even within one type?
- How about allowing the 'deepsky.dsc' entries to contain a reference to a specific .pts file, so that a talented and ambigious modeler can model an exact .pts version of a certain galaxy without beeing bound to the now oldfashioned billboard method?
- As I understand, every line in the .pts file correspondents to the coordinates of a small glowing blob of the viewed model - it may be x,y,z and size/brighness. So how about allowing a negativ forth value, indicating a /dark/ blob, so dark bands of matter could be also modeled inside galaxies?
- Theoretically, having galaxies represented as a bulk of particles with defined coordinates, it should be possible to build an educational showing for example the evolution of a galaxy - streching and thinning of arms while it is rotating - /if/ the coordinates could be manipulated via script access. Any chance?

Well, so far about some brainstorming.

maxim

Maxim,

before any further discussion, you should realize that each template presently adds 250-300KB of filesize. So our minimum of 7 amounts to additional 2MB. Moreover my "kingsize" deepsky.dsc is 5MB. In addition, we will be doing gaseous nebulae and globular clusters with a similar approach and large size catalogs....

We may assume that we save a factor two, by turning all this in binary format. But nevertheless, you can see the generic problematics.

If the Celestia default archive becomes too large for downloading, we have a real problem.

Now, instead of randomizing, my proposal was some time ago rather to get back to the modern extended Hubble class scheme which involves many more subclasses and is used by the professional galaxy catalogs.

So instead of randomness, we would put in substantially more /information/ content instead, adding extended Hubble templates! The effect would be almost identical, since the number of subclasses is pretty large. You see, in my PERL scripts, I spent a lot of work to reduce the quoted extended Hubble classification to the simple one. I.e. the extended information is there, waiting to be used!

As to allowing for a specific .pts file per galaxy, this was actually the first approach. But we felt after some discussion that for a start, things remain more compact and also more elegant with just 7 templates for 10000+ galaxies . But introducing such a possible .pts file per galaxy is really simple and the code even exists already!

In all future modifications we have to be EXTREMELY concerned about speed! Even small amounts of slowdown may easily add up to big undesired effects if we are not extremely careful, due to the LARGE numbers of objects involved.

Bye Fridger

[PlutonianEmpire]

The result is as I suspected. All galaxies are rendered EXCEPT the Milky Way from inside.

Actually, it not only happens in the milky way, but also every other galaxy as well. I went to whirlpool (m51), entered it, and got the same thing--the galaxy disappeared when inside it.

[t00fri]

The result is as I suspected. All galaxies are rendered EXCEPT the Milky Way from inside.

Actually, it not only happens in the milky way, but also every other galaxy as well. I went to whirlpool (m51), entered it, and got the same thing--the galaxy disappeared when inside it.

You may forget about this now. Hank found the reason. Here is Toti's comment

Many thanks! This is a leftover from a few experiments I made on the dso octree. I'll see what happens with the modified code...

It must have happened in the last moment before we released the code . We shall release a fixed version ASAP.

Bye Fridger

[PlutonianEmpire]

Ah. Thanks

[maxim]

before any further discussion, you should realize that each template presently adds 250-300KB of filesize. So our minimum of 7 amounts to additional 2MB. Moreover my "kingsize" deepsky.dsc is 5MB. In addition, we will be doing gaseous nebulae and globular clusters with a similar approach and large size catalogs....

We may assume that we save a factor two, by turning all this in binary format. But nevertheless, you can see the generic problematics.

If the Celestia default archive becomes too large for downloading, we have a real problem. Wink

Of course I didn't meant it to be part of the default package - just to prepare the code so that such things are possible as addons.

Now, instead of randomizing, my proposal was some time ago rather to get back to the modern extended Hubble class scheme which involves many more subclasses and is used by the professional galaxy catalogs.

So instead of randomness, we would put in substantially more /information/ content instead, adding extended Hubble templates! The effect would be almost identical, since the number of subclasses is pretty large. You see, in my PERL scripts, I spent a lot of work to reduce the quoted extended Hubble classification to the simple one. I.e. the extended information is there, waiting to be used!

Ok, that sounds good. Also not neccessarily as default, but as extended package I'd suppose.

As to allowing for a specific .pts file per galaxy, this was actually the first approach. But we felt after some discussion that for a start, things remain more compact and also more elegant with just 7 templates for 10000+ galaxies Wink . But introducing such a possible .pts file per galaxy is really simple and the code even exists already!

That's all I've asked for - a ready to use code for those that want to do addons.

In all future modifications we have to be EXTREMELY concerned about speed! Even small amounts of slowdown may easily add up to big undesired effects if we are not extremely careful, due to the LARGE numbers of objects involved.

Agreeing, additional possibilities should't affect speed.


What about 'dark' blobs for opaque bands of matter?

maxim

[Toti]

- How about allowing the 'deepsky.dsc' entries to contain a reference to a specific .pts file, so that a talented and ambigious modeler can model an exact .pts version of a certain galaxy without beeing bound to the now oldfashioned billboard method?

In addition to what Fridger said, I indeed implemented "on demand" loading of templates. You can override any of the default templates with custom ones to depict odd shaped galaxies, etc. The code allows for any number of default templates so enlarging the standard Hubble subclasses is straightforward. Since there can be a lot of these templates defined, objects are loaded when they are about to be rendered.
This is exactly the same behaviour as with other Celestia objects (eg. planets, probes, etc.)
All this is not included in this FT1 test release.

- As I understand, every line in the .pts file correspondents to the coordinates of a small glowing blob of the viewed model - it may be x,y,z and size/brighness. So how about allowing a negativ forth value, indicating a /dark/ blob, so dark bands of matter could be also modeled inside galaxies?

AFAICS there's an OpenGL 1.2 limitation there. Also the current .pts scheme and rendering is quite rudimentary. We plan to redefine it soon: this would allow rendering of dark clouds and other effects.

Bye

[danielj]

If there is no ready compiled version of Celestia-Windows,why don??t you tell that it was a test only to general users of Mac and Linux?I am not like Kolano and Fightspit,who have tons of money...
Obviously,I give up testing and return to my regular Celestia 1.4.0 pre6.I will be waiting for a final version,though,or ANYONE THAT DO NOT REQUIRE A COMPILED VERSION TO WORK!

The compiler has to be bought in case of Windows and is quite expensive.

Fortunately for some, this is not entirely correct. A free version of the compiler is available, but quite a lot of work needs to be done to make it work. The details are in the thread in the Celestia Development Forum at Sticky: Free Windows-based compiling for Celestia.

[lostfisherman]

Just to say I gave it what rough test I could last night. The galaxies render well, I can orient well with the mouse like any model, "a" and "s" travel speed keys give good animation, and the cores of galaxies brighten with increased distance (did I read that that was an intention?). It's a very neat job, Fridger and Toti.

My low end WinMe 128 meg memory and GeForce 2 isn't the ideal system to use Celestia, but like I said, the galaxies look good. I have however lost vertex and Nvidia combiners; I had them both with version 1.4.0pre6, ctrl V won't give them to me now. I can see from earlier posts a concern with the ctrl V command, so I'll look forward to a new release and hope the problem isn't mine.

Thanks for the hard work.

[buggs_moran]

In addition, we will be doing gaseous nebulae and globular clusters with a similar approach and large size catalogs....

I understand how globular clusters would be possible under this system as clusters, like galaxies, have roughly defined catalog shapes (hence the seven galaxy shapes ((and ellipticals to come...))).

How will you define gaseous nebulae shapes since, as far as my knowledge goes, are not remotely the same shape (barring Planetaries maybe)? And, would you be able to define the material (by gas type H, O, N or dust?? for emission color, reflectivity, etc) so depending on star placement the nebulae become differentially emissive/reflective? What a project that would be...sorry for that...I take it all back

[Toti]

My low end WinMe 128 meg memory and GeForce 2 isn't the ideal system to use Celestia, but like I said, the galaxies look good. I have however lost vertex and Nvidia combiners; I had them both with version 1.4.0pre6, ctrl V won't give them to me now. I can see from earlier posts a concern with the ctrl V command, so I'll look forward to a new release and hope the problem isn't mine.

Hi,

Perhaps you can help us to debug this one: what happens if you use the "latest CVS" celestia.exe file Selden posted (page 5) ?

[t00fri]

If there is no ready compiled version of Celestia-Windows,why don??t you tell that it was a test only to general users of Mac and Linux?I am not like Kolano and Fightspit,who have tons of money...
Obviously,I give up testing and return to my regular Celestia 1.4.0 pre6.I will be waiting for a final version,though,or ANYONE THAT DO NOT REQUIRE A COMPILED VERSION TO WORK!

Daniel,

you are trying again hard to make me angry. First you were unable to read a simple README.1st file in our Win32 release, which would have avoided the trouble you had initially. It starts off clearly like so:

Use a recent complete celestia-win32-1.4.0pre6 installation and replace the executable Celestia.exe by the present one.
...

Next you did not care to read what I wrote as headline over the Windows release:

WINDOWS (celestia.exe + deepsky.dsc + galaxy templates )
====================================

It explicitly states EVERY file that we released for Windows

Everyone else EXCEPT YOU, apparently did not have any problems interpreting and installing correctly the files we provided for Windows.

Last not least, once more: Toti and I are not programmers whose task it is to work for you

[lostfisherman]

Hi,

Perhaps you can help us to debug this one: what happens if you use the "latest CVS" celestia.exe file Selden posted (page 5) ?

Hello Toti,

The same thing happens, I lose vertex/Nvidia combiners; that is, no normal maps, no specular reflections and no atmospheric effects for Earth. Ctrl v behaves in the same way as I described in my previous post. This is with Seldens copy of celestia.exe you directed me to on page 5 of this thread.

My original exe file (1.4.0pre6) works as it should and everything is restored when I put it back (ctrl v, i mean).

[t00fri]

In addition to what Fridger said, I indeed implemented "on demand" loading of templates. You can override any of the default templates with custom ones to depict odd shaped galaxies, etc. The code allows for any number of default templates so enlarging the standard Hubble subclasses is straightforward. Since there can be a lot of these templates defined, objects are loaded when they are about to be rendered.

Toti,

while one could do it like you said, it is much more simple to extend the set of default templates from 7 to a fixed enlarged set (say 20) in galaxy.cpp.

Then all the changes needed in deepsky.dsc would be to return to the extended classification quoted e.g. in the RC3 catalog. You apparently forgot in your above claim that it is a quite NONTRIVIAL affair to parse those cryptic extended Hubble strings and translate them into a concrete template file name. That has to be coded beyond what you provided so far. Perhaps you have never seen such a string before. Here are a few:

Code: Select all

PSXT3*. Sr,
.SX.4P* PU,
.S..3*/ S,
...


Just to remind you about the parsing complexity to reduce those cryptics to the few Hubble classics, here is the respective PERL code:

Code: Select all

  $Type = &ss(79,87);
  $Type =~ s/^\s*//;
  $Type =~ s/\s*$//;
  $Type =~ s/\s+/ /g;
  if ($Type =~ /S[\+\?0abcdm]?|^[ES]$|SB[?0abcdm]?|d?E[\+\?0-7]?|Irr|IB?m?|C|RING|Ring|GxyP|P|D|^R/) {
    $HType = $Type;
    $HType =~ s/^E\/SB0/S0/;
    $HType =~ s/^(\w)\+C/$1/;
    $HType =~ s/\/P?R?G?D?\b//;
    $HType =~ s/(\w+\??)\sB?R?M?/$1/;
    $HType =~ s/^d//;
    $HType =~ s/(\w+)\d\-(\w)/$1$2/;
    $HType =~ s/^E\-?\/?S0/S0/;
    $HType =~ s/^S(B?)[abc]([abc])/S$1$2/;
    $HType =~ s/SB\?/SBa/;
    $HType =~ s/SB0/S0/;
    $HType =~ s/^E\??\ ?B?R?$/E0/;
    $HType =~ s/^S\??$/S0/;
    $HType =~ s/^Sd$/Irr/;
    $HType =~ s/^S(B?)c?d/S$1c/;
    $HType =~ s/^IB?m?$/Irr/;
    $HType =~ s/^Irr B$/Irr/;
    $HType =~ s/^SB?d?m/Irr/;
    $HType =~ s/^C/E0/;
    $HType =~ s/^P\??/Irr/;
    $HType =~ s/GxyP/Irr/;
    $HType =~ s/^Ring.*[AB]?$/S0/;
    $HType =~ s/^SBcm/Irr/;
    $HType =~ s/S\+S/Sa/;
    $HType =~ s/E\+E\??/E0/;
    $HType =~ s/^[cd]?D\ ?R?/E0/;
    $HType =~ s/E\+\*?C?\??S?/E0/;
    $HType =~ s/^R\w\d$/Irr/;
    $HType =~ s/^R/S0/;


It is arbitrarily easy in this business to add a little buggy
Note that this extended scheme is simply too RICH for using a simple lookup table. But one could easily generate one with Perl once for all.

We certainly would not want to add an extra extended Hubble class file entry in EACH of the 10000+ galaxies after having agreed to generally implement the extended Hubble scheme!

I think the extra ("personalized") entries in the deepsky.dsc should be reserved to a few special templates that one wants to introduce for cases where the generic mass rendering is too inadequate.

Finally, I am far from certain that your advocated "loading on demand" mechanism is not significantly slower (for 10000+ objects) than a simple preloading of say 20 templates and an optimized decoding method.
I think we should make first a profiling study before saying that it all is "straightforward" (including speed issues, of course!).

Bye Fridger

[t00fri]

Hi,

Perhaps you can help us to debug this one: what happens if you use the "latest CVS" celestia.exe file Selden posted (page 5) ?

Hello Toti,

The same thing happens, I lose vertex/Nvidia combiners; that is, no normal maps, no specular reflections and no atmospheric effects for Earth. Ctrl v behaves in the same way as I described in my previous post. This is with Seldens copy of celestia.exe you directed me to on page 5 of this thread.

My original exe file (1.4.0pre6) works as it should and everything is restored when I put it back (ctrl v, i mean).

So I see a "certain" problem to "motivate" Chris to /quickly/ fix that bug he has presumably introduced while implementing his last code and DrJoe's orbit fixes into CVS

Bye Fridger