Snapping doesn't work well with low resolution terrains.

[mihakrajnc]

I have a TerrainFactory with a 2x2 resolution (for a low-poly look) and the terrain snapping for roads doesn't work well in this case:

As the snapping modifier uses the height data of the terrain for snapping it works fine in cases with a high resolution terrain, but fails with low resolution.

Not sure what the fix for this would be... Worst case raycasting, best case, using the terrain resolution and some black magic to figure out the actual height of the terrain mesh?

My "workaround" for this was to use a map image factory with a custom style (that only includes roads) and retina resolution turned on, to get some feeling of roads, but I'd like to have them as meshes in the long term.

Using the latest develop: 61d740b

[brnkhy]

Hey @mihakrajnc, as you noted, default behaviour is to read from height data directly instead of doing raycast which would be a lot more expensive. Intended usage is to have the highest resolution you can for terrain and since it's quite low weight as it's only vertices anyway.
Are you looking for something like; https://twitter.com/brnkhy/status/867754134736429056 ? If that's the case, we'll probably release that low poly terrain factory soon.
Otherwise, a raycast solution would be the most straight forward one I guess but since it's not a common case, we probably wouldn't use it over raw data querying.

[mihakrajnc]

That's exactly what I'm looking for! So far I've been doing the recalculations myself to modify the vertices and normals for that low-poly look, but it would be awesome to have it integrated.

However won't that factory have the same problem? Snapping will still happen to the height data, and but the terrain will be low poly?

[brnkhy]

@mihakrajnc ah yes, you're absolutely right, that terrain will have it even worse. Actually the ultimate solution is to cut terrain to create roads and stuff but that's a low performance solution so we didn't prioritize it.
a trick to fix that would be rendering terrain and roads in different cameras. but then you'll have problems with buildings as well so you probably will need to render that in a different camera as well. So a three camera setup, going like building->road->terrain (top to down) would work. I used this trick for a while and looks quite good if you have a top down camera and won't go too close to terrain.

[brnkhy]

@mihakrajnc actually, let me correct that; low poly terrain in those shots are exactly same as the normal terrain (resolution wise) but have different shading. So snapping to terrain issue will be exactly same as the normal terrain, not any better or worse. With somewhat high resolution and a little height on roads, it'll probably stay on top of terrain most of the time.

[brnkhy]

@mihakrajnc OK one last thing, have you tried SmoothLineModifier for your roads? It goes before everything in stack and increases road data resolution so it snaps better on terrain. Might worth giving it a shot as well.

[david-rhodes]

@mihakrajnc And by all means, if you need to raycast to obtain your height data, please do so. You could build your own version of SnapTerrainModifier that uses raycasting, instead of height query from UnityTile. Something like SnapTerrainRaycastModifier? You could use the terrain layer option as a raycast mask.

[mihakrajnc]

@brnkhy Well, depending on what kind of low-poly look you're going for, the problem can still be there. If you want a really low poly look (which needs a low resolution terrain) the problem is still there.

@david-rhodes I tried it with Raycasting and the results are looking good!

I also tried a SmoothLineModifier and got better results in some cases. Still have to check the performance of this stack on mobile devices, but as the only impact will be when loading the map for the first time, it should be ok IMO.

Here is the SnapTerrainRaycastModifier if anyone wants to use it!

I'm not a huge fan of FindObjectOfType<AbstractMap>().WorldRelativeScale but I couldn't find any other way of getting the scale...

[brnkhy]

@mihakrajnc that shot looks really awesome! As long as it satisfies your performance needs, I guess this is the way to go in your case. Thanks a lot for the script as well, I'll try it as soon as possible!

[david-rhodes]

@mihakrajnc This is awesome!

I'm not a huge fan of FindObjectOfType().WorldRelativeScale but I couldn't find any other way of getting the scale...

I bet you could cache the IMap object or the WorldRelativeScale value in UnityTile, which is already passed into the MeshModifier.

Also, instead of serializing the string of the layer, you could use LayerMask.

[mihakrajnc]

Ahh, LayerMask, I knew there must be a better way, thanks, I updated the gist.

I also added an IMap property to UnityTile, to get rid of that nasty FindObjectOfType<>() call, good idea! This could probably be added to the official API, as IMap has some useful properties that can be used in custom modifiers...

P.S. Thanks for all the help guys 👍

[david-rhodes]

@mihakrajnc We'll probably add the IMap property soon to UnityTile. The plan right now is to separate IMap into IMapReadable and IMapWriteable to keep separation of concerns. Modifiers want to read map aspects, but we should not expose writeable values (zoom, location, etc.).

[david-rhodes]

@mihakrajnc Thanks again: #110.