You cannot access ETM's indices, nor do you need to.
I think I might have to grab the indices straight from ETM.. I've been debugging for quite a while now and this makes no sense to me.
The following picture shows a ManualObject created from a list of vertices and the first 125 (out of 513) rows indexed (Note that I only do 1 of the 2 triangles for every quad, helps visibility):
And now look at just row 126.. (out of 513)
I have spent a long time logging index values and vertices, and nothing looks out of place. The indices are always calculated with the same value, that is, + 0 or 1 in the x direction, and + 0 or 1 * width for indexing a vertex in the next row. (which is 513 in my case)
Looking at the picture, it looks like the vertices I'm indexing are distant from each other, by my log shows all the points to be together.
Code: Select all
20:51:30: Indices
20:51:30: 1315.79 40.6409 368.421
20:51:30: 1315.79 42.0462 371.345
20:51:30: 1318.71 39.7436 368.421
20:51:30:
20:51:30: 1318.71 39.7436 368.421
20:51:30: 1318.71 40.8606 371.345
20:51:30: 1321.64 38.5534 368.421
This is a sample of my log. Each 3 points represent a triangle. I have narrowed down my log to look at 10 triangles which stretch out across space, which represent some of the triangles seen in the second screenshot. In order for the triangle to stretch, the x coordinates between the 3 points need to be of great distance (triangle stretching from left to right). The logs show nothing like this, all x values are very close to each other.
Am I missing something? Is there a better way to investigate this? When will the hurting stop?
Is there some major design flaw in allowing access to the indices? In fact, if you did allow methods to retrieve lists of the vertices and indices,
OgreOpcode won't have to link to ETM in order to make an ETShape, which would be the best solution IMO. Requiring people to link ETM to OgreOpcode is not very likely, so even if I did produce a solution, I can't really add it to the library.
Please consider creating const access to:
- number of vertices
- number of indices
- vertices
- indices
KungFooMasta