@pictionaryjr
Quote: "its an object matrix lol."
The ideas are very similar to TDKs matrix primer tutorial for an object matrix. But even using an object matrix with a size of 100x100 , that equals 20,000 polygons if it's single sided. 40,000 if it's double sided. That may be more overhead than you actually need.
Anyway, depending on the program you used to create the matrix, the vertices should be in a particular order. On a 100x100 grid, vertex 0 generally starts in the lower left corner and vertex 10201 would be in the upper right corner. This reversed Z layout is often used to correspond with how a bitmap is most often stored as a Windows "bottom-up" DIB. A bitmap is usually stored upside down, with the high Y values at the top and the low Y values at the bottom; this is for the possibility of compression... but never mind all that, I'm just saying that 3d terrains often have the Z values layed out the same way a "bottom-up" bitmap is layed out.
Whatever the layout, the vertices should be ordered. The 3d unit size of the grid and the number of tiles should allow you to calculate any tile that you are on. If your 3d unit size was 1000x1000 and your grid tile size was 10x10, that means there are 100 units between each X and Z value.
So, if you had a position at 275,623 , what tile would you be at?
Let's find the X tile first:
275 X position / 100 units per tile = 2.75
Since we can't have only part of tile, let's drop the decimal and the formula becomes
xtile=int(Xpos/(xunits_per_tile))
Z is the same thing
ztile=int(Zpos/(zunits_per_tile))
So the tile position is xtile,ztile . If you are at the extreme, 1000x1000 , the tile values would be returned as 10x10 which is too big (9x9 would be the largest because the first tile is 0x0 ) so you'd have to compensate:
Remember, tilex and tilez is the grid size you set your matrix up to originally.
if xtile >= tilex OR ztile >=tilez then position is out of bounds
Enjoy your day.
