Every docs URL answers with Markdown when you add .md. Site map: llms.txt
YNV Navmesh Viewer
Open a GTA V .ynv navmesh over the real map and in 3D, colour the polygons by flag, inspect one polygon, and see which neighbouring cells its edges point into.
Deze docs zijn voorlopig in het Engels.
The YNV Navmesh Viewer opens a .ynv file and shows you what is in it: the polygons peds walk on, drawn over the real Los Santos map and in the 3D world, coloured by what the flags say each one is.
Everything runs in your browser. The file is never uploaded, and no game file is shipped with the page: you open your own.
This is a viewer. It does not write a .ynv, and that is deliberate. The reasons are on the page and in The navmesh at runtime.
Getting a file to open
You need a .ynv out of your own GTA V install. Extract it with CodeWalker or OpenIV.
The box at the top of the page finds the right one for you. Type a world position into World X and World Y and it gives you:
- the file name, ready to copy;
- the cell and the area id;
- the square the file covers;
- how many polygons, portals and cover points it holds, and how big it is;
- the archive folder to extract it from.
A cell is 150 metres square. The file name counts in 50 metre units, so navmesh[123][102].ynv is cell 41, 34.
Then drag the file onto the drop area, or press Choose a file.
The Map tab
The polygons are drawn over the game’s own map tiles. Pan with a drag, zoom with the wheel or the buttons. Click a polygon to select it and read it in the panel on the right.
The Colour key panel is also the layer switch. Click a row to hide that layer; the count beside it is how many polygons of the file it is. A polygon often carries several flags at once, so it is drawn in the colour of the first layer in the list it matches, which is why the counts add up to the whole file exactly once.
| Layer | What it means |
|---|---|
| Water | The polygon is over water. |
| Shallow water | Water a ped can wade in. |
| Train track | Rails. |
| Road | Carriageway. |
| Footpath | Pavement and walkways. |
| Interior | Inside a building. |
| Underground | Tunnels, metro, car parks. |
| Steep slope | Too steep to walk normally. |
| Flat ground | The commonest flag in the game. |
| Plain ground | No flag of the above is set. |
Two more switches sit under the key:
- Portals draws a line from one side of each portal to the other.
- Cover points draws a dot per point with a tick showing the direction it faces.
- Cell grid and neighbours outlines the file’s own 150 metre square in white, and outlines every neighbouring cell its edges point into in amber with the edge count on it. That is the quickest picture of the thing the Neighbours tab counts.
The 3D tab
The same polygons in the real world, over the game’s own geometry. Hold the right mouse button to look, W A S D to move, and click a polygon to select it. Look at the cell puts the camera back over the file.
The layer switches and the selected polygon are shared with the Map tab, so you can flip between them without losing your place.
Draw through walls is on by default. The navmesh is on the ground, so from any angle worth looking from most of it sits behind a building. Turn it off when you want the mesh occluded correctly, for example to check that a polygon really is inside a room.
Tip
The 3D view is where a navmesh problem is usually obvious. A staircase with no polygons on it, a bridge whose deck is missing, a building interior with nothing inside: all of that reads instantly in 3D and not at all from above.
Reading one polygon
Select a polygon and the panel gives you everything the file stores for it.
- Vertices, first index, area id, part id, centre. A polygon’s ring is a run of indices into the file’s shared vertex list.
- Flags. The three words in hex, then every bit that is on, with the real name where there is one and the bit number where there is not. Nothing here is a guess:
PolyFlags2bits 0 to 15 are set on plenty of real polygons and nobody has established what they mean, so they are listed as unknown. - Stored cell box. Six signed shorts in 0.25 metre units. It looks like the polygon’s bounding box and it is not one. The panel prints it next to the ring’s real extent and says whether it contains it, because almost never does. Read it as a loose hint, not a bound.
- Portal links. If the polygon is on a portal, the portals it names and what each one joins.
- Edges. Expand this for a row per ring slot: the two edge parts, the area each names, the polygon index on the other side, and the two fields whose meaning is not established. Amber means the polygon named is in a different file.
The Neighbours tab
This is the tab worth understanding even if you never edit anything.
An edge in a .ynv names the polygon on the other side by an area id and a polygon index. Where that area is a different cell, the index is a position in the neighbouring file’s own polygon list. The tab counts, for the file you have open:
- how many edge parts there are in total;
- how many have no neighbour at all;
- how many point inside this file;
- how many point into another file, and which files, with a count each.
It also prints the file’s adjacent area table, which is the 32 entry list an edge’s 5 bit area index selects from.
The reason this matters: add or remove one polygon anywhere in a file and every polygon after it shifts down the list. The neighbouring files still hold the old indices and nothing warns you. That is why a navmesh edit is a five file edit, and why this page reads rather than writes.
The Sectors tab
The quadtree over the cell. Every node has its own box; a leaf also carries the list of polygons inside it and the cover points that belong to it. The root’s box is the origin every vertex in the file is quantized against, which is why two files can have slightly different vertex precision.
Long trees are cut off at the first 400 nodes.
The Portals and points tab
Full tables. Portals give the type byte, the angle, the two areas joined and the four polygon ids. Cover points give the type, the facing angle over a full turn, the position and which sector they came out of.
Both type bytes are printed as numbers, because the game files carry no table naming them.
The Runtime tab
What a resource can actually do to the navmesh while the game is running, with the code. The table at the top is a straight yes or no per thing people want to do, and most of the answers are no: nothing in the native surface creates, moves or retags a polygon.
The four snippets below it are ready to paste, in Lua, JavaScript, TypeScript or C#, with your open file’s own box filled in:
- Block a box.
ADD_NAVMESH_BLOCKING_OBJECTwith the flag table and the cleanup, because only 32 can exist at once. - Turn an area off. For anything bigger, with the ped path switch beside it and both put back.
- Is there a navmesh here? The check to run before debugging anything else.
- Did the ped find a route? Because with no navmesh the documented behaviour is that the ped stands still, with no error.
The navmesh at runtime goes through all of it in prose.
Vehicle navmeshes
Thirty seven files are named after a vehicle model rather than a cell. They carry the navmesh for walking around on a moving deck, they all report area id 10000, and their geometry is in the vehicle’s own space rather than the world. The page says so when you open one, and draws it around the origin. The Map tab will not have anything useful under it.
Limits
- One file at a time. The Neighbours tab names the files next door and marks their squares, but you open them one by one.
- No writing. No
.ynvoutput, no XML output, no resource download. - A concave polygon is drawn as a fan from its first vertex. Navmesh polygons are convex by construction, so this is exact for real files; a hand made file that broke that rule would draw wrong.
- The unknown fields stay unknown. Where the game files carry no table, the raw number is printed and called a raw number.
