I’ve just pushed on
github my work for the past few weeks and it’s a major update. But most of you should not
have to change a single line of code in the best case. The two major changes are the activation of
frustum culling – who now works perfectly well – and the use of ByteArray objectst to store vertex/index
streams data.
Using ByteArray instead of Vector, why are we doing this?
As you might now, Number is the equivalent of the “double” data type and as such they are stored on
64bits. As 32bits is all a GPU can handle regarding vertex data it is a big waste of RAM.
Using ByteArray
makes it possible to store floats as floats and avoid any memory waste. The same goes with indices stored
in uint when they are actually shorts.
Another important optimization is the GPU upload. Using Number of uint requires the Flash player to
re-interpret every value before upload: each 64bits Number has to be turned into a 32bits float, each
32bit uint has to be turned into a 16bits short. This process is slow by itself, but it also prevent
the Flash player to simply memcopy the buffers into the GPU data. Thus,
using ByteArray should really
speed up the upload of the streams data to the GPU and make it as fast as possible. This difference should be even bigger on low-end and
mobile devices.
Finally,
it also makes it a lot faster to load external assets because it is now possible to memcopy
chunk of binary files directly into vertex/index streams. It should also prove to be very very useful
for a few exclusive – and quite honestly truly incredible – features we will add in the next few months.
What does it change for you ?
If you’ve never been playing around with the vertex/index streams raw data,
it should not change a single
thing in your code. For example, iterators such as VertexIterator and TriangleIterator will keep working just the way
they did. A good example of this is the
TerrainExample, who runs just fine without a single change.
If you are relying on VertexStream.lock() or IndexStream.lock(), you will find that those methods now
return a ByteArray instead of a Vector. You should update you code accordingly. If you want to see a good example of ByteArray manipulations for streams, you can read the code of the
Geometry.fillNormalsData() and
Geometry.fillTangentsData() methods.
What’s next?
This and some recent additions should make it much easier to keep streams data in the RAM without wasting too much memory and be able to restore it on context device loss. It’s not implemented yet but it’s a good first step on this complicated memory management path.
Another possible feature would be to store streams data in compressed ByteArray. As LZMA compression is now available, it could save a lot of memory. The only price to pay would be to have to uncompress the data before being able to read/write it.