where is star magnitude filtered for rendering

[tec]

Hello,
I would like to know where the stars are filtered as a function of the magnitude. I have walked through debugger many times and I cannot find this. When I press either of the two square brackets the star magnitude filter is increased or decreased. I can see in octree.cpp and render.cpp where most of the code handles drawing the star point source. I am looking for some kind of logarithmic function that assigns the pixel color as a function of the star magnitude.

I have prints in octree.cpp but if the star's magnitude if greater than the threshold it does not even make it into the octree.cpp functions.

Tim

[chris]

You're correct that the culling happens in octree.cpp. The whole point of the octree algorithm is to avoid individually checking each star's magnitude--an entire octree node full of faint stars can be culled with a single test. There may be a bug in the test in StarOctree::processVisibleObjects().

--Chris

[tec]

Thanks Chris for helping me. I registered a bug report on this and I am trying to fix it myself for you guys. You might want to read it in the bug forum get a more detailed list of my problems. See "stars not rendered properly when changing magnitude filter " in the bug forum.


You mentioned that the ProcessVisibleObjects() is where the culling takes place. The line:

Star& obj = _firstObject[i];

gets a star object but it seems (from the debugger) that the star is already culled. The line:

if (obj.getAbsoluteMagnitude() < dimmest)

doesn't seem to be needed because the object is already culled as a function of it's magnitude . For instance, I tried to print the obj when the obj.getCatalogNumber() was equal to 46768. This is one of the stars that is not rendering properly. When I place the code to print the magnitude, it never shows up because the star is already culled from the _firstObject list. I used

if( obj.getCatalogNumber() == 46768 )
DPRINTF( 0, "Here is 46768\n" );

I cannot find where the obj is culled before it gets to this function. The error I see is that some stars manitudes less than my star filter are not being draw. I know this because I read the screen and the pixel values are zero for red/green/blue.

Thanks for helping.
Tim

[Toti]

Tim,

Apparently that star is rendered in my system, at least when the observer is close to Sol.

[tec]

Hi Toti,
Thanks for getting invloved. Here is how I tested the HIP 46768. I am using the latest version 1.4.1. I press the return key to bring up the command window. I type "HIP 46768" and then I center the selection with the 'c' key. By default the star will not show up because something is wrong. Notice that 46768 has an apparent mangitude of 6.11. Yuo can see this from the information in the upper left text. I am positioned around the earth about 63Km away.

When I adjust my magnitude filter above 7.1 using the square brackets it will render. The 46768 star should render when the filter is greater than 6.1 and it is not there. It only pops into my view around 7.1 which is wrong.

I would like to fix this myself but I cannot find where the culling takes place. I have used the debugger to step through the code but I cannot find where the star is compared to the filter value. I did find a spot in staroctree.ccp where the filter is compare but the 46768 is never in the loop. It looks like the culling is taking place before staroctree.cpp.

There are many other stars that behave this way.
Tim

[Toti]

Tim,

I tested this in my other Linux partition and can't reproduce what you describe with HIP 46768 (it dissapears when it's too faint to be noticed in my small CRT, even as a disk) but I certainly found that 23 Hya is culled prematurely.

Also, HIP 46768 doesn't appear in the completion tab, which looks like a bug.

I'll do more testing later.

[selden]

Also, HIP 46768 doesn't appear in the completion tab, which looks like a bug.

No HIP catalog numbers appear due to the use of "tab completion". My understanding is that is the way it was designed. There are just too many of them.

Some Stars have been defined with HIP specifications as their names (not numbers). They appear when using "tab completion" because their names have been specified as quoted strings in several of Celestia's STC addon catalogs. This has confused more than one person, unfortunately. Look in visualbins.stc for some examples.

e.g.

Code: Select all

2237 "HIP2237 A" # component A


2237 is the star's Hipparcos catalog number, which is used as an index into Celestia's stars.dat database.

"HIP2237 A" is the star's name, which corresponds to its Hipparcos catalog number, but is not an index into Celestia's stars.dat database.

When you type HIP2237 with no space you'll see the list of star names which start with those characters. Celestia does not display the corresponding HIP indices that are used to access the binary database.

I hope this clarifies things a little.

[tec]

Toti,
I did not quite understand your message. Did you mean that you cannot test it because you CRT is too small?

You also said that the star is culled prematurely. Can you expand on this? How did you know this and where do you think the star is culled? I cannot find where it is culled.


To summarize what selden said, Just place a space between the HIP and the 46768 in the command prompt. Then press 'c' to center on the star.

Thanks

Tim

[Toti]

No HIP catalog numbers appear due to the use of "tab completion". My understanding is that is the way it was designed. There are just too many of them.

Thanks, I didn't know this, and it makes sense.

I did not quite understand your message. Did you mean that you cannot test it because you CRT is too small?

With the filter at ~7.5 the star appears so dim that it almost can't be seen (to my eye, it gradually "disappears" at ~7.3) so I cannot see the abrupt change when the star pops out even with "stars as disks" turned on and my CRT brightness at maximum.

But with 23 Hya it looks quite evident: just select "stars as disks" (ctrl-s twice) and crank your screen brightness all the way up: it should disappear abruptly at filter ~7.00

[Toti]

Hi,

Does anyone else see the problem with 23 Hya or is it just me?

[tec]

I see the problem. If you tighten the FOV to about 5 degrees you can see all of these problems better because there are not as many stars in the FOV. The 23 Hya is suppose to have an apparent magnitude of 5.23. It comes into view as I am increasing the mag filter at 7.3. It should come into view around 5.23, right?

This star is just one example of this bug. There are many in the star database that do this. I still cannot find where the culling is computed. staroctree.cpp does some culling but there is another place that culls, too. I just cannot find it.

Tim

[Toti]

I fixed the bug. Will commit the patch later.

[chris]

I fixed the bug. Will commit the patch later.

Thanks for working on this, Toti. What was the bug?

--Chris

[Toti]

You are welcome, Chris. It was a test missing in sortIntoChildNodes(). But I am almost sure I fixed this a year ago or so for FT 1.0. Probably I sent Fridger the wrong patch... working without a central repository was a mess. I hope everything works OK now.

Tim, thanks for your detailed bug report.

[Toti]

Just to be clear, the missing test was my mistake: I forgot to add it when I templatized your original octree implementation, which was correct.

[tec]

GREAT!!!!

Cannot I get the files? I really need them bad. My boss has been hounting me for weeks to fix this myself. You can send the modified files to tec@knology.net.

Thanks so much!
Tim

[Toti]

The fix is in CVS now. You can update your celestia sources:

Code: Select all

cvs update


There may be a couple hours of delay until it is available.