Are you calling glClear during onDrawFrame or similar function? If you don't call it it should never clear the screen, thus allowing you to continually "add" to the image on every frame.
Unfortunately I'm not sure if the glSurfaceView uses double buffering or how to disable it if it does. This might cause some problems but I'm not sure, you can try without calling glClear and see how far you get.
I don't personally see anything, maybe you could post more code. Do you have a shader? How do you know that AttribArray 1 is really the texcoord, do you have glGetAttribLocation somewhere, or glBindAttribLocation?
I'm not sure if that's an adequate general-case solution. In some cases you may actually need to increase the size of the vertex/index buffer with new indices. In an original VBO, you can have a single position vector share two UV vectors. For example if you had a quad consisting of two triangles, with unique textures on each tri, it might look like this:
f 1/1 2/2 3/3
f 2/4 3/5 4/6
Originally you'll have a vbo/ibo of 4 vertices, but you'll end up needing 6 to represent the texcoords accurately. You'll probably need to toss the entire existing IBO and recreate one from scratch.
Unfortunately processing texture coordinates from obj models is not trivial. In opengl you only get one IBO which must be shared by all buffers (for a given vertex, position, color, texcoord, normal, must all be in the same index of the buffer).
Because obj gives each attribute its own set of indices, you will need to read in the data and rearrange/reindex everything such that all attribute buffers are aligned on a single index.
If you have trouble doing this, just search the forums and I'm sure you'll find hundreds of discussions on the topic. I think pretty much every opengl developer runs into this wall early in their development carrer.
So what I did is declare the matrices in the shader as uniforms and made a neat updateMatrices() function for my DisplayObject class that is called everytime a transformation is done to the object (for example when it translates or rotates).
You're probably running into the problem of two objects using the same shader. If you use more than one object with a given shader, then you need to update the matrices each time you change between one and the other.
After some time of debugging I was able to fix this by calling chop the glUniform calls out of updateMatrices and call just before every object is drawn instead. Even though this works, I'm really doubting if I did the right thing here, because what I'm now doing is sending matrix data to the shader even though the values didn't change.
This sounds like a reasonable thing to do to me. Obviously you don't want to send data that you don't have to, but I can't imagine many cases where a single object gets a shader all to itself. I think just updating the matrices before drawing is not a big deal, unless you have unusual use case where it becomes impractical.
You don't want texcoord to be the same as the vertex coordinates. Textures range from 0 to 1. So by specifying it from 20 to 100 you're squishing and repeating your texture 80 times across the surface.
So does that mean that generic attributes hold the actual data used by the shader?
Not exactly sure what you mean here, but a generic attribute is basically a point you can bind a VBO to such that the VBO supplies data through that attribute.
And what's the difference between glVertexAttribPointer and the other glVertexAttrib* functions?
glVertexAttrib* (for example glVertexAttrib3f) are kind of like the 'immediate mode' equivalents of glVertexAttribPointer. Its the same thing as the difference between glColorPointer and glColor3f, if you're familiar with the deprecated non-generic attributes. One specifies a VBO as a data source, and the other just sets a constant value. If you had a shader that had a per-vertex color attribute, but you just wanted to draw a red model, then you can just call glVertexAttrib3f(colorIndex, 1,0,0), and this will set the input to 1,0,0 for all vertices if you don't bind a VBO to it.
I guess what I'm really asking is, why would you need a generic attribute to bind to in the first place? Wouldn't the vertex shader analyze the VBO's contents and initialize the attribs off of that?
Shaders don't know anything about VBOs, and VBOs don't know anything about shaders. Attributes are how you link VBOs to specific input variables in your shader. How would the program know which array of floats you want to be the position, which is the texcoords, which is the normals unless you tell it what they are? Setting up attributes is how you send which VBOs to which input variables.
I think that expense is covered by forced labour. If I'm not mistaken putting citizens in prison is a lucrative buisness in the US hence why there's so many prisoners.
I doubt the cost of labor comes anywhere close to compensating taxpayers. In California we have extremely strict 3-strikes laws that lockup way too many people. All the jails are at like 175% of capacity, hence the recent supreme court ruling.
However it is very lucrative, not for the state, but for the prison guards' union. Its quite perverted, but that group is the biggest sponsor of all tough-on-crime laws in the state (three-strikes law was pushed by CCPOA), and they throw more money behind them than any other group. More prisoners = more guards = more union dues.
Technically, there's no such thing as "the projection matrix". All you really have down at the hardware level is one matrix that transforms a vec4 (object space) to another vec4 (screen space). The idea of a projection matrix is just a nice abstraction for developers to help them assemble this final matrix (by compounding the projection, view, and object space matrices).
But if you consider the concept of a projection matrix, then it makes no sense for it to be there. Projection is only for doing perspective transforms, i.e. transforming what is in front of your face into an image. It doesn't care much about what direction you consider to be 'up', that's for the view matrix to determine.
You can probably stuff a 90 degree rotation into what you're calling your projection matrix, but it doesn't make much sense for you to do so.
I don't have a particular need for a texture editor at the moment so I'm not going to download, but one feature I think would be great would be a filter that helps create tileable textures from untileable ones.
I know its not an exact science, and it can be done in photoshop (though I never remember exactly how when the time comes that I need to do it), but a feature like that could be really cool. You'd have to have a lot of user interaction to get it quite right, maybe with some kind of clone tool like photoshop and some lowpass filters to work on color gradients, but to me that seems like it would make a neat tool.
A few more in-use screenshots and documentation on the website would help people get an idea of what they were downloading as well before they commit to installing it. I saw one but some more feature explanation would be nice.
Just started out the same way as everyone else with my first glBegin triangle, then picked up VBOs for speed, and shaders cause they sounded fun and cool. Really not much more to it than that.
Looking at the big picture the API is not really a big deal. Whether you're using ancient immediate mode opengl, modern DirectX/OpenGL with buffers and shaders, or something else, the underlying graphics theory is all the same. Once you understand the theory behind things, then the API is just a tool for you to use.
"Modern OpenGL" is just shader syntax and API calls, its the theory that's most important to understand.