Sorry your browser is not supported!

So I have standard tri list terrain done and dusted, however decided to look at replacing with shared vertex objects instead.
So tried to examine generated objects from height maps, first off baffled as to why the work for the extra row of verts is dealt with in the middle of object instead of the end, anyone knows why I am curious to know the purpose.
I tried various sizes and checked out the memblock mesh indices and vertex count given I know the res of the objects mesh it should be easy enough to work out right? I mean the help file states every 3 index=1 tri, and that's about it lol, but I had big problems so that's why I started to lean away from the plethora of info on indices in the help files and took to making sure what was in the object from height map object command matched what the help file said.

help files;
"The first 4 bytes of the memblock represent the number of vertices in the mesh. The second 4 bytes represent the number of indices in the mesh, this may be 0 in which case every three vertices represents a polygon, and no vertices can be shared. If the number of indices is greater than 0 then every three indices represent a polygon and vertices may be shared between polygons. Indices start at 0 so index 0 references the first vertex in the list. "
and later confirmed towards the end;
"Lastly is the index data, if present. Each index is a 4 byte integer which references a vertex in the vertex data. Every three indices represents a polygon"

So I interpret that as a 2*2 image setup is 4 verts and 6 indices, if you have to provide 3 integers each referencing a position per tri, well that should be it right?
so 4*4 verts should be 16 and 54(9 squares is 18 tris, multiply by 3 indices), 10*10 should be 100 and 486
yet these where results from height map objects memblock mesh;
2*2= 4 verts, 4 indices
4*4= 16 verts, 28 indices
10*10= 100 verts, 196 indices

So that didn't make sense, next best thing I can do is google the crap out of it..did not clear things up.
I have known what tri-fans and strips are roughly, but again couldn't make the numbers work when applying any "rules" I found online to fit the above results or even what the help files state. Came close a few times but never exact.

Now what I have done is give it a shot anyway...so far I can make a tri or 2 show up, what I cannot do is get beyond the second tri with anything that doesn't end with a final vertex position at 0
I have started left to right bottom to top, and switched top to bottom, I have tried a bunch of combinations going through each possibility methodically but nope every darn time it fails beyond the none use of vertex zero. Can literally type in 5 on the last vertex and it jumps to zero.
As I said I did my best to take apart the height map object mesh memblock data but just can't fathom it.

I feel sure they should be able to be made from scratch right? I can change data in the height map objects mesh and see how the single change to 1 vertex moves all neighbour triangles.

I couldn't see anything related on github either - unless I am mistaken.

Attached should be a project showing as far as I managed to get - if anyone can fill out the correct indices manually for several tiles and offer an explanation along with what I am supposed to do at the end of each row I would really appreciate it.
Really thought it would be straight forward and if not then it would probably be obvious after a bit of study...days later I find myself here baffled!

Edit wrong file, corrected

I'm not sure if this will help but AppGameKit has "helper" functions for getting/setting the vertex, UV etc. Search the commands for "GetMeshMemblock" and "SetMeshMemblock"
I have also tried to decode a mesh created from CreateObjectFromHeightMap and i've concluded that the object is not a regular object.

Those commands don't cover indices - they are sort of automated in a way, instead of making loads of verts you just put down the minimum points needed, so instead of 6 verts for 2 tris you only need 4 and for every neighbouring pair after that just 2 more are needed, basically lay a grid of verts out and the indexed list defines each triangle in a specific order so that edges are shared, at least as I understand it. This way when you alter a height of a single point you only need to raise 1 vertex with indexed lists instead of all 6 on an object with 0 indices - which would ordinarily share the same point(not so many at edges of course). So yeah I do use those commands, but only get/setmemblockint is useful for indices.

I think it may well be a regular object, it has standard attributes plus indices is all. It may well(and probably will) be determined that those values detailing the number of indices is correct and all it takes is better understanding on my part, if so then yeah its a regular object, its just they stuck the extra row solution right in an annoying place that bugged me when some old code appeared "off".

So far I have managed 4 tri's but the neighbouing edge issue lands me back at wrong edge lol, to get the 4 in a row I had to reverse vertex order to get the underside instead - because I can always flip the normals for every second tri I guess? How or which verts would apply to what might be just as much a headache at this rate!

This is a project that will save an object from a heightmap

blink0k on further reflection you may be right

The 4*4 example - reports as 28 indices via object height map - nowhere near enough, not only that when you try to manually duplicate the contents - an error is thrown telling me that indices can't be 28 they must be a multiple of 3! Weirdly though you can change the mesh via memblocks if you grab them, change heights and swap them back with no issues.

You can also read way past the memblock limit for the object height maps mesh - but the values are all 0, when you try that with an ordinary memblock it throws the out of bounds error, to be clear I did generate the object from my own mesh first and then re-grabbed the mesh to double check I couldn't read out of memblocks memory bounds - I couldn't, and yeap I did take into account index 0.

Also when I draw out on paper the 4*4 formation and shade in the 28 indices that are provided they are surprisingly all over the place and cover just 6 triangles of the grid, lots of space in-between, with 3 additional triangles that are being used as lines by the look of it(totals 27 indices...). Why they would hide this info seems odd. Still begs the question then of why would they support indices at the user end if they aren't gonna tell us anything useful lol.

That's pretty neat, very useful indeed, I've checked out many an x file(meshes only) but not other formats. So how does the format face function work? I am actually very tired...its breakfast time so I should go to bed.

I switched texture to my 4*4 to make it easy to read - there are 9 lines with 4 lots of what look like same vertex face references? ie 1/1/1

You know what, after I get some shut eye this might make a bit more sense, thanks for that project, might be the key to me getting that penny dropped moment !

Wavefront .obj file format

Okay so have sorted this now. Weirdly your saved .obj file when loaded back showed the full compliment of indices but a number of them where messed up, wrong places and orders along with larger than the tile sized tris ie 2 or 3 tile span for some vertices visually(not the actual verts but result of indices reference)overlapping tris, and finally some where being used as edges almost...however at the same time, reading that data back - from your saved object reloaded as a memblock mesh - that was my savior as I have now sorted it all out! In the data some combo's did appear to work - a full row right at the end, so looked for a pattern for the order - was a really obvious one and fitted in with what the help files stated So I went through the other indices and applied the rule - came out spot on. See attached

Thanks very much for your help blink0k, I really appreciate it, although I only managed to get there by chance I would not have got it it otherwise, not without that project - although I was methodical yesterday the answer was near the end of of what I was doing - I was so tired that I missed it plain and simple, I(I must have blinked0k)would have had to repeat whole thing again today and likely got the same result(health tires me out quick - like just a few hours).

There is though that obvious issue of the createobjectfromheightmap, not to mention some sort of issue with the readout of indices data with some media like the one produced your save object project...object reloads successfully however when I copied the data manually over so as to make it from scratch - that is when it became obvious something is messed up as I was seeing lots of messed up tris.

Whats important(to me at least) is I have a working mesh with a pattern for the indices I can write some simple code for.

Now I do have a question someone might be able to answer - at what point would I need to generate tangents and binormals? In DBP some shaders needed them others didn't. Also do I set them before uv attribute or after? The shader packs terrain shader works fine without as does internal normal mapping, but I have never seen examples or mention of stuff like parrallax or stuff with vertex texture fetch for heightmaps so would be nice if someone knew that off the top of their head.

Once again thanks blink0k

Edit: almost forgot, just remove or rem out that chunk of manual entries for this, then you can change number of object verts in function call