|
Billboards And Transformations Question submitted by (22 June 2001)  |
Return to The Archives |
 |
 |
|
|
I'm at a bit of a cross roads in my current engine design and I was
hoping you could clear some thing up re hardware transform. A typical application of my engine will involve rendering lots of identical low poly objects. Hundreds of billboards with less than 10 vertices. I've already made the decision to render everything via vertex buffers (glDrawElements()). My first concern is that drawing these objects with separate vertex buffers is not going to be best use of my time. A better way would be to batch all the objects up into one vertex buffer and call one glDrawElements for the whole lot. (State's not an issue, I've got that pretty well sorted). My question is this. To get my objects into one big buffer I will have to pre transform all the vertices on the cpu. Is doing this going to negate the benefit of having hardware transform available or does the hardware transform come into it's own at a lower level ie model space to screen space transformation. |
||
 |
 |
 |
|
|
|
If your billboards are static (i.e. cross-section trees), then you only need
to perform this pre-transform once when you load the level, which is a
perfectly satisfactory solution, since you won't be required to do
transforms on a per-frame basis. As you mentioned, the hardware will still
perform transforms from model space through to the perspective transforms. If your billboards are always camera-facing, then you'll need to do the transforms yourself on a per-frame basis to ensure that your billboards are always properly oriented. This would require not only doing the transforms, but also dynamically updating your vertex buffer every frame as well. In terms of bandwidth to the video card (sending 10 new vertices to a T&L card as opposed to sending a matrix) you're better off sending it a matrix. This means that you avoid the matrix multiplication and get better bandwidth to the card. On the other hand, it's possible that different OpenGL implementations might have to perform pre-multiplication of the matrix stack each time you update a matrix. I'm not sure what the OpenGL specification says on the matter, but this behavior may very well be implementation dependent. In the end, you are probably be better off letting OpenGL perform the transforms. Different OpenGL implementations can have differing results, but if you let OpenGL handle the transforms for you, the better implementations will out-perform your own transforms because they send the individual matrices to the card rather than pre-multiplying them. The worse implementations may only be marginally slower. Response provided by Paul Nettle |
||
|
|
|
This article was originally an entry in flipCode's Ask Midnight, a Question and Answer column with Paul Nettle that's no longer active. |