I built a 3d model of a city in the UK, using OSM2World which generates a .obj file from some .osm map data. Pretty sure the map data is all accurate. Have emailed the osm2world developer to see if maybe something goes wrong in the model creation, as the problem I’ve got is that vehicles driving around are in some places in the wrong place by maybe 1m-2m.
The vehicle positions i’m pretty sure are right - if i plot the xy positions they go to into google earth, they’re all pretty much bang on in the middle of the road.
So, what I’d like to check, is if anyone has ever seen any inaccuracy creep in from the stage of the j3o being converted, through to the model being loaded, with a rotatation and setLocalTranslation…
I think i’m clutching at straws, but gotta check. In the meantime, i’m looking for some sort of inaccuracy in coordinate conversion, as I’m doing some UTM to lat long which could introduce the sort of inaccuracy im seeing if theres some rounding somewhere. But… I haven’t found any yet!
how big is your map?
Jme uses floats and with big distances you can have precision issues. If your cars are very far away from the world origin I guess you can have this kind of precision loss.
Well the total map is only covering a reasonably small town… we’re talking less than 2000m. I had zero’d around a specific point, to initially make things a bit more readable and keep the numbers small, but I’m just in the middle of converting it all to using UTMs, so a couple of doubles like 544482, 5692044. I can afford to lose some accuracy after the decimal point, so hopefully should all be ok. Plus it’ll let me test a bit better whether the number being sent around are what I’d expect.
that didn’t make any difference… apart from giving me a headache converting all the coord system and camera angle stuff. also, i seem to only be able to go up in 0.5 increments with the larger (5692044.0) number. So, i’m scraping that and going back to a nice zero’d center and small number
on the plus side, i could output the xy of points being drawn, and paste them into google maps, and they’re all definitely right, so nothing getting lost in the middle.
Example of the problem is here - this is an example of the worst case, where about 1000m south-west everything is lined up properly. Seems to get worse the further you drift out to north-east, rather than being constant. But I dont think its a big enough distance for UTM - latlong elipsoid / earth curvature stuff to kick in?? Apart from that, im pretty much out of ideas… I think jme is doing everything right at least, and if no-ones seen issues with .obj->.j3o before then I think it must be the .obj model itself!
<cite>@vinnieb said:</cite>
Hopefully another coffee will fix the problem..
If only it were that simple ^^
<cite>@vinnieb said:</cite>
I think jme is doing everything right at least, and if no-ones seen issues with .obj->.j3o before then I think it must be the .obj model itself!
Have you tried loading the .obj file directly if you think it may be the .j3o?
Well its back to the drawing board for me I think. Tried loading the .obj file, and get the same issue. Tried regenerating the obj file too, and in that apps GUI, setting camera location to the problem area appears in the right spot.
Anyway, its looking less and less like anything to do with the j3o / jme side of things at least
Changing the origin won’t help. And the size only make sense in JME world units. 2000m can be ok if 1m = 1 world unit.
Loosing accuracy after the decimal point can mean loosing meters to some extends. That’s why your cars are not in the center of the road.
A float only has 32 bits… but only some are used for the decimal places. You can have really big numbers that are not very close to each other or really small numbers that are all close to each other… but not both at the same time.
It might be worth reading up on how floats are stored to give yourself a deeper background on the issue.
