[Nanocubes-discuss] Drawing problems

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[Nanocubes-discuss] Drawing problems

Alex Bongiovanni
I've now gotten most of the functionality of the 1.0 nanocube demo working with the master branch's cube (a very large thank you for that).  The problem that I'm now having is that things aren't drawing in the right position (but they are drawing!).  The problem is well-defined however, and is related to the zoom/coarseness.

If our original drawing can be defined as being composed of two halves:
|-----|
|  1  |
|-----|
|  2  |
|-----|
Then after one level of zoom (and it does actually display the refined points for the next level of zoom) what gets drawn is:
|-----|
|  2  |
|-----|
|  1  |
|-----|
This persists the further you zoom in; at the next level of zoom (if we now divide into quarters in a manner similar to how we split into halves) we get:
|-----|
|  4  |
|  3  |
|-----|
|  2  |
|  1  |
|-----|

I doubt the drawing code is the problem, as it is identical to the current code for the working BrightKite demo you have.  This makes me think that the tile data is either being processed incorrectly, or stored incorrectly.  Neither of these seem likely as the code for processing the tile binaries hasn't changed (as has previously been explained), and the code for storage (tile_pointset.js and tile_cache.js) is identical to the working versions in your demo.

I'm at a loss to what to look for (having now spend several hours trying to debug this) and was wondering if you had any ideas.

--
Alex Bongiovanni
University of Maryland
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Nanocubes-discuss] Drawing problems

laurolins
Hi Alex,

I am not sure I understood the problem, but to me it seemed that the data tiles are upside down. If that is the case you can try inverting the “row” of the pixels sent on the ‘tile’ query. So if you have a pixel with row coordinate i, you use ii=255-i instead (this is considering that your tile is at full resolution: 256x256; if it is a coarser tile at 128x128, you would use ii=127-i instead and so on…).

Lauro


On Jan 30, 2014, at 1:41 PM, Alex Bongiovanni <[hidden email]> wrote:

I've now gotten most of the functionality of the 1.0 nanocube demo working with the master branch's cube (a very large thank you for that).  The problem that I'm now having is that things aren't drawing in the right position (but they are drawing!).  The problem is well-defined however, and is related to the zoom/coarseness.

If our original drawing can be defined as being composed of two halves:
|-----|
|  1  |
|-----|
|  2  |
|-----|
Then after one level of zoom (and it does actually display the refined points for the next level of zoom) what gets drawn is:
|-----|
|  2  |
|-----|
|  1  |
|-----|
This persists the further you zoom in; at the next level of zoom (if we now divide into quarters in a manner similar to how we split into halves) we get:
|-----|
|  4  |
|  3  |
|-----|
|  2  |
|  1  |
|-----|

I doubt the drawing code is the problem, as it is identical to the current code for the working BrightKite demo you have.  This makes me think that the tile data is either being processed incorrectly, or stored incorrectly.  Neither of these seem likely as the code for processing the tile binaries hasn't changed (as has previously been explained), and the code for storage (tile_pointset.js and tile_cache.js) is identical to the working versions in your demo.

I'm at a loss to what to look for (having now spend several hours trying to debug this) and was wondering if you had any ideas.

--
Alex Bongiovanni
University of Maryland
_______________________________________________
Nanocubes-discuss mailing list
[hidden email]
http://mailman.nanocubes.net/mailman/listinfo/nanocubes-discuss_mailman.nanocubes.net

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Nanocubes-discuss] Drawing problems

Alex Bongiovanni
It is more like, if you divide the map into rows (the number being based on how zoomed in you are), the rows become switched about.  Surprisingly, changing 
'y_array[i] = 256 - ((1 + view.getUint8(record_size*i)) << (8 - res));
to 
'y_array[i] = ((1 + view.getUint8(record_size*i)) << (8 - res)) - 256;
solves the problem, but gives me the map upside down.



On Thu, Jan 30, 2014 at 3:33 PM, Lauro Lins <[hidden email]> wrote:
Hi Alex,

I am not sure I understood the problem, but to me it seemed that the data tiles are upside down. If that is the case you can try inverting the “row” of the pixels sent on the ‘tile’ query. So if you have a pixel with row coordinate i, you use ii=255-i instead (this is considering that your tile is at full resolution: 256x256; if it is a coarser tile at 128x128, you would use ii=127-i instead and so on…).

Lauro


On Jan 30, 2014, at 1:41 PM, Alex Bongiovanni <[hidden email]> wrote:

I've now gotten most of the functionality of the 1.0 nanocube demo working with the master branch's cube (a very large thank you for that).  The problem that I'm now having is that things aren't drawing in the right position (but they are drawing!).  The problem is well-defined however, and is related to the zoom/coarseness.

If our original drawing can be defined as being composed of two halves:
|-----|
|  1  |
|-----|
|  2  |
|-----|
Then after one level of zoom (and it does actually display the refined points for the next level of zoom) what gets drawn is:
|-----|
|  2  |
|-----|
|  1  |
|-----|
This persists the further you zoom in; at the next level of zoom (if we now divide into quarters in a manner similar to how we split into halves) we get:
|-----|
|  4  |
|  3  |
|-----|
|  2  |
|  1  |
|-----|

I doubt the drawing code is the problem, as it is identical to the current code for the working BrightKite demo you have.  This makes me think that the tile data is either being processed incorrectly, or stored incorrectly.  Neither of these seem likely as the code for processing the tile binaries hasn't changed (as has previously been explained), and the code for storage (tile_pointset.js and tile_cache.js) is identical to the working versions in your demo.

I'm at a loss to what to look for (having now spend several hours trying to debug this) and was wondering if you had any ideas.

--
Alex Bongiovanni
University of Maryland
_______________________________________________
Nanocubes-discuss mailing list
[hidden email]
http://mailman.nanocubes.net/mailman/listinfo/nanocubes-discuss_mailman.nanocubes.net


_______________________________________________
Nanocubes-discuss mailing list
[hidden email]
http://mailman.nanocubes.net/mailman/listinfo/nanocubes-discuss_mailman.nanocubes.net




--
Alex Bongiovanni
University of Maryland
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Nanocubes-discuss] Drawing problems

Alex Bongiovanni
It turns out that removing any subtraction altogether results in an upside down, problem free map.  Taking the negation of either the x or y values causes the problem to happen in the respective dimensions.


On Thu, Jan 30, 2014 at 3:41 PM, Alex Bongiovanni <[hidden email]> wrote:
It is more like, if you divide the map into rows (the number being based on how zoomed in you are), the rows become switched about.  Surprisingly, changing 
'y_array[i] = 256 - ((1 + view.getUint8(record_size*i)) << (8 - res));
to 
'y_array[i] = ((1 + view.getUint8(record_size*i)) << (8 - res)) - 256;
solves the problem, but gives me the map upside down.



On Thu, Jan 30, 2014 at 3:33 PM, Lauro Lins <[hidden email]> wrote:
Hi Alex,

I am not sure I understood the problem, but to me it seemed that the data tiles are upside down. If that is the case you can try inverting the “row” of the pixels sent on the ‘tile’ query. So if you have a pixel with row coordinate i, you use ii=255-i instead (this is considering that your tile is at full resolution: 256x256; if it is a coarser tile at 128x128, you would use ii=127-i instead and so on…).

Lauro


On Jan 30, 2014, at 1:41 PM, Alex Bongiovanni <[hidden email]> wrote:

I've now gotten most of the functionality of the 1.0 nanocube demo working with the master branch's cube (a very large thank you for that).  The problem that I'm now having is that things aren't drawing in the right position (but they are drawing!).  The problem is well-defined however, and is related to the zoom/coarseness.

If our original drawing can be defined as being composed of two halves:
|-----|
|  1  |
|-----|
|  2  |
|-----|
Then after one level of zoom (and it does actually display the refined points for the next level of zoom) what gets drawn is:
|-----|
|  2  |
|-----|
|  1  |
|-----|
This persists the further you zoom in; at the next level of zoom (if we now divide into quarters in a manner similar to how we split into halves) we get:
|-----|
|  4  |
|  3  |
|-----|
|  2  |
|  1  |
|-----|

I doubt the drawing code is the problem, as it is identical to the current code for the working BrightKite demo you have.  This makes me think that the tile data is either being processed incorrectly, or stored incorrectly.  Neither of these seem likely as the code for processing the tile binaries hasn't changed (as has previously been explained), and the code for storage (tile_pointset.js and tile_cache.js) is identical to the working versions in your demo.

I'm at a loss to what to look for (having now spend several hours trying to debug this) and was wondering if you had any ideas.

--
Alex Bongiovanni
University of Maryland
_______________________________________________
Nanocubes-discuss mailing list
[hidden email]
http://mailman.nanocubes.net/mailman/listinfo/nanocubes-discuss_mailman.nanocubes.net


_______________________________________________
Nanocubes-discuss mailing list
[hidden email]
http://mailman.nanocubes.net/mailman/listinfo/nanocubes-discuss_mailman.nanocubes.net




--
Alex Bongiovanni
University of Maryland



--
Alex Bongiovanni
University of Maryland
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Nanocubes-discuss] Drawing problems

laurolins
In reply to this post by Alex Bongiovanni
Maybe this is our fault and the pixel rows of the ‘tile’ API on 1.0 and master are inverted. The two options I see are either

y_array[i] = view.getUint8(record_size*i) << (8 - res)

or

y_array[i] = 255 - (view.getUint8(record_size*i) << (8 - res))

Test everything with res==8 first. I think you are almost there…


Lauro
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Nanocubes-discuss] Drawing problems

Alex Bongiovanni
In reply to this post by Alex Bongiovanni
Hasn't solved my problem, but I did notice that line 52 of tiled_pointset.js might be wrong, says:
(c1.y - c2.y) * (c1.x - c2.y));
But I'm guessing from the context of it that you want:
(c1.y - c2.y) * (c1.y - c2.y));


On Thu, Jan 30, 2014 at 3:51 PM, Alex Bongiovanni <[hidden email]> wrote:
It turns out that removing any subtraction altogether results in an upside down, problem free map.  Taking the negation of either the x or y values causes the problem to happen in the respective dimensions.


On Thu, Jan 30, 2014 at 3:41 PM, Alex Bongiovanni <[hidden email]> wrote:
It is more like, if you divide the map into rows (the number being based on how zoomed in you are), the rows become switched about.  Surprisingly, changing 
'y_array[i] = 256 - ((1 + view.getUint8(record_size*i)) << (8 - res));
to 
'y_array[i] = ((1 + view.getUint8(record_size*i)) << (8 - res)) - 256;
solves the problem, but gives me the map upside down.



On Thu, Jan 30, 2014 at 3:33 PM, Lauro Lins <[hidden email]> wrote:
Hi Alex,

I am not sure I understood the problem, but to me it seemed that the data tiles are upside down. If that is the case you can try inverting the “row” of the pixels sent on the ‘tile’ query. So if you have a pixel with row coordinate i, you use ii=255-i instead (this is considering that your tile is at full resolution: 256x256; if it is a coarser tile at 128x128, you would use ii=127-i instead and so on…).

Lauro


On Jan 30, 2014, at 1:41 PM, Alex Bongiovanni <[hidden email]> wrote:

I've now gotten most of the functionality of the 1.0 nanocube demo working with the master branch's cube (a very large thank you for that).  The problem that I'm now having is that things aren't drawing in the right position (but they are drawing!).  The problem is well-defined however, and is related to the zoom/coarseness.

If our original drawing can be defined as being composed of two halves:
|-----|
|  1  |
|-----|
|  2  |
|-----|
Then after one level of zoom (and it does actually display the refined points for the next level of zoom) what gets drawn is:
|-----|
|  2  |
|-----|
|  1  |
|-----|
This persists the further you zoom in; at the next level of zoom (if we now divide into quarters in a manner similar to how we split into halves) we get:
|-----|
|  4  |
|  3  |
|-----|
|  2  |
|  1  |
|-----|

I doubt the drawing code is the problem, as it is identical to the current code for the working BrightKite demo you have.  This makes me think that the tile data is either being processed incorrectly, or stored incorrectly.  Neither of these seem likely as the code for processing the tile binaries hasn't changed (as has previously been explained), and the code for storage (tile_pointset.js and tile_cache.js) is identical to the working versions in your demo.

I'm at a loss to what to look for (having now spend several hours trying to debug this) and was wondering if you had any ideas.

--
Alex Bongiovanni
University of Maryland
_______________________________________________
Nanocubes-discuss mailing list
[hidden email]
http://mailman.nanocubes.net/mailman/listinfo/nanocubes-discuss_mailman.nanocubes.net


_______________________________________________
Nanocubes-discuss mailing list
[hidden email]
http://mailman.nanocubes.net/mailman/listinfo/nanocubes-discuss_mailman.nanocubes.net




--
Alex Bongiovanni
University of Maryland



--
Alex Bongiovanni
University of Maryland



--
Alex Bongiovanni
University of Maryland
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Nanocubes-discuss] Drawing problems

Alex Bongiovanni
So the problem was that the tiles were being loaded properly, but requested and displayed in reverse order for the y-coordinate.  The fix was to change line 150 of index.js (view.js for your demos I believe) to:

var q = { tile: { x: x, y: (1 << zoom) - 1 - y, z: zoom },

This reverses the order in which tiles are loaded, which solves the problem.


On Thu, Jan 30, 2014 at 4:08 PM, Alex Bongiovanni <[hidden email]> wrote:
Hasn't solved my problem, but I did notice that line 52 of tiled_pointset.js might be wrong, says:
(c1.y - c2.y) * (c1.x - c2.y));
But I'm guessing from the context of it that you want:
(c1.y - c2.y) * (c1.y - c2.y));


On Thu, Jan 30, 2014 at 3:51 PM, Alex Bongiovanni <[hidden email]> wrote:
It turns out that removing any subtraction altogether results in an upside down, problem free map.  Taking the negation of either the x or y values causes the problem to happen in the respective dimensions.


On Thu, Jan 30, 2014 at 3:41 PM, Alex Bongiovanni <[hidden email]> wrote:
It is more like, if you divide the map into rows (the number being based on how zoomed in you are), the rows become switched about.  Surprisingly, changing 
'y_array[i] = 256 - ((1 + view.getUint8(record_size*i)) << (8 - res));
to 
'y_array[i] = ((1 + view.getUint8(record_size*i)) << (8 - res)) - 256;
solves the problem, but gives me the map upside down.



On Thu, Jan 30, 2014 at 3:33 PM, Lauro Lins <[hidden email]> wrote:
Hi Alex,

I am not sure I understood the problem, but to me it seemed that the data tiles are upside down. If that is the case you can try inverting the “row” of the pixels sent on the ‘tile’ query. So if you have a pixel with row coordinate i, you use ii=255-i instead (this is considering that your tile is at full resolution: 256x256; if it is a coarser tile at 128x128, you would use ii=127-i instead and so on…).

Lauro


On Jan 30, 2014, at 1:41 PM, Alex Bongiovanni <[hidden email]> wrote:

I've now gotten most of the functionality of the 1.0 nanocube demo working with the master branch's cube (a very large thank you for that).  The problem that I'm now having is that things aren't drawing in the right position (but they are drawing!).  The problem is well-defined however, and is related to the zoom/coarseness.

If our original drawing can be defined as being composed of two halves:
|-----|
|  1  |
|-----|
|  2  |
|-----|
Then after one level of zoom (and it does actually display the refined points for the next level of zoom) what gets drawn is:
|-----|
|  2  |
|-----|
|  1  |
|-----|
This persists the further you zoom in; at the next level of zoom (if we now divide into quarters in a manner similar to how we split into halves) we get:
|-----|
|  4  |
|  3  |
|-----|
|  2  |
|  1  |
|-----|

I doubt the drawing code is the problem, as it is identical to the current code for the working BrightKite demo you have.  This makes me think that the tile data is either being processed incorrectly, or stored incorrectly.  Neither of these seem likely as the code for processing the tile binaries hasn't changed (as has previously been explained), and the code for storage (tile_pointset.js and tile_cache.js) is identical to the working versions in your demo.

I'm at a loss to what to look for (having now spend several hours trying to debug this) and was wondering if you had any ideas.

--
Alex Bongiovanni
University of Maryland
_______________________________________________
Nanocubes-discuss mailing list
[hidden email]
http://mailman.nanocubes.net/mailman/listinfo/nanocubes-discuss_mailman.nanocubes.net


_______________________________________________
Nanocubes-discuss mailing list
[hidden email]
http://mailman.nanocubes.net/mailman/listinfo/nanocubes-discuss_mailman.nanocubes.net




--
Alex Bongiovanni
University of Maryland



--
Alex Bongiovanni
University of Maryland



--
Alex Bongiovanni
University of Maryland



--
Alex Bongiovanni
University of Maryland
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Nanocubes-discuss] Drawing problems

Carlos Scheidegger
Sorry for the confusion, and it's my fault.

IIRC this happens ultimately because  the WebGL "y" direction doesn't match the y direction of the map tile coordinates, so we had to do the coordinate matching somewhere. It obviously needs to be done in a clearer way.

-carlos

On Jan 31, 2014, at 11:37 AM, Alex Bongiovanni <[hidden email]> wrote:

So the problem was that the tiles were being loaded properly, but requested and displayed in reverse order for the y-coordinate.  The fix was to change line 150 of index.js (view.js for your demos I believe) to:

var q = { tile: { x: x, y: (1 << zoom) - 1 - y, z: zoom },

This reverses the order in which tiles are loaded, which solves the problem.


On Thu, Jan 30, 2014 at 4:08 PM, Alex Bongiovanni <[hidden email]> wrote:
Hasn't solved my problem, but I did notice that line 52 of tiled_pointset.js might be wrong, says:
(c1.y - c2.y) * (c1.x - c2.y));
But I'm guessing from the context of it that you want:
(c1.y - c2.y) * (c1.y - c2.y));


On Thu, Jan 30, 2014 at 3:51 PM, Alex Bongiovanni <[hidden email]> wrote:
It turns out that removing any subtraction altogether results in an upside down, problem free map.  Taking the negation of either the x or y values causes the problem to happen in the respective dimensions.


On Thu, Jan 30, 2014 at 3:41 PM, Alex Bongiovanni <[hidden email]> wrote:
It is more like, if you divide the map into rows (the number being based on how zoomed in you are), the rows become switched about.  Surprisingly, changing 
'y_array[i] = 256 - ((1 + view.getUint8(record_size*i)) << (8 - res));
to 
'y_array[i] = ((1 + view.getUint8(record_size*i)) << (8 - res)) - 256;
solves the problem, but gives me the map upside down.



On Thu, Jan 30, 2014 at 3:33 PM, Lauro Lins <[hidden email]> wrote:
Hi Alex,

I am not sure I understood the problem, but to me it seemed that the data tiles are upside down. If that is the case you can try inverting the “row” of the pixels sent on the ‘tile’ query. So if you have a pixel with row coordinate i, you use ii=255-i instead (this is considering that your tile is at full resolution: 256x256; if it is a coarser tile at 128x128, you would use ii=127-i instead and so on…).

Lauro


On Jan 30, 2014, at 1:41 PM, Alex Bongiovanni <[hidden email]> wrote:

I've now gotten most of the functionality of the 1.0 nanocube demo working with the master branch's cube (a very large thank you for that).  The problem that I'm now having is that things aren't drawing in the right position (but they are drawing!).  The problem is well-defined however, and is related to the zoom/coarseness.

If our original drawing can be defined as being composed of two halves:
|-----|
|  1  |
|-----|
|  2  |
|-----|
Then after one level of zoom (and it does actually display the refined points for the next level of zoom) what gets drawn is:
|-----|
|  2  |
|-----|
|  1  |
|-----|
This persists the further you zoom in; at the next level of zoom (if we now divide into quarters in a manner similar to how we split into halves) we get:
|-----|
|  4  |
|  3  |
|-----|
|  2  |
|  1  |
|-----|

I doubt the drawing code is the problem, as it is identical to the current code for the working BrightKite demo you have.  This makes me think that the tile data is either being processed incorrectly, or stored incorrectly.  Neither of these seem likely as the code for processing the tile binaries hasn't changed (as has previously been explained), and the code for storage (tile_pointset.js and tile_cache.js) is identical to the working versions in your demo.

I'm at a loss to what to look for (having now spend several hours trying to debug this) and was wondering if you had any ideas.

--
Alex Bongiovanni
University of Maryland
_______________________________________________
Nanocubes-discuss mailing list
[hidden email]
http://mailman.nanocubes.net/mailman/listinfo/nanocubes-discuss_mailman.nanocubes.net


_______________________________________________
Nanocubes-discuss mailing list
[hidden email]
http://mailman.nanocubes.net/mailman/listinfo/nanocubes-discuss_mailman.nanocubes.net




--
Alex Bongiovanni
University of Maryland



--
Alex Bongiovanni
University of Maryland



--
Alex Bongiovanni
University of Maryland



--
Alex Bongiovanni
University of Maryland
_______________________________________________
Nanocubes-discuss mailing list
[hidden email]
http://mailman.nanocubes.net/mailman/listinfo/nanocubes-discuss_mailman.nanocubes.net

Loading...