Transformation Costs

[Omaha]

I frequently come up with the most elegant solutions to problems that I have, but the cost is always heavy in transformations.

Case in point: I have a rocket that was fired from point A, follows a path of vertices (we'll say it's a homing missle and the target keeps veering to the side)and it leaves behind it a contrail of gray smoke. This is easily accomplished by setting up effectively a billboard at each vertex (I actually do some more math to make it look a little better, and connect the dots. The problem is, for best results, I have to do the billboard transform at each vertex. This is no problem if there's like one rocket going off at a time but this is a space shootemup so we're going to be talking about 40-50 rockets being fired in rapdi succession so the player can _try_ to dodge them all :p

ALl in all I find my engines are transformation heavy, and sometimes I wonder if too heavy. Rendering a a complicated object made of several submodels for instance, requires the following transformations:

pushMatrix()
1.) Translate to object position...
2.) rotate to object orientation...
3.) draw object
4.) push matrix
5.) repeat 5 for all subobjects

The hierarchies can be arbitrarily deep. For example it would be a piecce of cake to set up a class NES-style snake monster by chaining a bunch of spheres together, but then there are lots of matrix multipiles going on.

How many transformations are too many transformations?

[Omaha]

I'll get the easiest reply out of the way: When things start to slow down, then find out why they're slowing down and then attack the problem, not the symptoms.

It jsut doesn't feel right drawing a contrail by performing a transformation for each vertex--although that is picking nits because I want each one to line up with the camera properly and I will do away with that in order to instead have he vertices follow a corkscrew pattern, but still...

Well, the camera's basis is constant, so all you really need per billboard is 2 vector scales and 6 vector adds, all of which can be done very efficietly with SSE/3DNOW!.

You can do the entire billboard calculation on the GPU by sending the billboard origin and basis vectors for each vertex (constant), the scale to use (constant), and an index (scale vector) indicating which of the 4 quad vertices to process.

But how many are too many? I think you already answered that one. But the sausage would surely need to hit the fan to stress a good system ;)

[T101]

What I did back in the UT days (mostly because of the cost of replicating smoke across the network) was make an elongated mesh and draw that between successive snapshots of the rocket's position.

I used a simple uniform scale to make the mesh fit. (That was a compromise since in UnrealScript you don't have the option of sending vertices directly)

You could try something similar.

1. Get a decent (preferably animated) smoketrail texture
2. Calculate your rocket position every 0.x seconds, and store in rotating buffer of y vertices (i.o.w. you generally don't want to store endless con trails)
3. Render two (or three) quads between successive rocket positions. This way you don't have to align the smoke trail with the screen.