Cruisers Forum
 


Join CruisersForum Today

Reply
 
Thread Tools Rate Thread Display Modes
Old 02-07-2015, 20:04   #16
Registered User
 
LeaseOnLife's Avatar

Join Date: Apr 2008
Location: out cruising again
Boat: Sailboat
Posts: 1,046
Re: projections alpha test

Quote:
Originally Posted by ChuckSK View Post
Check this out!

Attachment 104559


chuck

Way cool. Just need a compiled version for my Win7 Boat-PC and I am in, helping testing in my home waters...

Dirk
__________________

__________________
LeaseOnLife is offline   Reply With Quote
Old 05-07-2015, 06:50   #17
Registered User
 
boat_alexandra's Avatar

Join Date: Aug 2009
Location: Masachusetts
Boat: bristol 27
Posts: 2,804
Re: projections alpha test

Quote:
Originally Posted by ChuckSK View Post
Check this out!

Attachment 104559


chuck
Nice.. so it works on windows. Did you manage to play around with it any more? Panning should be faster in course up mode for example (especially with tide stations enabled) but quilting ENC in course up should also work (broken in master) and of course all the projections (gnomonic is my favorite) which you can access with the context menu.

There is even an experimental projection view (not really fully implemented with the < > keys)

Did anything break seriously? I really want to merge this work but it's a lot of changes and it's certain to have cause problems I cannot find.
__________________

__________________
boat_alexandra is offline   Reply With Quote
Old 05-07-2015, 10:04   #18
Registered User

Join Date: Apr 2009
Location: Marina Del Rey
Boat: Hylas 44
Posts: 387
Re: projections alpha test

OK Sean, this is too much.

Quilted skewed charts, rotated, tilted, with AIS, tides and currents.

Click image for larger version

Name:	Capture5.jpg
Views:	93
Size:	443.8 KB
ID:	104703

The only important issue is CM93 charts don't display; singly or quilted.

I will attempt a pull request with the tweaks needed to satisfy windows.

chuck
__________________
ChuckSK is offline   Reply With Quote
Old 05-07-2015, 15:03   #19
Registered User

Join Date: Apr 2009
Location: Marina Del Rey
Boat: Hylas 44
Posts: 387
Re: projections alpha test

Sean

I realized I cannot submit a pull request on your fork. Here is a diff file instead. Not every change was tested to determine if it is absolutely necessary.

Code:
diff --git a/include/LLRegion.h b/include/LLRegion.h
index c44c761..7ddb834 100644
--- a/include/LLRegion.h
+++ b/include/LLRegion.h
@@ -45,7 +45,7 @@ struct contour_pt
 typedef std::list<contour_pt> poly_contour;
 class LLBBox;
 
-class work;
+struct work;
 class LLRegion
 {
 public:
diff --git a/src/LLRegion.cpp b/src/LLRegion.cpp
index bcfc4c1..9a3d941 100644
--- a/src/LLRegion.cpp
+++ b/src/LLRegion.cpp
@@ -174,7 +174,7 @@ static inline int ComputeState(const LLBBox &box, const contour_pt &p)
 
 inline bool TestPoint(contour_pt p0, contour_pt p1, double x, double y)
 {
-    contour_pt p = {.y=y, .x=x};
+    contour_pt p = { y, x};
     return cross(vector(p0, p1), vector(p0, p)) < 0;
 }
 
@@ -254,7 +254,8 @@ struct work
     LLRegion &region;
 };
 
-static void LLvertexCallback(GLvoid *vertex, void *user_data)
+
+static void CALLBACK LLvertexCallback(GLvoid *vertex, void *user_data)
 {
     work *w = (work*)user_data;
     const GLdouble *pointer = (GLdouble *)vertex;
@@ -263,27 +264,28 @@ static void LLvertexCallback(GLvoid *vertex, void *user_data)
     w->contour.push_back(p);
 }
 
-static void LLbeginCallback(GLenum which) {}
+static void CALLBACK LLbeginCallback(GLenum which) {
+}
 
-static void LLendCallback(void *user_data)
+static void CALLBACK LLendCallback(void *user_data)
 {
     work *w = (work*)user_data;
     if(w->contour.size()) {
         w->region.contours.push_back(w->contour);
         w->contour.clear();
-    }
+    }    
 }
 
-static void LLcombineCallback( GLdouble coords[3], GLdouble *vertex_data[4], GLfloat weight[4],
+static void CALLBACK LLcombineCallback( GLdouble coords[3], GLdouble *vertex_data[4], GLfloat weight[4],
                       GLdouble **dataOut, void *user_data )
 {
     work *w = (work*)user_data;
-    GLdouble *vertex = w->NewData();
-    memcpy(vertex, coords, 3*(sizeof *coords));
-    *dataOut = vertex;
+    GLdouble *vertex = w->NewData(); 
+    memcpy(vertex, coords, 3*(sizeof *coords)); 
+    *dataOut = vertex;    
 }
 
-static void LLerrorCallback(GLenum errorCode)
+static void CALLBACK LLerrorCallback(GLenum errorCode)
 {
     const GLubyte *estring;
     estring = gluErrorString(errorCode);
@@ -298,7 +300,7 @@ void LLRegion::Intersect(const LLRegion& region)
         return;
     }
 
-    Put(region, GLU_TESS_WINDING_ABS_GEQ_TWO);
+    Put(region, GLU_TESS_WINDING_ABS_GEQ_TWO, false);
 }
 
 void LLRegion::Union(const LLRegion& region)
@@ -308,7 +310,7 @@ void LLRegion::Union(const LLRegion& region)
         return;
     }
 
-    Put(region, GLU_TESS_WINDING_POSITIVE);
+    Put(region, GLU_TESS_WINDING_POSITIVE, false);
 }
 
 void LLRegion::Subtract(const LLRegion& region)
@@ -416,15 +418,15 @@ void LLRegion::PutContours(work &w, const LLRegion& region, bool reverse)
     }
 }
 
-void LLRegion::Put(const LLRegion& region, int winding_rule, bool reverse)
+void LLRegion::Put( const LLRegion& region, int winding_rule, bool reverse)
 {
     work w(*this);
-
-    gluTessCallback(w.tobj, GLU_TESS_VERTEX_DATA, (GLvoid (*) ()) &LLvertexCallback);
-    gluTessCallback(w.tobj, GLU_TESS_BEGIN, (GLvoid (*) ()) &LLbeginCallback);
-    gluTessCallback(w.tobj, GLU_TESS_COMBINE_DATA, (GLvoid (*) ()) &LLcombineCallback );
-    gluTessCallback(w.tobj, GLU_TESS_END_DATA, (GLvoid (*) ()) &LLendCallback);
-    gluTessCallback(w.tobj, GLU_TESS_ERROR, (GLvoid (*) ()) &LLerrorCallback);
+   
+    gluTessCallback( w.tobj, GLU_TESS_VERTEX_DATA, reinterpret_cast<_GLUfuncptr> ( &LLvertexCallback ) );
+    gluTessCallback( w.tobj, GLU_TESS_BEGIN, reinterpret_cast<_GLUfuncptr>  ( &LLbeginCallback ) );
+    gluTessCallback( w.tobj, GLU_TESS_COMBINE_DATA, reinterpret_cast<_GLUfuncptr>  ( &LLcombineCallback ) );
+    gluTessCallback( w.tobj, GLU_TESS_END_DATA, reinterpret_cast<_GLUfuncptr>  ( &LLendCallback ) );
+    gluTessCallback( w.tobj, GLU_TESS_ERROR, reinterpret_cast<_GLUfuncptr> ( &LLerrorCallback ) );
     gluTessProperty(w.tobj, GLU_TESS_WINDING_RULE, winding_rule);
     gluTessProperty(w.tobj, GLU_TESS_BOUNDARY_ONLY, GL_TRUE);
 //    gluTessProperty(w.tobj, GLU_TESS_TOLERANCE, 1e-5);
@@ -436,7 +438,7 @@ void LLRegion::Put(const LLRegion& region, int winding_rule, bool reverse)
     PutContours(w, *this);
     PutContours(w, region, reverse);
     contours.clear();
-    gluTessEndPolygon(w.tobj);
+    gluTessEndPolygon( w.tobj ); 
 
     Optimize();
     m_box.SetValid(false);
diff --git a/src/bbox.cpp b/src/bbox.cpp
index ef1aee5..9347834 100644
--- a/src/bbox.cpp
+++ b/src/bbox.cpp
@@ -320,7 +320,7 @@ wxBoundingBox& wxBoundingBox::operator+(wxBoundingBox &other)
 // makes a boundingbox same as the other
 wxBoundingBox& wxBoundingBox::operator=( const wxBoundingBox &other)
 {
-    assert (other.GetValid());
+ //   assert (other.GetValid());
 
     m_minx = other.m_minx;
     m_maxx = other.m_maxx;
diff --git a/src/canvasMenu.cpp b/src/canvasMenu.cpp
index 3f41e26..16b89a8 100644
--- a/src/canvasMenu.cpp
+++ b/src/canvasMenu.cpp
@@ -276,7 +276,7 @@ wxMenu *MenuAppend2( wxMenu *menu, wxString label)
 #if defined(__WXMSW__) || defined(__OCPN__ANDROID__)
    
     wxFont *qFont = GetOCPNScaledFont(_("Menu"));
-    item->SetFont(*qFont);
+//    item->SetFont(*qFont);
 #endif
     menu->Append(wxID_ANY, label, item);
     return item;
diff --git a/src/glChartCanvas.cpp b/src/glChartCanvas.cpp
index 5fc26d8..a535088 100644
--- a/src/glChartCanvas.cpp
+++ b/src/glChartCanvas.cpp
@@ -1721,7 +1721,8 @@ void glChartCanvas::RenderChartOutline( int dbIndex, ViewPort &vp )
 
         bool begin = false, sml_valid = false;
         double sml[2];
-        float lastplylat, lastplylon;
+        float lastplylat = 0.0;
+        float lastplylon = 0.0;
         for( int i = 0; i < nPly+1; i++ ) {
             if(nAuxPlyEntries)
                 ChartData->GetDBAuxPlyPoint( dbIndex, i%nPly, j, &plylat, &plylon );
@@ -2582,10 +2583,10 @@ void glChartCanvas::DrawRegion(ViewPort &vp, const LLRegion &region)
 
     GLUtesselator *tobj = gluNewTess();
 
-    gluTessCallback(tobj, GLU_TESS_VERTEX_DATA, (GLvoid (*) ()) &glVertex3dv);
-    gluTessCallback(tobj, GLU_TESS_BEGIN, (GLvoid (*) ()) &glBegin);
-    gluTessCallback(tobj, GLU_TESS_END_DATA, (GLvoid (*) ()) 0);
-    gluTessCallback(tobj, GLU_TESS_END, (GLvoid (*) ()) &glEnd);
+    gluTessCallback( tobj, GLU_TESS_VERTEX, reinterpret_cast <_GLUfuncptr>  ( &glVertex3dv ) );
+    gluTessCallback( tobj, GLU_TESS_BEGIN, reinterpret_cast <_GLUfuncptr> ( &glBegin ) );
+   // gluTessCallback( tobj, GLU_TESS_END_DATA, reinterpret_cast <_GLUfuncptr> ( 0 ) );
+    gluTessCallback( tobj, GLU_TESS_END, reinterpret_cast <_GLUfuncptr> ( &glEnd ) );
 
     gluTessNormal( tobj, 0, 0, 1);
 
@@ -2992,7 +2993,8 @@ void glChartCanvas::RenderRasterChartRegionGL( ChartBase *chart, ViewPort &vp, L
             }
 
             float *coords;
-            float convertedcoords[2*tile->m_ncoords];
+            float *convertedcoords = new float[2 * tile->m_ncoords];
+          //  float convertedcoords[2*tile->m_ncoords];
             if(use_norm_vp)
                 coords = tile->m_coords;
             else {
@@ -3011,6 +3013,8 @@ void glChartCanvas::RenderRasterChartRegionGL( ChartBase *chart, ViewPort &vp, L
 
             if(!texture)
                 glEnable(GL_TEXTURE_2D);
+
+            delete [] convertedcoords;
         }
     }
 
diff --git a/src/viewport.cpp b/src/viewport.cpp
index 48da635..0c64a0d 100644
--- a/src/viewport.cpp
+++ b/src/viewport.cpp
@@ -133,6 +133,9 @@ ViewPort::ViewPort()
     pix_height = pix_width = 0;
     b_MercatorProjectionOverride = false;
     lat0_cache = NAN;
+    m_projection_type = 1;
+    pitch = 0;
+
 }
 
 // TODO: eliminate the use of this function
@@ -144,7 +147,8 @@ wxPoint ViewPort::GetPixFromLL( double lat, double lon )
 
 wxPoint2DDouble ViewPort::GetDoublePixFromLL( double lat, double lon )
 {
-    double easting, northing;
+    double easting = 0;
+    double northing = 0;
     double xlon = lon;
 
     /*  Make sure lon and lon0 are same phase */
chuck
__________________
ChuckSK is offline   Reply With Quote
Old 05-07-2015, 17:58   #20
Registered User
 
LeaseOnLife's Avatar

Join Date: Apr 2008
Location: out cruising again
Boat: Sailboat
Posts: 1,046
Re: projections alpha test

Sean

Thanks to Chuck I have a version of your branch to play with on Windows7. I tested a few simple cases, displaying Polyconic as Polyconinc. Grid lines match well and the waypoints and tracks did not end up on land as with current/main 4.xx series. Displaying Polyconic as Mercator works well here too. Nice work!

But trying to do a Polyconic => Polar or Polyconic => Gnomonic causes latitude gridlines on the chart not to match Opencpn's overlay grid. Try with any of the freely available NOAA RNC for the Great Lakes, my home turf is 14852_1.kap

Dirk
Attached Thumbnails
Click image for larger version

Name:	harsensisland.JPG
Views:	58
Size:	129.2 KB
ID:	104742   Click image for larger version

Name:	polyconic-gnomonic.JPG
Views:	60
Size:	68.8 KB
ID:	104743  

__________________
LeaseOnLife is offline   Reply With Quote
Old 05-07-2015, 19:20   #21
Registered User

Join Date: Jun 2015
Posts: 201
Re: projections alpha test

Hi,
Quote:
Originally Posted by boat_alexandra View Post
Did anything break seriously? I really want to merge this work but it's a lot of changes and it's certain to have cause problems I cannot find.
Nice, but:
- it doesn't compile with gcc 4.6.3, in src/LLRegion.cpp
contour_pt p = {.y=y, .x=x};
Too cutting edge syntax :)

- It doesn't run when compiled with debug, on startup:
Quote:
wxBoundingBox& wxBoundingBox::operator=(const wxBoundingBox&): Assertion `other.GetValid()' failed.
Quote:
#4 0xb6fe5d67 in __GI___assert_fail (assertion=0x8506176 "other.GetValid()", file=0x8506120 "src/bbox.cpp",
line=323, function=0x8506200 "wxBoundingBox& wxBoundingBox::operator=(const wxBoundingBox&)") at assert.c:103
#5 0x0819e16f in wxBoundingBox::operator= (this=0x95c83c4, other=...) at src/bbox.cpp:323
#6 0x081cf124 in LLBBox::operator= (this=0x95c83c4) at include/bbox.h:88
#7 0x0824d8e2 in LLRegion::operator= (this=0x95c83bc) at include/LLRegion.h:49
#8 0x08246378 in QuiltCandidate::GetCandidateRegion (this=0x95c83b0) at src/Quilt.cpp:131
#9 0x08249e28 in Quilt::Compose (this=0x8a023a0, vp_in=...) at src/Quilt.cpp:1462
#10 0x081dae44 in ChartCanvas::SetViewPoint (this=0x88a89b8, lat=26.490100000000002, lon=-82.049300000000002, scale_ppm=0.079156197607517242,
skew=0, rotation=0, projection=0, b_adjust=true, b_refresh=true) src/chcanv.cpp:3278
#11 0x08181153 in MyFrame::DoChartUpdate (this=0x889a690) src/chart1.cpp:7220
#12 0x08166d01 in MyApp::OnInit (this=0x86c7d60) at src/chart1.cpp:2024
Didier
__________________
did-g is online now   Reply With Quote
Old 08-07-2015, 01:04   #22
Registered User
 
boat_alexandra's Avatar

Join Date: Aug 2009
Location: Masachusetts
Boat: bristol 27
Posts: 2,804
Re: projections alpha test

Quote:
Originally Posted by ChuckSK View Post
Sean

I realized I cannot submit a pull request on your fork. Here is a diff file instead. Not every change was tested to determine if it is absolutely necessary.
I didn't know how, but it's possible to submit a pull request to the branch. Anyway, I accept patches as well
Quote:
Code:
diff --git a/include/LLRegion.h b/include/LLRegion.h
index c44c761..7ddb834 100644
--- a/include/LLRegion.h
+++ b/include/LLRegion.h
@@ -45,7 +45,7 @@ struct contour_pt
 typedef std::list<contour_pt> poly_contour;
 class LLBBox;
 
-class work;
+struct work;
 class LLRegion
 {
 public:
I want to understand why this is needed.
Quote:
Code:
@@ -298,7 +300,7 @@ void LLRegion::Intersect(const LLRegion& region)
         return;
     }
 
-    Put(region, GLU_TESS_WINDING_ABS_GEQ_TWO);
+    Put(region, GLU_TESS_WINDING_ABS_GEQ_TWO, false);
 }
Is this required to build or run correctly, or you think a better style?
Quote:
Code:
diff --git a/src/bbox.cpp b/src/bbox.cpp
index ef1aee5..9347834 100644
--- a/src/bbox.cpp
+++ b/src/bbox.cpp
@@ -320,7 +320,7 @@ wxBoundingBox& wxBoundingBox::operator+(wxBoundingBox &other)
 // makes a boundingbox same as the other
 wxBoundingBox& wxBoundingBox::operator=( const wxBoundingBox &other)
 {
-    assert (other.GetValid());
+ //   assert (other.GetValid());
 
     m_minx = other.m_minx;
     m_maxx = other.m_maxx;
Any suggestion to make this hit so I can analyze it better? Maybe my assertions are off. In any case, I don't think this is the correct fix.


I will merge your patch and make some changes as I see fit.


As for polyconic charts in polar coordinates... I think I know the problem and I can fix that one very easily, but otherwise I will find a way to fix it somehow anyway.
__________________
boat_alexandra is offline   Reply With Quote
Old 08-07-2015, 08:39   #23
Registered User

Join Date: Apr 2009
Location: Marina Del Rey
Boat: Hylas 44
Posts: 387
Re: projections alpha test

Hi Sean

Those changes are not required. They are left over from my trial and error testing; sorry.
__________________
ChuckSK is offline   Reply With Quote
Old 10-07-2015, 13:03   #24
Registered User

Join Date: Jun 2013
Location: Moscow, Russia
Boat: Clerk Chair 1.6ft
Posts: 39
Re: projections alpha test

Quote:
Originally Posted by boat_alexandra View Post
mercator, polar, and spherical projections supported by pressing '1', '2', '3'
Quote:
Originally Posted by boat_alexandra View Post
I fixed some things and added gnomonic projections.
Since the latter message, I cannot switch between projections by pressing 1, 2, 3 or 4, neither can I toggle grid lines by pressing G, like one of your recent patches suggests; standard one-key shortcuts are working meanwhile. Moreover, your version does not display latitude labels after 60°.


For testing purposes, I created a fake North Pole chart (save the attached 001POLEN.000.doc as “001POLEN.000”). Due to high amount of efforts required to generate charts programmatically (despite numerous helper functions, it still takes about 20 kilobytes of code to get a 5500-byte chart file, of which 1500 bytes are the DDF header), it contains very few data, but should be enough to start looking for rendering errors.

Here is my own simplified rendering in Equidistant Cylindrical projection (aka Plate Carrée, aka Simple Cylindrical):
Click image for larger version

Name:	001POLEN.mars.Cylindrical-Equidistant.png
Views:	54
Size:	1.7 KB
ID:	105091
From North (90° N) to South (85° N):
  • unsurveyed area (90° N to 89° N), depicted in gray;
  • depth area (89° N to 85° N), depicted in cyan;
  • ice area (89° N to 86° N), depicted in semi-transparent light gray over the cyan depth area;
  • traffic separation line (starting at 88° N 180° W and going to 135° E and then returning to 87° N), depicted in pink;
  • spot soundings (85.5° N to 87.5° N and 120° E to 165° E), depicted in violet;
  • landmarks at Geographic North Pole (90° N 0° E) and Magnetic North Pole (86.3° N 160° W), depicted in orange.
A textual dump in HTML is attached as 001POLEN.html.doc (strip “.doc”).

Here is my simplified rendering in Equidistant Conical projection (aka Conic, aka Simple Conic):
Click image for larger version

Name:	001POLEN.mars.Conical-Equidistant.png
Views:	54
Size:	9.4 KB
ID:	105092
Small gap between 180° W and 180° E is perhaps due to computation errors and/or over-aggressive rendering optimizations, rather than due to the fact that the value 179.9999999° E is actually used in this chart instead of 180.0° E to ensure software compatibility.

My rendering in Orthographic Azimuthal projection looks basically the same as the one in Equidistant Conical, but it does not have the gap and yet has some shapes screwed (missing or incorrect), — indeed, it is not easy to handle charts that span 360° and optimize for speed and node count at the same time. Therefore I do not attach this bad rendering.

Tried this chart with existing software:
  • OpenCPN — import succeeds, but no chart boundaries are visible;
  • SeeMyENC — depth area and ice area both cover the Geographic North Pole, although they should not; unsurveyed area is not visible at all;
  • PolarView NS — chart manager error: “Unable to add cell” (pretty verbose!);
  • Fugawi View ENC — displays Magnetic North Pole only.
Your are welcome to try anything else you have access to.
__________________
SamsonovAnton is offline   Reply With Quote
Old 10-07-2015, 17:04   #25
Registered User

Join Date: Apr 2009
Location: Marina Del Rey
Boat: Hylas 44
Posts: 387
Re: projections alpha test

Hi Sean

This patch fixes a problem with charts that straddle the IDL. PointsCCW is used in different ways for charts and viewports, so I duplicated it to make changes. I'm sure there is a more elegant solution.

Code:
diff --git a/include/LLRegion.h b/include/LLRegion.h
index 7ddb834..48ebd04 100644
--- a/include/LLRegion.h
+++ b/include/LLRegion.h
@@ -56,6 +56,7 @@ public:
     LLRegion( size_t n, const double *points );
 
     static bool PointsCCW( size_t n, const double *points );
+    static bool PointsCCWidl( size_t n, const double *points );
     
     void Print() const;
     
diff --git a/src/LLRegion.cpp b/src/LLRegion.cpp
index 4490f46..4febcb1 100644
--- a/src/LLRegion.cpp
+++ b/src/LLRegion.cpp
@@ -66,6 +66,14 @@ LLRegion::LLRegion( size_t n, const double *points )
     InitPoints(n, points);
 }
 
+double cidl( double val )
+{
+    if( val > 180.0 ) return val -= 360.0;
+    if( val < -180.0 ) return val += 360.0;
+    return val;
+}
+
+
 // determine if a loop of points is counter clockwise
 bool LLRegion::PointsCCW( size_t n, const double *points )
 {
@@ -83,6 +91,25 @@ bool LLRegion::PointsCCW( size_t n, const double *points )
     return total > 0;
 }
 
+// determine if a loop of points is counter clockwise
+bool LLRegion::PointsCCWidl( size_t n, const double *points )
+{
+    double total = 0;
+    int pl = 2 * ( n - 1 );
+    double x0 = points[0] - points[pl + 0];
+    double y0 = cidl(points[1] - points[pl + 1]);
+    for( unsigned int i = 0; i<2 * n; i += 2 ) {
+        int pn = i < 2 * ( n - 1 ) ? i + 2 : 0;
+        double x1 = points[pn + 0] - points[i + 0];
+        double y1 = cidl(points[pn + 1] - points[i + 1]);
+        total += x1*y0 - x0*y1;
+        x0 = x1, y0 = y1;
+    }
+    return total > 0;
+}
+
+
+
 void LLRegion::Print() const
 {
     for(std::list<poly_contour>::const_iterator i = contours.begin(); i != contours.end(); i++) {
@@ -483,7 +510,7 @@ void LLRegion::InitPoints( size_t n, const double *points)
     std::list<contour_pt> pts;
     bool adjust = false;
 
-    bool ccw = PointsCCW(n, points);
+    bool ccw = PointsCCWidl(n, points);
     for(unsigned int i=0; i<2*n; i+=2) {
         contour_pt p;
         p.y = points[i+0];
chuck
__________________
ChuckSK is offline   Reply With Quote
Old 13-07-2015, 06:18   #26
Registered User
 
boat_alexandra's Avatar

Join Date: Aug 2009
Location: Masachusetts
Boat: bristol 27
Posts: 2,804
Re: projections alpha test

Chuck,

Thank you for the patch. I was certain I dealt with charts straddling the idl, but didn't test this case recently, I will take a look again. I just pushed a few more fixes. I have a few minor things still, then I hope to start making pull requests (first with changes that are unlikely to break anything) but eventually I must try to push the LLRegion logic which is almost guaranteed to cause some fallout, although I know it fixes a lot of problems.
__________________
boat_alexandra is offline   Reply With Quote
Old 14-07-2015, 20:53   #27
Registered User
 
rgleason's Avatar

Join Date: Mar 2012
Location: Boston, MA
Boat: 1981 Bristol 32 Sloop
Posts: 9,382
Re: projections alpha test

These are some more exciting things happening. Wow.
__________________
rgleason is offline   Reply With Quote
Old 16-07-2015, 05:11   #28
Registered User
 
boat_alexandra's Avatar

Join Date: Aug 2009
Location: Masachusetts
Boat: bristol 27
Posts: 2,804
Re: projections alpha test

Quote:
Originally Posted by ChuckSK View Post
Hi Sean

This patch fixes a problem with charts that straddle the IDL. PointsCCW is used in different ways for charts and viewports, so I duplicated it to make changes. I'm sure there is a more elegant solution.
Chuck,

your patch was not technically correct because it broke the case when the viewport crosses both 0 and 180 meridian at the same time. I have corrected the issue (was it only raster charts?) and so it should be fixed now. I never saw any rendering errors (did you find this?) but only now realized it was doing more work than it should be in this case. Maybe in some case the quilt was wrong but I couldn't find it. I don't have any vector charts besides cm93 that cross the idl, and cm93 uses 0-360 so the issues with it are on the 0 meridian already.

I found that in a few cases performance is actually worse so I really need to correct this. What do you think of tilted mode? Is it worth it or just a gimmick? I saw a screenshot of garmin doing this so I didn't want them to have something we don't when it took about 5 lines of code to add. In any case several things should not be tilted, and it's also not possible to make routes in this mode yet.
__________________
boat_alexandra is offline   Reply With Quote
Old 16-07-2015, 10:11   #29
Registered User

Join Date: Apr 2009
Location: Marina Del Rey
Boat: Hylas 44
Posts: 387
Re: projections alpha test

Sean

Yes there were rendering errors while panning raster charts that straddled the IDL. That is all working now. I knew there must be a better fix.

The tilted mode may be a gimmick but I like it.
__________________
ChuckSK is offline   Reply With Quote
Old 20-07-2015, 01:02   #30
Registered User
 
boat_alexandra's Avatar

Join Date: Aug 2009
Location: Masachusetts
Boat: bristol 27
Posts: 2,804
Re: projections alpha test

Chuck

I made a few more fixes (mainly I broke the performance in dc-mode which is fixed now)

As for tilted mode, I am still struggling with the calculations to make the measurement and route tools work properly. I used gluUnProject but unfortunately I want to specify screen x and y, but object z, to determine object x and y, not screen x, y and z. I will try to download the source code to glu so I can dissect it.

I think tilted mode will become much more useful once we can get topo data for the land (possible plugin) and also maybe we can render the contours in the sea using 3 dimensions (with lighting) which could be useful in harbors, but we would want to have fairly high resolution soundings.

Otherwise, are there any serious issues with this? Any cases performance is noticeably worse that master? If not, I will break the changes into more reasonable commits (this eliminates the changes that changed things back etc..) but I maybe have to wait until after 4.2 is released before this can be considered.
__________________

__________________
boat_alexandra is offline   Reply With Quote
Reply

Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
OpenCPN for Android Alpha test 4.1.409 bdbcat OpenCPN 117 12-10-2015 02:28
OpenCPN for Android Alpha test 4.1.427 bdbcat OpenCPN 139 29-05-2015 15:27
OpenCPN for Android Alpha test 4.1.412 bdbcat OpenCPN 120 15-05-2015 13:12
S63_PI Alpha Test 0.3.0 bdbcat OpenCPN 25 07-04-2014 11:00
S63_PI Alpha Test 0.2.0 bdbcat OpenCPN 29 05-02-2014 11:26



Copyright 2002- Social Knowledge, LLC All Rights Reserved.

All times are GMT -7. The time now is 04:07.


Google+
Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
Social Knowledge Networks
Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2017, vBulletin Solutions, Inc.

ShowCase vBulletin Plugins by Drive Thru Online, Inc.