Crash in Sinusoidal Projection

[gzotti]

Sinusoidal projection is a good addition. However, an assert in Atmosphere.cpp fires if fov is larger than about 110 degrees.

[Alexander Wolf (alexwolf)]

I can't reproduce the issue on linux.

[gzotti (georg-zotti)]

Strange, I just did.

ASSERT: "fabs(point.lengthSquared()-1.0) < 1e-10" in file /<xxxxxxxxx>/StelBZR/trunk/src/core/modules/Atmosphere.cpp, line 265

Just zoom out, and ... poof!

Of course this is only in Debug mode.

[Alexander Wolf (alexwolf)]

I tried debug and release modes - nothing

[gzotti (georg-zotti)]

I can still reproduce it reliably, on Win7/NVidia and Intel HD/Ubuntu. You must have Atmosphere visible, and zoom out to about 110°.

[Alexander Wolf (alexwolf)]

I can't reproduce issue on Ubuntu/NVidia

[Alexander Wolf (alexwolf)]

Oh, I catch it!

[Alexander Wolf (alexwolf)]

few last lines:
point 1 : "[-0.683582, -0.62264, 0.380835]"
point 1 : "[-0.713127, -0.609051, 0.34714]"
point 1 : "[-0.741977, -0.592163, 0.314346]"
point 1 : "[-0.76997, -0.57207, 0.282635]"
point 1 : "[-0.796951, -0.548883, 0.252182]"
point 1 : "[-0.822771, -0.522732, 0.223158]"
point 1 : "[-0.847285, -0.493762, 0.195722]"
point 1 : "[-0.870358, -0.462133, 0.170028]"
point 1 : "[-0.891862, -0.428022, 0.146217]"
point 1 : "[-0.911677, -0.391616, 0.124423]"
point 1 : "[-0.920917, -0.372617, 0.114321]"
point 1.24508 : "[-0.768205, 0.47562, 0.654773]"
ASSERT: "fabs(point.lengthSquared()-1.0) < 1e-10" in file /home/aw/devel/stellarium/trunk/src/core/modules/Atmosphere.cpp, line 266

at the line 265: qWarning() << "point" << point.lengthSquared() << " : " << point.toString();

[gzotti (georg-zotti)]

The thing is about getting the "blank desktop" into view. This works well e.g. for Hammer-Aitoff, but not for Sinusoidal.

[Alexander Wolf (alexwolf)]

Sinusoidal projection based on "Fish-eye" projection (similar mathematics)

[gzotti (georg-zotti)]

Nick, I have found a preliminary fix for the Sinusoidal projection.

However, it requires a test in Atmoshphere.cpp line ~268.

if (!(fabs(point.lengthSquared()-1.0) < 1e-10))
                            continue;
    or even just
if (!(prj->unProject(v[0],v[1],point)))
                                    continue;

but this causes artifacts in other projections which show edge-of-projection.

I dislike the test (no other projection needs it!), the projection's unproject should be repaired instead.

[Nick Fedoseev (nick-ut2uz)]

I can't reproduce the bug in Relase build. But the bug can easily be
reproduced in Debug build.

I'd like to understand what is the meaning of that verification:

(Atmosphere.cpp, line ~265)

Q_ASSERT(fabs(point.lengthSquared()-1.0) < 1e-10);

Just tried a very simple solution: Commented out the line. Everything seems
to work fine. Did I miss something?

2015-10-11 20:44 GMT+03:00 gzotti <email address hidden>:

> Nick, I have found a preliminary fix for the Sinusoidal projection.
>
> However, it requires a test in Atmoshphere.cpp line ~268.
>
> if (!(fabs(point.lengthSquared()-1.0) < 1e-10))
> continue;
> or even just
> if (!(prj->unProject(v[0],v[1],point)))
> continue;
>
> but this causes artifacts in other projections which show edge-of-
> projection.
>
> I dislike the test (no other projection needs it!), the projection's
> unproject should be repaired instead.
>
>
> ** Changed in: stellarium
> Assignee: (unassigned) => Nick Fedoseev (nick-ut2uz)
>
> ** Changed in: stellarium
> Milestone: None => 0.14.0
>
> --
> You received this bug notification because you are a bug assignee.
> https://bugs.launchpad.net/bugs/1472555
>
> Title:
> Crash in Sinusoidal Projection
>
> Status in Stellarium:
> Confirmed
>
> Bug description:
> Sinusoidal projection is a good addition. However, an assert in
> Atmosphere.cpp fires if fov is larger than about 110 degrees.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/stellarium/+bug/1472555/+subscriptions
>

[gzotti (georg-zotti)]

Well, the Q_ASSERT only is avaluated in debug builds.
I don't know who put the test in here and why (comments would help here!!!) but there likely was some reason for having it here.
I also don't see a big problem currently when the test is omitted (automatically in Release builds). But there may be hidden effects somewhere!
However, zoom far out and look west. There are black regions appearing now in Sinusoidal. (Oh: on locations on the Southern hemisphere, look east instead...)

[gzotti (georg-zotti)]

BTW some incomplete implementation may also be responsible for https://bugs.launchpad.net/stellarium/+bug/1498012. Admitted, other projections are not completely free from striping artifacts and should be fixed as well, but the point.lengthSquare() (for whichever reason it is here) test does not fail on them.

[Nick Fedoseev (nick-ut2uz)]

I need to understand what's doing in the code. At least for finding the proper place for the fix.

Just dumped fabs(point.lengthSquared()-1.0) for the Sinusoidal projection...

Yes, values are sigificantly greater than expected, up to ~0.5, but nothing exceptional on the screen. All the artefacts seen are visible in some other projections as well.

Again, the value of fabs(point.lengthSquared()-1.0) is 0.442039, for example. It is not a single point or a few random ones. It is a huge array of such values, they smoothly become greater with increasing the FOV. So, values are 1 000 000 000+ times greater than expected... Should I see anything strange at the screen? But I see nothing strange. That's why I asked for meaning of that QASSERT.

As about projection itself. It does forward and backward transformation correctly and can be verified with "Show Coordinates Of The Mouse Pointer" plugin. Perhaps there is a problem with transformations outside of possible transformation field. But I do not know what should be done there.

One more question, why this bug appears only with atmosphere drawing turned on. As I can remember, there was a fix to make backward transformation more precise for atmosphere refraction. But it still works fine for stars and planets.

IMHO the problem is not with point transformation, but with drawing triangles in OpenGL. Since I'm still a newcomer with OpenGL drawing, I can't promise a fast solition. I promise to try in the range of my knowledge, extending that range when possible. And I need any kind of help on this way.

[gzotti (georg-zotti)]

Hm, testing with mouse coordinates is a good ídea. It seems the values outside the defined area (corners when zoomed out) are valid by numbers, but wrong, because they are in fact meaningless. (The coordinate display should not show anything here IMHO. In this area unproject() should return false to signal "invalid".) You may be better able to find out with the coord display set to Alt/Az, I think the mouse pos is projected to the border of the defined area or something like this.

Apparently doing an unproject() for screen coordinates outside the Sinusiodal drawing area creates bogus values. This must also be the case for the other projections, but they can handle the situation somehow gracefully. (This may be why there are "nice" shades of blue around Hammer-Aitoff, Orthographic, etc.) Maybe add a test or normalize() call to just the sinusoldal.unproject() method, and let it return false if length was 1 before normalisation? By this, the (costly) normalize() is only called if necessary, not for every projection.

The bug appears only with atmosphere because the Q_ASSERT is only in this function which renders the blue-sky background. It has nothing to do with the refraction fix. I cannot say currently why the original author of these lines (Fabien?) wanted to make sure that lengthSquared should be 1, i.e., the vector should be normalized, at that point, it must have to do with what happens with point coordinates after that. I may also look into the code later or in the next week, but this part is also mostly unknown to me.
HTH, G.

[gzotti (georg-zotti)]

Hi!

can you maybe give me a link to the basic formulae?

in bool StelProjectorSinusoidal::backward(Vec3d &v) const, what do you do with v[2] in the special case? Likely length>1 then. What is the special case dealing with?

r7959 brings a fix for now. But see comments in backward().

[Nick Fedoseev (nick-ut2uz)]

The basic idea of current implementation was the small difference between cylinder and sin projection, which just need minor changes like an extra multiplier.

I can't remember when somebody (perhaps me?) added the following into StelProjectorSinusoidal::backward

 if (v[0]<-M_PI*cd || v[0]>M_PI*cd)
 {
  v[0] = -cd;
  v[1] = 1.0;
  return false;
 }

If theese lines are commented out, then no asserts fired. But in such a case some stars are drawn incorrectly when FOV > 120.
I also can remember a question, why some objects are drawn fine while the other ones are missed or drawn in a wrong place outside the field. Seems the transformation is the same for all objects... With that if block stars are drawn correctly but assert is fired.

[gzotti (georg-zotti)]

Please see recent commit: I added a normalize() in this part, now the ASSERT is fine. I just did not go through the math yet. The striping problem https://bugs.launchpad.net/stellarium/+bug/1498012 may be harder though.

[gzotti (georg-zotti)]

I think we can close this now. The original bug is solved by normalizing v in those lines and the black regions vanished. There is a FIXME comment in the code, whoever did the math please comment or give reference.