This may be a beginner question, but is it possible to update the values of a VBO. Say for instance, I wish to move one of the vertices(relative to the others in the buffer).

I was looking at the code in http://code.google.com/p/android-gamede ... /Mesh.java, and in that example the following code is used to "update" the buffer.



However, after reading the documentation, it seems that glBufferData will simply create a new data store for your data. That seems like a relatively expensive operation, to be deleting the old store and creating a new one, especially if I wish to do it every x frames or so.

Any pointers? Should I be using VBO's at all in the case where I need to update vertex data fairly regularly?

What you're looking for is glBufferSubData. You need to upload the initial data with GL_DYNAMIC_DRAW for the "usage" parameter - that will optimize it for continuous changes in the geometry.

appforce wrote:What you're looking for is glBufferSubData. You need to upload the initial data with GL_DYNAMIC_DRAW for the "usage" parameter - that will optimize it for continuous changes in the geometry.

After reading http://apistudios.com/hosted/marzec/bad ... ess/?p=548, I ended up being weary of using glsubdata. However, after playing around with it a bit, I was able to get glbufferdata to work great. I was able to get about 5 fps by drawing a single dynamic mesh (backed by a dynamic VBO), vs drawing a whole bunch of individual VBO's.

That post is referring Qualcomm hardware, I don't think it's ever reasonable to write code with specific hardware in mind. If you're modifying almost the entire buffer, then you may look into glBufferData, but if you update small part of it, don't fall for Qualcomm's poor implementation. At least you should measure (not guess) the fps penalty that this brings, and decide whether you still want to spoil your code. Anyway, Qualcomm may be currently popular, but has no chance against PowerVR's upcoming wave of chips. Sane code is always preferred over tweaking for specific implementation.

Ha, well unfortunately most of my testing happens on a MSM7200. I do have access to a Galaxy S, but its not currently my test phone. I am planning on getting a next-gen phone pretty soon though.

The thing is too, I end up usually updating the whole buffer (at least vertex buffer) usually anyways, so its not a really big deal.

It's also worth taking a look at the following posts on Mario's blog too:
http://apistudios.com/hosted/marzec/bad ... ess/?p=904
http://apistudios.com/hosted/marzec/bad ... ess/?p=899

As things go there is a big performance problem with direct FloatBuffer support on Android that is going to be fixed in Gingerbread. Mario came up with a temporary native solution which is discussed in the posts above. Of course you must be careful when using the workaround.

MichaelEGR wrote:As things go there is a big performance problem with direct FloatBuffer support on Android that is going to be fixed in Gingerbread.

I have personally experienced this problem and I can say that it renders FloatBuffers essentially unusable for graphics. I don't have my profile statistics anymore but I can say that something like 70% of my time in the render loop was spent in FloatBuffer code. I didn't know that this was a bug limited to only FloatBuffer that will be fixed or that the issue didn't exist in all the other buffer types.

Even if this were fixed today however, I wouldn't even consider using FloatBuffer within the 12 months after Gingerbread's release. As of July nearly half of the devices in consumers' hands were still running 1.5 or 1.6 (http://www.3g.co.uk/PR/July2010/google-android-version-statistics-revealed.html). This means that it'll be a long while before the largest segment of the market is updated to Gingerbread after providers start pushing it out.

@MichealEGR: After digging around, I found this. I'm gonna try it out and see how it works. http://code.google.com/p/rugl/source/br ... uffer.java

@moblcade: What was your solution? Did you switch to fix point?

@Mark:
On a quick look of the RUGL fix is that it is using a backing ByteBuffer with IntBuffer & FloatBuffer imaged copies. IntBuffer puts are not handicapped and this will be faster than FloatBuffer puts, but the float array put still loops through the array and does Float.floatToRawIntBits. It'll be a lot safer than Mario/libgdx solution, but I'd look at the libgdx / native call solution as the real workaround direction since you can still work with FloatBuffers and not have to worry about a new type as that will aid in coming up with a cleaner facade like solution when Gingerbread is released. Pre Gingerbread use native put work around and w/ Gingerbread handle things normally. Of course with the libgdx/native solution you have to be extra careful to not exceed the size of the buffer, etc.

This of course now introduces a custom facade layer to code that is a major bummer considering my efforts are cross-platform and run on J2SE / desktop too from the same code, so now it'll have to be embodied in all code. Bah!

@moblcade:
This is a major problem with Java Android real time app & game dev. Things have had very low quality control or apparently none at all. With the FloatBuffer and OpenGL ES 2.x API NIO screw up major workarounds are necessary for pre Gingerbread dev. This opens a can of worms up considering wider ecosystem deployment. Many devices will never be updated to Gingerbread, so it isn't even a case of waiting to switch over say 12 months after release. These are permanent workarounds that must never (until years later - if one wants to guarantee running on the entire ecosystem) leave ones code. :: sigh :: I really do feel with just a bit more effort all of this could have been fixed up front and not burden all developers. I'm afraid it's really a Google / Android management issue as top management never made quality a primary concern. just ship it ship it ship it... Now this succeeded in gaining Android quick market share and if trajectories continue things will move quickly to market dominance, but at the cost of quality and/or making developers lives more hellish. When people just define Android fragmentation as OS differentiation across the ecosystem they have no idea what the face of fragmentation really looks like for devs doing low level audio/graphics real time apps. After all we're the ones making engaging and really cool apps/games for Android pushing the limits and moving things forward. :: sigh ::

Keep positive though. Android is great and hopefully soon they'll be more standardized work around methods embodied in middleware. I've long been working on my middleware platform since the G1 hit my hands and hope to release this year.

Just for a quick update on this issue. I finally have an acceptable, in terms of performance, solution working. I switched to using the FastFloatBuffer (with a few minor modifications, namely limit() stuff) and instantly noticed a difference. I was actually bit shocked by how such a simple change could result in noticeable gains.

@MichealEgr Micheal, I also noticed something strange. Mario's graph shows put(position,value) to be marginally slower than bulk puts, but I actually saw (at least in my rudimentary FPS counter), that performance is actually worse using bulk puts that single indexed puts. I dont know if it was symptomatic of another issue in my code, or if bulk float puts are really just that broken right now.

@MichaelEGR

I am writing a 2D application, so I just switched to using glDrawTex. It is sufficiently fast given that I manage texture and crop state changes, but I am disappointed that I will not be able to rotate textures. I may, later, add a method to render a rotated texture as a special case that uses a textured quad. Having only a few quads on the screen at once combined with the FastFloatBuffer extension would probably me OK on most hardware.