Lost in the triangles moved! find it here: aras-p.info/blog

OpenGL vertex buffer functionality, I mock thee too! Why couldn't they make the specification simple&clear, and then why can't the implementations work as expected?

It started out like this: converting some existing code that generates geometry on the fly. It used to generate that into in-memory arrays and then Just Draw Them. Probably not the most optimal solution, but that's fine. Of course we can optimize that, right?

So with all my knowledge how things used to work in D3D I start "I'll just do the same in OpenGL" adventure. Create a single big dynamic vertex buffer, a single big dynamic element buffer; update small portions of it with glBufferSubData, "discard" it (=glBufferData with null pointer) when the end is reached, rinse & repeat.

Now, let's for a moment ignore the fact that updating portions of index buffer does not actually work on Mac OS X... Everything else is fine and it actually works! Except for... it's quite a lot slower than just doing the old "render from memory" thing. Ok, must be some OS X specific thing... Nope, on a Windows box with GeForce 6800GT it is still slower.

Now, there are three things that could have gone wrong: 1) I did something stupid (quite likely), 2) VBOs for dynamically updated chunks of geometry suck (could be... they don't have a way to update just one chunk without one extra memory copy at least), 3) both me and VBOs are stupid. If I was me I'd bet on the third option.

What I don't get is: D3D has had a buffer model that is simple to understand and actually works for, like, 6 years now! Why ARB_vertex_buffer_object guys couldn't just copy that? The world would be a better place! No, instead they make a way to map only whole buffer; updating chunks is extra memory copy; there are confusing usage parameters (when should I use STREAM and when DYNAMIC?); performance costs are unclear (when is glBufferSubData faster than glMapBuffer?) etc. And in the end when an OpenGL noob like me tries to actually make them work - he can't! It's slow!

Breaking news: sometimes seemingly trivial tasks take insane amounts of time! I am sure no one knew this before!

So it was yesterday - almost whole day spent fighting rounding/precision errors when encoding floating point numbers into regular 8 bit RGBA textures. You know, the trivial stuff where you start with

inline float4 EncodeFloatRGBA( float v ) {
  return frac( float4(1.0, 256.0, 65536.0, 16777216.0) * v );
}
inline float DecodeFloatRGBA( float4 rgba ) {
  return dot( rgba, float4(1.0, 1.0/256.0, 1.0/65536.0, 1.0/16777216.0) );
}

and everything is fine until sometimes, somewhere there's "something wrong". Must be rounding or quantizations errors; or maybe I should use 255 instead of 256; plus optionally add or subtract 0.5/256.0 (or would that be 0.5/255.0?). Or maybe the error is entirely somewhere else, and I'm just chasing ghosts here!

What would you do then? Why, of course, build an Encoding Floats Into Textures Studio 2007! (don't tell me it's not a great idea for a commercial software package! game studios would pay insane amounts of money for a tool like this!) The images here are exactly that - render into a texture, encoding UV coordinate as RGBA, then read from that texture, displaying RGBA and error from the expected value in some weird way. Turns out image postprocessing filters in Unity are a pretty good tool to do all this. Yay!

Sometimes in situations like this I figure out that graphics hardware still leaves a lot to be desired. This last image shows some calculations that depend only on the horizontal UV coordinate, so they should produce some purely vertical pattern (sans the part at the bottom, that is expected to be different). Heh, you wish!

I had an interesting story recently, but was waiting for gamedev.net to be back up&running again. So...

One day I got an email like "Hey Aras, where are you we need to finish up our project soon". Ok, I don't know who is the sender, know nothing about any project I should be "in", and the sender's email address does not match the signature, so I just marked it as spam and forgot about it.

A couple of days later Paulius forwards me a message from the same sender, saying that he can't reach me, the project has a deadline soon, so he started looking through nesnausk.org and write to other people out there.

I still thought this is some advanced new form of phishing!

I check the website from the signature of the sender. It's a real website; a bunch of people developing (or trying to develop) a MMO game. In the "technology" section of the website was a link to in.out.side demo: "this is a techdemo of the engine we developed". WTF!?

Contacting the original email sender revealed all the story, which is quite simple in fact. They were looking for a programmer and found someone posting on gamedev.net forums, saying he has done in.out.side demo that won Imagine Cup 2005. He presented himself as me (with a slightly altered name) and agreed to work with them. How is this thing called by the way? Identity theft? Some time passed, in my understanding they haven't ever seen any code from that guy, and then he just disappeared.

What makes it funny though that the guy never received any money from the job he was supposed to do either. I could understand reasoning behind presenting oneself as some other guy, taking the money and then running fast - but presenting oneself as someone else, doing nothing and getting nothing in return? Does not strike me as a viable "business plan"...

The moral? Never trust anyone online, especially if they are from Lithuania :)

Here's a short function:

inline int SecondsToEnergy( float time )
{
return FastFloorfToInt( time * (float)(1 << kEnergyFixedPoint) );
}

It's used in the particle system, and converts particle lifetime to an internal fixed point representation (10 bits for fractional part, i.e. kEnergyFixedPoint=10).

Some of the emitted particles are okay on a Mac, but completely not visible on Windows. This function is to blame.

Of course, what's wrong is the possible overflow in float-to-int conversion. Whenever someone tries to use lifetime longer than about 2097151, the conversion to signed 32 bit integer is undefined. It seems to clamp result in gcc and produce something like -1 in msvc.

Using multiple compilers can be hard, but it can also help in finding obscure bugs. Ha!