I’m using the Navmesh Components that are available on Unity’s GitHub. My current workflow (using Polaris 2020) is building a terrain, adding a Navmesh Surface component, baking, reviewing, editing, re-generating etc. That said I really want to use Tycoon Tile if I can.
For Tycoon Tile it might be something along the lines of extending the Editor demo to build and save levels, then load the level data into my project. With the terrain now visible in the Scene view I’d then apply a NavMeshSurface component and bake the mesh. One challenge is figuring out how to exclude certain areas from the NavMesh. Typically you’d do this using a NavMeshModifer and assign it as non-walkable. A good scenario is where you might have a hill and you only want the navigation available up a certain side of the hill. The slope of all the sides of the hill will be the same (assuming you’re not using cliffs) so you’d want to exclude the other sides of the hill somehow. I haven’t figured out how to do this yet…
Hopefully this makes sense - can add pictures if needed
Thanks for your reply. I think I understand your workflow, although I am not yet sure whether I understand the NavMeshModifier use-case yet. I have done some researching for how the Navmesh Components work and how they should be used, but my guess is that an end user would probably want to have this control on a per-tile basis instead of having to define each volume separately? I will probably have to create a plugin/separate for Tycoon Tile which generates the appropriate meshes to be used as sources for the navmesh builder. This seems doable, but I am not yet sure how users should define what areas are reachable for navmesh agents and which areas are not.
I would be interested in your use-cases and/or examples for excluding specific terrain areas for the navmesh. Could you give me some examples of game mechanics that you are trying to implement? Is this dependent on tile type of a given tile? Do you want to designate specific tiles to be unreachable?
Using a NavMeshModifier would allow us to associate navigation penalties with different parts of the terrain. However it comes at the expense of having to break the terrain up into as many components as you needed modifiers for (at least as far as I understand). There would be a considerable amount of work involved from a UI perspective to allow the user to mark certain navareas as water, lava etc and then break those up into individual mesh objects. I suspect it’s not worth the effort initially, particularly as development effort spent is always a factor of sales and demand for the feature (a perfectly reasonable perspective).
My use case is not so much building a tycoon-style game as generating a (more or less static) terrain for use in a “real time skirmish” game. I want to exclude certain parts of the terrain completely from navigation and also have speed costs associated with terrain types so that it’s slower to traverse over snow or mud than it is grass. I can partially achieve this by querying the terrain, getting the terrain type and modifying the NavMeshAgent speed depending on what the agent is over. This comes at the expense of navigation being somewhat dumber as everything on the terrain will have the same cost from the navmesh agent perspective.
Here’s an in-game example. Picture a 4-sided hill with a plateau on top I’ve made by raising the terrain in TycoonTile. The top of the plateau might contain some contested item wanted by both sides. I want to mark 3 of the sides as un-navigable and use the 4th side as the entry/exit path. Given our WorldStepHeight we know the maximum slope of any given terrain tile and adjust the navmesh agent Max Slope property accordingly. If I’m not wrong, with a WorldStepHeight of 1, the maximum slope is 45 degrees? The nature of TycoonTile means the slope angles are the same on all sides so the challenge is how to indicate the other 3 sides of this hill are un-navigable (as default navmesh generation would include all sides).
So how might we achieve this? If we modify the demo so we can paint a navigation layer, we could re-use a significant portion of code and also track what is navigable and what is not. The when generating the triangles from the raw data, we skip adding triangles previously marked as un-navigable. This kind of touches on the other change I suggested about being able to apply individual textures to the 4 triangles in each quad, as you’d get a much smoother boundary definition for the navmesh too. The end result would be a mesh that has the sides of hills and cliff faces missing or empty, and just those areas we want navigable included. This is what we’d need to feed into Unity’s navmesh system (but I haven’t figured out how this works yet).
By the way - I did some more experimenting with NavMeshVolumes last night and couldn’t get them to work at all.
Thank you for elaborating on your use-case. Unfortunately I don’t think this will be a simple addition or modifcation to the way Tycoon Tile works at this moment, especially if you also want to define navmesh inclusion for each tile triangle separately. If you intent to use the terrain as a static mesh anyway, I would suggest exporting the generated mesh during runtime to an external mesh format like fbx or obj. Tycoon Tile will generate a submesh per tile type. After exporting you could then edit your mesh in some modeling software like blender to remove unnecessary parts of the tiles. Then use the edited mesh as input for the navmesh components to get your final navmesh.
Totally understand your perspective and your workaround suggestion makes sense. First thing I’ll try tonight when I get home is using GameObject > Export to FBX and see how I go.
I didn’t manage to get too far with the mesh export. I tried using the standard (well preview from memory) Unity FBX exporter as described here but when I opened the mesh in Blender I didn’t see anything. That said, I’m not a Blender user so I might have needed to switch render modes or something.
So for now I’ve abandoned using TycoonTile until either I can get the export working so I can remove the unused faces in Blender and then re-import for my NavMesh, or you can help me with the export process.
That is unfortunate to hear. I suspect the problem you are experiencing with Unity FBX Exporter is due to the Tycoon Tile renderer storing and rendering the meshes internally, instead of spawning child GameObject with a MeshFilter and setting these mesh filters. The exporter is probably scanning for MeshFilter components and only exports meshes assigned in these components. You could try adjusting the renderer to spawn objects with a MeshFilter component instead and apply meshes to these filters. Then you can probably use the FBX exporter.
Version 1.3 is a big update that comes with API improvements across the board. The major new features are support for multi-tile placement of buildings and structures, as well as support for locking tile heights.
Version 1.3 includes the following features:
Revamped terrain operation API
Terrain operation is now a two-staged process. Operations schedule modifications instead of directly applying changes, to improve orchestration of tile updates.
Adapted all included terrain operations to the new API.
Added ability to ‘lock’ tiles.
Standardized tooling API to simplify implementation of custom tooling.
Simplified code of included tools and adapted to new tooling API.
Added utility classes for terrain overlay rendering and preview object rendering.
Added base renderer class to simplify implementing custom terrain renderers.
Adapted standard renderer to new base renderer API.
Added support for multi-tile object placement (constructables).
Added new builder tool to place multi-tile structures.
Extended demo scene to showcase building tool.
Moved some classes to other namespaces and file locations to tidy up API surface.
How hard would it be to modify the scripts so that surrounding tiles are updated when a vertex is raised/lowered? For my game, I would like the surrounding quads to also update when you raise or lower a corner. That is, instead of making a cliff when one corner is raised, the surrounding tiles recalculate their triangles according to the new vertex height.
If I understood your feature wish correctly, this is already possible and implemented with the included scripts. In the included demo scene (or the online web demo), you can select the smooth terrain editing mode in the terraformer tool to do this.
By dragging the highlighted selection upwards, it will create a smooth terrain in neighbouring tiles:
This tool uses the DecreaseHeightSmoothConnectedOperation and IncreaseHeightSmoothConnectedOperation operations to accomplish this.
If you have any further questions, please let me know!
Thanks for the quick reply. What I mean was similar to what you are showing, but when only selecting a single vertex on the “corner” of a tile.
In this image you can see how the one vertex is raised, but the tiles around it do not recalculate their triangles to match, as if they are not sharing a common vertex in that corner.
Ah I see. This should be easy to accomplish by making a new terrain operation or by modifying the standard one. The TileHandle and CornerIndex classes contain some helper functions to easily access neighbouring tiles and/or tile corners. If you need specific details I’d be happy to assist!
Hi,
I’m considering to use this asset.
But I have a question. How complicated is it to add Tiles which support tunnels?
And can I use your tile grid to easy implement a node based pathing algo?
Thank you!
The mesh generator is an isolated part of the package, which makes it easy to customize for your own needs. As long as you know which ‘tile positions’ and which side/direction of the tile requires a tunnel, you could simply skip generating triangles for that cliff or surface or generate a different mesh there. I don’t expect you to run into specific problems here, but it depends on your specific requirements I guess.
There is no explicit support for node based navigation built in, but using terrain operations makes it very easy to query the tile grid and ‘navigate’ through the grid by the tile neighbors and positions. I have also seen some customers integrating the Unity navmesh system with success, if that is what you are looking for. Again, this depends on your specific requirements and game rules, which is why there is no built in and standard solution for this within the product. Tycoon Tile does aim to provide an easy to use API surface which is also easy to extend, such that these features can be implemented as desired.
I hope this helps! If you have any further questions, please let me know!
At this time, Tycoon Tile does not support infinite dimensions within the same terrain object. You can however define quite large terrain objects and use multiple objects within the same scene. Working out cross-object modifications or placements however would require some extra effort to work correctly, but is certainly doable.
The demo scene comes with a procedural terrain generator included. You can customize this generator to your desire.
I have some question for you.
Are you planning on making further update on this asset? And if the answer is yes do you have any idea when?
Also one of the shader stops working on the new Unity versions. Do you have any idea why? (TerrainGridShader). There is no direct errors but it’s rendering pink.
