Status Update

Since I've returned to Rochester, my efforts have been focused pretty much solely on my co-op with Paychex.  There's a ton to learn and I have been feeling a bit wiped out after I return home.  I intend nonetheless to continue my efforts to update Finger Fireworks.  The activity I was last doing was creating a more centralized and uniform way to manage the buffers sent from Java to OpenGL.  I think I tried much too ambitious an approach before; I will now simply be creating a data-holder for the buffers I know I need, then building and reforming/refactoring as seems appropriate.

Blending update

So, it was definitely the order of blending that was the problem; the OpenGL framework apparently does no sorting whatsoever.  I had to do a quick calculation of distance from the camera, then sort by that in order to get it to work.  There are still strange issues when particles are close to each other, but it is a vast improvement.

Partial Success

So I'm still definitely having blending issues.  But a considerable amount of the time, the program behaves well.  In the first shot here, you might be tempted to think everything was ok:

But even in this one, you can see a couple lines where things are messing up.  This next shot was taken some time shortly after that, and it has obvious problems:

On a positive note though, these shots do show my "billboarding" math to be performing fairly well; the particles all face the camera pretty much.  They do have different shapes though because the four points that make up the borders are processed through the perspective transformation, but arguably that is desirable.

Now I must inquire more deeply into blending and depth buffers and such matters so that I can get to the bottom of this ugly line business!

Herpin' and Derpin'

So, I am working on my Finger Fireworks revamp.  I have some textured triangles I'm rendering particles on.  It's still very early in the process, but I've already ran into an annoying issue: even though glBlendFuncSeparate() is in the GLES 2 specification, it is not actually implemented in my test device.  Holy [expletive deleted] batman that made me kind of mad.

I need to set the blend function so that the texture pixels with transparency are rendered transparent or semi-transparent, as the case requires.  I also wish to keep only the most recent alpha value for comparison, assuming (hopefully) that the blending takes place from farthest to nearest (I'm not sure this is the case actually).  But I do want to blend the actual RGB values in proportion to the source Alpha value.  This seems to be a reasonable thing, as this is exactly the kind of thing that glBlendFuncSeparate() was made for, but I guess someone didn't feel like writing that code.  I was going to use something like glBlendFuncSeparate(SRC_ALPHA,ONE_MINUS_SRC_ALPHA,ONE,ZERO).  Please excuse my not referencing the actual names of the GLES 2 constants; the meaning is there though.

I don't think I'm trying to do anything too extraordinary here, so I've been working on other ways to do it.  I've tried glBlend(SRC_ALPHA,ONE_MINUS_SRC_ALPHA), which almost does the job, but has some weird artifacts here and there; they look like the boxed outlines of the texture file which should not be present as they are entirely transparent by the time you get to the edges.  I think that somehow the order of evaluation might be the problem here.  The blend parameters I have here, if actually evaluated from back to front should only consider the source alpha each time, not carrying forward any amount of the destination alpha, as even though the pixel will be assigned a mixed alpha, the next blend execution will not actually factor it into the weighting of the RGB values.  It still bewilders me though that I am seeing areas of the textures that look like picture frames where there should be complete transparency, but only on a small number of the rendered triangles.

I will be orienting these particles to face the eye/camera tomorrow.  Hopefully these weird artifacts are a condition that does not occur under those circumstances, but we shall have to see.  There are two ways I could do it though, so I may have some options: simply no y- or x-rotation of the model coordinates or, in a more complicated way calculate the vector to the eye then make the plane of each particle perpendicular to that vector.  I have a few sources to consult on this one, so it should be good.

Progress

I've started to adapt the Android OpenGL example to my own purposes.  It uses glDrawArrays() rather than glDrawElements(), which is probably not the source of my current problems, but I'm having a hard time getting glDrawElements() to work instead.  I've gotten my world coordinates transformations working, including the frustum matrix and the view matrix.  Right now my biggest problem is that the triangles in my example code do not overlap correctly; they overlap in the same order, regardless of position in 3D space.  This is somewhat vexing....

Ready to start up again

Ok! I am done with the fall quarter at RIT and back on the couch that I designed the original two versions of Finger Fireworks on. I have reviewed the Android OpenGL example and am thrilled to recognize a lot more stuff than the last time I looked.

Hopefully I will be able to rewrite Finger Fireworks in a more shader-friendly manner, so I can use OpenGL to make it better looking. I think I need to maintain some consistency with the previous versions of the software, but it is clear that I cannot retain everything. One thing that has given me some trouble thinking about it is the fact that I allowed the trails in FF1 and 2 to build up over time on a buffer (i.e. not calling clear). This was an artistic choice, and I like it, but the transition to three dimensions will make this approach very difficult to maintain; now trails would have to be maintained in memory, as vertices and color data. Perhaps this is not so much of a problem; I am not sure; it will greatly depend on memory and processing speed available on the devices I release for next time.

Getting Back On Track

I have not forgotten about this blog or Wernerware! I will be updating Finger Fireworks over this Thanks Giving break, or starting that process at least. Hopefully things will be settling down to a more reasonable schedule for me so that I can start applying all I have learned here at RIT. Reading my last few blog posts makes me realize I sound like a recidivist claiming this time is the charm, but I really do intend to start this thing up again soon! I am starting a co-op at Paychex soon, so that should be good too.