Question - eqnavigation mesh creation for TDS?

[Hihi]

Is there any way to have the limit changed/removed? I'm not sure who designed it that way, or if it's still being frankensteined to work. Is it possible to remove the limit and just make as detailed of a mesh as possible? Even if it's more cpu intensive to use, it should be ok if you're not using it on multiple boxes at once. The actual plugin performance increase would be well worth a slight PC performance hit.

 

[brainiac]

The problem is not the limit. The problem is actually not knowing you've hit the limit.

Cell size is kind of like resolution, the smaller the cells the more of them you have. The more cells you have, the higher the number of bits requires to index the cells, and the less tiles you'll be able to store. The smaller the cells, the larger the tiles need to be.

Tile size can be quite large, if you set them to 256 or higher you will generally not hit the limit.

 

[dannuic]

Yes, and I know why. I am using the very latest Recast and it is not a bug with recast.
There is a maximum number of tiles that can be created that is inversely proportional with the size of each cell. You need to make sure your tile size is not too small or you end up running out of space for tiles. Basically the cell index and tile index is packed into a single 32-bit integer. The number of tiles/cells determines the width of each within that integer. IF you have too many cells you run out of space for counting them, and it ends up stopping.

I've added a display in my EQNavigation to show you when you've created too many tiles, it'll be in that build whenever i release it. Easiest way to solve this is create bigger tiles, though.

edit: I may have conflated this with the eqemu mesh generator, but the problem exists in eqnavigation and i believe it is the same.

I'm not sure the problem is the maximum number of tiles. In underquarry, I watched how many tiles were being generated and it was less than the max. The calculation for max number of tiles simply comes from dividing the zone into equal parts based on the size you specify. I'm sure it's possible there are examples where this calculation goes awry, but from my testing I always stayed under the max number. (You can actually see the number of tiles generated while the mesh is being generated, it counts down in the UI. For instance, in underquarry, with a 256 tile limit I was generating 180 tiles).

The problem instead was that there was some sort of "ceiling" where you would get a giant square mesh that was not on any actual terrain (it "floats" between the really low terrain and that which is above it). It looks like a height limit thing, but the numbers as I was inspecting them in my limited testing looked good, so I was unable to locate the source of the problem.

 

[brainiac]

I'm hoping this will help illustrate my point

		const glm::vec3& bmin = m_geom->getMeshBoundsMin();
		const glm::vec3& bmax = m_geom->getMeshBoundsMax();
		int gw = 0, gh = 0;
		rcCalcGridSize(&bmin[0], &bmax[0], m_cellSize, &gw, &gh);
		const int ts = (int)m_tileSize;
		const int tw = (gw + ts-1) / ts;
		const int th = (gh + ts-1) / ts;

		ImGui::LabelText("Tiles", "%d x %d (%d)", tw, th, tw*th);

		// Max tiles and max polys affect how the tile IDs are caculated.
		// There are 22 bits available for identifying a tile and a polygon.
		int tileBits = rcMin((int)ilog2(nextPow2(tw*th)), 14);
		if (tileBits > 14) tileBits = 14;
		int polyBits = 22 - tileBits;
		m_maxTiles = 1 << tileBits;
		m_maxPolysPerTile = 1 << polyBits;

		ImVec4 col = ImColor(255, 255, 255);
		if (tw*th > m_maxTiles) col = ImColor(255, 0, 0);
		ImGui::TextColored(col, "Max Tiles: %d", m_maxTiles);

I will look at underquarry and see if the issue applies here. Its possible we are both correct and just talking about different things.

 

[TheTsr69]

Glad you guys are hashing this out - the community has been looking for this excellent program to get updated for a while!

 

[mackal]

I mentioned underquarry to KLS, he said he thinks he knows what the issue is, but he needs time to look into it. And it's that's after he really fixes some of the silly shit the zone files do that was realized with some newer zones.

 

[dannuic]

I will look at underquarry and see if the issue applies here. Its possible we are both correct and just talking about different things.

I assumed that was the case =P

But that code (assuming that rcCalcGridSize finds the number of cells in width and height and stores them in gw and gh) gives a maximum tile count of 2^14 (16384) which could happen, and probably does in some circumstances. In underquarry though, it doesn't get close to that cap. I assume there is more than one problem.

 

[brainiac]

OK, I can confirm, the issue with underquarry is the bullshit underneath the zone. Adjusting the bounding rectangle of the navmesh solves the problem.

Sorry if this is a bit of a tease. This is a work in progress but you can see the navmesh generated fully.

 

[tms]

this looks like a mesh with pretty big tiles. Can this still be used for mq2navigation ? As i said, i dont really understand whats more important : small cells or small tiles.

 

[brainiac]

Yeah, I actually don't think the tile size matters. The cell size is the resolution of the navmesh at edges and corners, which means the smaller the cell size, the more resolution and more triangles.

from what I understand, tiles are meant a logical grouping of geometry. Like if you had a game that loaded terrain in chunks, you'd want your chunk size to match your tile size. On some very large maps you need large tiles or you'll have too many and be unable to compute paths (there is a finite limit on the number of tiles a navmesh can have, and a limit on the number of tiles a path can contain).

 

[Maskoi]

OK, I can confirm, the issue with underquarry is the bullshit underneath the zone. Adjusting the bounding rectangle of the navmesh solves the problem.

Sorry if this is a bit of a tease. This is a work in progress but you can see the navmesh generated fully.

The bounding box is a fantastic addition it had to be hard coded into the old version and recompiled. Plus on the super large TDS zones it looks like you can make the mesh box smaller so you aren't wasting resources on water etc. Just like you did with the Z-axis on Underquarry

 

[tms]

Yeah, I actually don't think the tile size matters. The cell size is the resolution of the navmesh at edges and corners, which means the smaller the cell size, the more resolution and more triangles.

from what I understand, tiles are meant a logical grouping of geometry. Like if you had a game that loaded terrain in chunks, you'd want your chunk size to match your tile size. On some very large maps you need large tiles or you'll have too many and be unable to compute paths (there is a finite limit on the number of tiles a navmesh can have, and a limit on the number of tiles a path can contain).

Thanks for the explanation, this match with my feeling, that a mesh with larger tiles are actually better than a mesh with smaller ones. ill try old sebilis again (my testing zone) with as small as possibles cells and large tiles.

 

[Maskoi]

Yeah, I actually don't think the tile size matters. The cell size is the resolution of the navmesh at edges and corners, which means the smaller the cell size, the more resolution and more triangles.

from what I understand, tiles are meant a logical grouping of geometry. Like if you had a game that loaded terrain in chunks, you'd want your chunk size to match your tile size. On some very large maps you need large tiles or you'll have too many and be unable to compute paths (there is a finite limit on the number of tiles a navmesh can have, and a limit on the number of tiles a path can contain).

That's what she said. She was a liar.

 

[mackal]

Damn EQ devs and their copy paste! Also EQ devs letting multiple zon files be in the same zone (and use them!), like wut.

 

[dannuic]

Did you just ignore anything below a certain Z-Axis?