I cannot seem to be able to get a range image (if I visualize it I just see a black dot/square).
I am using a point cloud I generated, that has around 5K points. Following the instructions at http://pointclouds.org/documentation/tutorials/range_image_creation.php and getting the affine matrix from the viewer, after I reset it to look at the cloud, which is positioned at the origin.
Could it be a view position problem?
Related
Im generating a map proceduraly with isometric autotiles. Each tile has its navigation poligon defined in the Tilemap editor. The Navigationmesh is working fine. The thing is that the map I generate is bigger than the actually playable area. I dont want the human player to see the borders of the map, the "black background". So I'm limiting the camera view movement. Therefore, the navigationmesh goes outside of the playable area, like in this image:
I'm using pathfinding to move the player character. Since the map is generated proceduraly, sometimes it generates a map where the path to a point goes outside the playable area an then comes back in order to reach its destination. Like this:
A player in O would go outside the playable are to reach X. In X could be a point of interest, so if this kind of map is generated, I would simply regenerate it until i get a feasible one.
I'm using GODOT 3.51.
I have think about:
Carving a hole in the navigation mesh on the borders of the playable area using clip_polygons(). BUT since im using autotile navigation, it is very hard to get the navigationpoligoninstance. I have tried this but failed miserably.
-Adding NavigationObstacles on the borders: Hadn't tried this, but as far as i understand from my research, this will not avoid the agent to generate the path to the destination.
My idea is to achieve that no path goes out of the playable area and then check is the map is feasible by checking if all points of interest (randomly spawned) are reacheable. This is done by cheking the last point of every path to interest points from the starting point an seeing if it is equal to the point of interest position.
I hope this is understandable. Sometimes I dont understand myself.
What comes to mind is to use two versions of the tiles. One that is not passable which will be used to generate the areas that the players should not be able to reach. And the regular one used for the playable area.
The Google API map scale used to always show both meters and imperial units (ft or miles).
Now when a map opens the scale is always only in meters. If you click the actual scale image, you can toggle it to imperial units. Not exactly intuitive and certainly a nuisance.
Anyone know how to tell the API to display a scale with types of units? My server log shows users hitting my app from around the world.
BTW, setting google.maps.visualRefresh = false;
does nothing. The scale is now always part of the stuff in the lower right corner.
Edit: I just noticed that https://maps.google.com/ displays a nice scale with both mi and km.
Edit: No, not a duplicate. My users in the USA want the scale to show mi and ft. My users in other counties mostly want the scale to show m and km. Since plain old Google maps shows both types of units on the scale, I am hoping there is a way to display a scale with the API that has both types of units. Meanwhile, at least I can change the default to imperial via the hack in the other thread.
I've got quite strange google earth plugin behaviour. I get the camera position from the plugin to create some KML with coordinates, then I store it in database. When I reload the page, then it reads the kml, inserts it inside some other string - as a result I've got a string with whole kml document inside my javascript code. Then I load it into the plugin. Usually everything works, however after loading I see two things:
The coordinates returned by the API are not the same I have in the kml I'm loading
The camera position is sometimes moved a little bit, which causes errors like: I've got a camera inside a building, and after a couple of page refreshing, the camera suddenly is outside the building.
Do you have any hints how this could be fixed?
Example:
I've created a document, and inserted this camera tag inside:
<Camera>
<gx:ViewerOptions><gx:option name='streetview'></gx:option></gx:ViewerOptions>
<longitude>2.1201209999999993</longitude>
<latitude>48.80452499999986</latitude>
<altitude>2.4999999991174264</altitude>
<heading>22.795249807940547</heading>
<tilt>82.25987544961218</tilt>
<altitudeMode>relativeToGround</altitudeMode>
</Camera>
Then I loaded it into the plugin, and asked to fly there. When it stopeed flying, I got the coordinates using copyAsCamera() and the latitude was changed to 48.8044078508718.
The difference is not huge, just 0.000117149 but as a result it is showing a totally different place (a different room in the palace.
I'm trying to get exactly the same place, as written in the coordinates.
I have rewritten the answer to cover the various points you have made and the example you have provided.
street view
The KML data is setting <gx:ViewerOptions> to enter street view mode based on the camera. The key words being based on - a street view is an approximation. Things like the camera tilt and heading are no longer applicable as they are replaced by a SteeetView POV object. Further to that you can't guarantee that a camera at any given latitude and longitude will actually enter street view at the same given latitude and longitude.
relativeToGround and terrain data
Using altitude mode relativeToGround can cause the issue you are seeing. This is because the terrain data hasn't always finished streaming when the relatively positioned element (in your case a camera) is added.
To be clear you should use <altitudeMode>absolute</altitudeMode> and ge.ALTITUDE_ABSOLUTE.
The example you provided uses both <altitudeMode>relativeToGround</altitudeMode> and ge.ALTITUDE_RELATIVE_TO_GROUND.
You could also try disabling the terrain data by turning off the terrain layer, i.e.
ge.getLayerRoot().enableLayerById(ge.LAYER_TERRAIN, false);
multiple viewchangeend events
The viewchangeend event may fire in the middle of a viewchange, especially if the plugin pauses for a brief period during the change. Your markup is triggering street view mode which causes this to happen.
You can resolve this by using setTimeout to throttle the viewchangeend event like so.
var timer = null;
google.earth.addEventListener(ge.getView(), 'viewchangeend', function(){
if(timer){
clearTimeout(timer);
}
timer = setTimeout(eventHandler, 100);
}
);
see: https://developers.google.com/earth/documentation/events#event_listeners
Tilt discrepancy
The plugin automatically "swoops" at ground level so that it moves from looking straight down (0 degrees tilt) to straight along the horizon (90 degrees tilt). This is what is causing the discrepancy in the tilt value in the view. You are viewing objects at ground level and so the view is being automatically set - this can't be disabled.
Storing and outputting KML data
Take a look through this document, it gives some really good information of storing coordinate data and covers points like the one I mentioned - A Database Driven Earth App.
.
I need a polygon for every German state. I go all the GeoPoints in one JavaScript-file but the file is because of the amout of points about 4MB. I've been googling and thinking about this problem all day but couldn't figure out a solution...
How can I use Google Maps polygons without forcing the user to download a huge js-file with the coordinates?
Thanks!
Ron
You can encode the polygon points to vastly reduce the size of the javascript file. To do this, you must include the geometry library.
https://developers.google.com/maps/documentation/javascript/reference#encoding
https://developers.google.com/maps/documentation/javascript/geometry#Encoding
One option is to use a FusionTablesLayer to display the polygons. They are available in the Natural Earth data set that is publicly available.
Example
You could do the same with your points and a KmlLayer if you convert your data to KML.
Well... somehow the points have to get to the user. You could think of the following solutions to reduce the data usage:
Use different polygons for different zoom levels. For example zoomed out you won't need the full details.
only send parts of your polygon back to the user. You can for example send the viewport coordinates to an AJAX script. This one queries your database and/or shapefile and only returns the polygon parts that are visible in the user's viewport
preprocess tiles. If you can generate images from your shape, you can overlay these on Google Maps.
We need to build a model of the shop floor in which we can relate pixel coordinates(x, y) from
camera images to the actual objects in the 3D space of the store. The camera images, which will act as sources for generating such a model, suffer from fish-eye distortions. Hence straight lines actually appear as curves in the camera images and the walls appear to meet each other at not exactly right angles.
We are sub-dividing the region into polygons. Each polygon on the image refers to a particular region such as a shelf, display area, checkout counter etc. By mapping the pixels that fall in each polygon, we want to relate it as belonging to the shelf corresponding to that region.
Any ideas how to go about it?
Following is a sample image of the store with some polygons marked:
EDIT:
We are not looking to find out the 3D coordinates, we just need to know which shelf is any polygon mapped to. So if the user clicks on a polygon, we can say he clicked on which shelf.
We are able to manage the above for big polygons like the ones shown in the image, but the shelves away from the camera can be as small as a few pixels so we need some kind of a probabilistic result saying if the user clicked at (x,y) what is the probability that he was trying to click on Shelf-A or what is the probability that he was trying to click on Shelf-B and so on.
Basically, what we are looking for is a probability function which would return the probabilities of click on nearby objects when a small polygon(or a pixel) is clicked on the 2D image.
EDIT2:
One thing which is not apparent from the sample image is that the polygon size could be really small(as small as a few pixels) and polygons in turn could be really close to each other.
Moreover, the use case is that a customer in the store picks a product from one of the shelves. The application user would click on a point in the image from which he thinks the products is picked up. Now since the polygons are so small and so close, the user can only guess the exact point of pickup, so we can only know at best that it could be any one of the 3-4 polygons close to the point of click. So the question is how to calculate probabilities for these 3-4 polygons given the click?
As suggested here distance of the click from the center of polygon and its area could be parameters in calculation of this probability, what I am wondering is if there is algorithm to do so.
We are not looking to find out the 3D coordinates, we just need to know which shelf is any polygon mapped to. So if the user clicks on a polygon, we can say he clicked on which shelf.
I assume you have a mapping from polygon to shelf name. For example, as a list of pairs (polygon, shelf name). You can make it by hand once, if the cameras are fixed and don't move. Then your problem is only finding which polygon does a point belong to.
If you use OpenCV, then you can use its PointPolygonTest function. Otherwise you may write a similar function yourself. See, for example, a Ray casting algorithm. Then look through the list until you find a polygon which the point lies withing.
To further optimize the program you may precalculate polygons' extents. An extents allows you to quickly say when the point is definitely not inside the polygon, and consider only the remaining polygons. But with so few polygons as you have in the image, I would not bother.
Basically, what we are looking for is a probability function which would return the probabilities of click on nearby objects when a small polygon(or a pixel) is clicked on the 2D image.
Just run an experiment, try to click a single highlighted pixel, accumulate some statistics on where the operator does actually clicks. Once you have this, it's easy to predict the number of out-of-object clicks and how far they are likely to be off.
Without such experiment with exactly the same kind of person, the same usage conditions and the same pointing device you are going to use, you cannot really tell how much off the clicks are going to be. I believe that many people are sniper clickers if the mouse is good and they can see the image well. If they are forced to use touch interface or some other pointing device, the precision may be lower.
Few comments
fish eye can be corrected by applying some transformations to the image, see for example this page for some resources including panotools
to get the 3D coordinates only and image from one camera is not enough, additional info is necessary
marking a same point on two images of the same scene from different cameras can give you full 3D info (you do need to know position of each camera relative to each other)
if you are looking for tools to do it, see https://superuser.com/questions/30053/is-there-any-free-open-source-software-that-converts-photos-to-3d-models
EDIT
After update to the question, assuming there already exist a set of polygons and you want to eliminate user errors (or improve precision) you might
try to guess the desired click polygon by calculating distance to centre of weight of polygons close to click
use visual cues (flash the polygon selected and require second click)
collect statistics on errors and for certain polygons require validation
What you want is a space-filling-curce for example a Z-Curce or a Hilbert-Curve. A space-filling-curve sub-divide the plane into smaller tiles and reduce the complexity of 2-Dimensions into 1-Dimension in a way that each tile get's a new order. What might interessting for your problem is that the Hilber-Curve traverse the plane not in binary order but it use a gray code so that every tile is different in 1-Bit from the other tiles. That makes it easy to decide whether the user has clicked this or that object.