Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Map Layer Features Not Always in The Right Place #1587

Closed
highpockets opened this issue Apr 7, 2020 · 6 comments
Closed

Map Layer Features Not Always in The Right Place #1587

highpockets opened this issue Apr 7, 2020 · 6 comments

Comments

@highpockets
Copy link

highpockets commented Apr 7, 2020

Note: If this is a bug or support ticket, please provide the following information:

  • Unity version: 2019.3.5f1

    • Scripting Runtime Version: .NET 4.6

    • Scripting Backend: IL2CPP

    • Api Compatibility Level: .NET Standard 2.0

  • Mapbox SDK version: 2.1.1

  • The platform you're building to: iOS/Android

  • A description of what you're trying to do:

Adding a Mapbox Streets V8 map layer with roads so we can have mesh colliders on roads. Everything is ok when initializing the map/starting the game. The 'Extent Options' is set to 'Range Around Transform', thus after moving the target transform, tiles start to appear in the direction that the transform moves and the textures and road meshes appear in the new positions, but on a lot of those tiles, there is extra road mesh from, what I assume is, the previous position of the tile.

So, I tried to track down where the tiles were being redistributed and I found myself inside the AbstractMapVisualizer at the LoadTile() function, line 225. I tried to check the unityTile for children and if the tile has children, Destroy() those child objects, but that appears to be Destroying some of the new children as well:

                 public virtual UnityTile LoadTile(UnwrappedTileId tileId)
		{
			UnityTile unityTile = null;

			if (_inactiveTiles.Count > 0)
			{
				int _childCount;
				unityTile = _inactiveTiles.Dequeue();
				_childCount = unityTile.transform.childCount;

				if( _childCount > 0)
				{
					for(int i = _childCount - 1; i >= 0; i--)
					{
						Destroy(unityTile.transform.GetChild(i).gameObject);
					}
				}
			}

Here is an image to help see the issue. The pink lines are the roads that I have defined in the Map Layer features. You will notice that all streets are defined except for the primary's, trunks and motorways along with bridges which is what we want, but there are additional pink roads in random spots, like crossing the river for example.

Screen Shot 2020-04-07 at 4 50 25 PM

  • Steps to recreate the bug if appropriate:

Steps mentioned above...

  • Links to your logs are also helpful:
@highpockets
Copy link
Author

After looking into it further, it also appears that some of the features are duplicated on a tile when the tile goes out of view and then I come back to it. So the tiles end up having multiple children as just one feature can be repeated more than once

@highpockets
Copy link
Author

Maybe you guys are not working because of the corona virus. Though we really would appreciate your attention on this as soon as possible because it has been holding up development. I have been trying to work on other things, but this issue is really at the center of a key feature for the app..

@highpockets
Copy link
Author

I came across this issue (#1537) which seems to be similar and I tried the fix mentioned, but it doesn't work. After applying the fix, my map looks like the following screen shot:

Screen Shot 2020-04-09 at 4 10 35 PM

Red lines indicate dangerous roads, pink lines are all other roads and the blue is water (a river in this case). As you can see some tiles still have lots of random mesh data, including portions of rivers that are out of place and roads going crazy.. On top of that, while some of the road mesh is loading properly, most of the mesh sections that are in the right place have 1 or more clones in the same spot..

@brnkhy
Copy link
Contributor

brnkhy commented Apr 13, 2020

Hey @highpockets!
I think this might be due to some mesh leaking issue we experienced lately as well. We merged a few fixes for that into the dev branch and there's one I PRed just last week here;

#1582

and this is the old one in case you don't want to pull dev;
#1539

Can you apply those two (very small 1-2 line changes) and see if it helps? It should prevent mesh leak issues altogether.

@highpockets
Copy link
Author

Thanks @brnkhy , works beautifully..

@Markovicho
Copy link

Hey @highpockets!
I think this might be due to some mesh leaking issue we experienced lately as well. We merged a few fixes for that into the dev branch and there's one I PRed just last week here;

#1582

and this is the old one in case you don't want to pull dev;
#1539

Can you apply those two (very small 1-2 line changes) and see if it helps? It should prevent mesh leak issues altogether.

Can't confirm this fix is working. Please refer to this cross-related issue :
#1698

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants