TerrainQuad and PatchSize, the thread to the way of solving the issue

Hey.

There is a pretty big issue with the TerrainQuad and PatchSize. Up to a size of 256 all is ok. Every setting above that value messes up the indexbuffer.

I tracked the primary issue down to LODGeomap.java line 171.
[java]
int numIndexes = calculateNumIndexesLodDiff(lod);
IndexBuffer ib = IndexBuffer.createIndexBuffer(numIndexes, numIndexes);
[/java]

The problem with this is that even if the index count for the current lod level is below the magic value of 65.534 it is not guaranteed that the the usage of a short buffer is allowed.

If the mesh itself has more than 65k vertices the follow up generator code starts writing values larger then ‘short’ to the ShortBuffer.

Forcing the code to always use an IntBuffer solves most of the issues, but it does generate some slight seams…

Ah I see. Good catch. The code there is checking the vertex count not the index count. I will strip it out and have it check the index count instead.

As for using an int buffer, Terrain cannot be forced to use one all the time because android does not support it. At least for many hardware types. That’s why it does the check there.

Sorry I didn’t see this thread earlier, forum notifications are borked.

I’ve made the change but I cannot fully test it and commit until next week, heading off to a conference in the mean time.

1 Like

No problem,

However, just changing to int buffers will not solve all issues on my side. It seems that the algorithm is picking the wrong indices. Already checked if there is some ‘short’ used in the code, but i have not found anything.

Also the picking algorithm is kind of hard to follow ^^

Did not know about the android limitation, but good to know.

What issues are you seeing with the indices?
The picking algorithm is Bresenham Line algorithm.

I have to say that i didn’t investigate it further… looks eighter that wrong indices are used, or that 1 lod level left out between… don’t know really.