projections alpha test

[LeaseOnLife]

Originally Posted by boat_alexandra

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.

Sean

thanks to Chuck I have been able to test a couple days old version. Displaying polyconic as polyconics works well now, as well as in other projections. I am using the Apostle Islands in Lake Superior as a test case.

So any US Great Lakes sailor would benefit greatly from your projection feature, almost all official charts are polyconic here.

I added a comment to my bug report for polyconic charts:

FS#1810 : Georeferencing on quilted polyconic charts gone wrong

How else can I help to have this pushed into 4.2? Can we maybe reduce content for 4.2 (no tilt and remove lesser known projections..)?



Dirk

[seandepagnier]

I don't know what the time frame is for a 4.2 stable version. All I can say is this work changed the underlying regions logic from screen coordinate rectangles to latitude and longitude floating point polygons. This will surely cause bugs somewhere somehow to emerge but I know for a fact it fixes a lot of existing problems that have nothing to do with polyconic charts.

For this reason it's not a good idea to merge this right now if a stable version will be released soon. Judging by the pull requests dave is selecting I'm guessing this is the case (already plenty of other things probably won't make it in 4.2)

Furthermore, we should analyze the great lakes charts to determine exactly what version of polyconic they used because I'm certain it's different than what we have now so it will cause some very slight errors. If there are any other charts available in polyconic (or even other projections like polar) I would like to know about them.

Taking out tilt and some other projections would make the changes 95% of what they are now. A lot of changes were needed (region logic) to enable future development to do all kinds of interesting things with not much effort.

[bdbcat]

Sean...

I would like to see the triangle region code as a clean pull. I agree that there will be breakage. So lets start.

At the same time, we can integrate the glu tesselator (at least) and really clean up the mygeom.cpp classes. Get rid of the ugly tri.c tesselator, for one thing. Get rid of the rectangle strip tesselator used for cm93 in DC mode, for another. All this would a decent target for 4.2, with real performance improvement obtained.

The glu tess code is in the tree, so some cmake work might be all that is required.... There were problems with include files (conflicting definitions), so I had to build a private include file...


Actually, 4.2 is not scheduled at all, in my mind. There is lots of test time available. Aside from one or two bugs on Mac, O4 is a stable and useful release, so no real pressure.


Thanks
Dave

[seandepagnier]

Dave,

I remember you mentioning when 4.0 was released that you wanted the next stable release much sooner so for whatever reason I thought this meant august (coinciding with the first stable release for android) but maybe it's too soon. If you do have an idea of when it would help me plan.

Anyway, the triangle region code works, but the initial simple implementation suffers from using way too many triangles, so it's still mostly fine, but in certain cases it becomes too slow. My later implementation which is a lot more efficient in several ways (and also is a lot more complicated) is not fully tested because I switched to just using the glu tesselator and polygons which actually seems to work after all.

For our purposes we could make our own version of glutess, and my idea was initially to replace double with float and not allocate memory for colors because it's already enough precision and roughly twice as fast with a fourth the memory use which would suit us fine and would be really easy to implement.

[seandepagnier]

Dave,

I remember you mentioning when 4.0 was released that you wanted the next stable release much sooner so for whatever reason I thought this meant august (coinciding with the first stable release for android) but maybe it's too soon. If you do have an idea of when it would help me plan.

Anyway, the triangle region code works, but the initial simple implementation suffers from using way too many triangles, so it's still mostly fine, but in certain cases it becomes too slow. My later implementation which is a lot more efficient in several ways (and also is a lot more complicated) is not fully tested because I switched to just using the glu tesselator and polygons which actually seems to work after all.

For our purposes we could make our own version of glutess, and my idea was initially to replace double with float and not allocate memory for colors because it's already enough precision and roughly twice as fast with a fourth the memory use which would suit us fine and would be really easy to implement.

[ChuckSK]

Hi Sean

Here are a few fixes for tides and currents.

diff --git a/src/TCWin.cpp b/src/TCWin.cpp
index da97e49..0fd04e7 100644
--- a/src/TCWin.cpp
+++ b/src/TCWin.cpp
@@ -706,6 +706,8 @@ void TCWin::OnPaint( wxPaintEvent& event )
 
 void TCWin::OnSize( wxSizeEvent& event )
 {
+    if( !m_created ) return;
+
     int x, y;
     GetClientSize( &x, &y );
     
diff --git a/src/glChartCanvas.cpp b/src/glChartCanvas.cpp
index e053a03..c550333 100644
--- a/src/glChartCanvas.cpp
+++ b/src/glChartCanvas.cpp
@@ -3752,12 +3752,16 @@ void glChartCanvas::DrawGLTidesInBBox(ocpnDC& dc, LLBBox& BBox)
     }
     else
         cc1->DrawAllTidesInBBox( dc, BBox );
+
+    cc1->RebuildTideSelectList( cc1->GetVP().GetBBox() );
     
 }
 
 void glChartCanvas::DrawGLCurrentsInBBox(ocpnDC& dc, LLBBox& BBox)
 {
-        cc1->DrawAllCurrentsInBBox( dc, BBox );
+    cc1->DrawAllCurrentsInBBox( dc, BBox );
+    cc1->RebuildCurrentSelectList( cc1->GetVP().GetBBox() );
+
 }

chuck