Bug in BitmapMuzzleFlame.cpp

[Zpock]

I like using BitmapMuzzleFlames for displaying a particle in any direction I want. I wanted to make an indicator for units loading/unloading cargo with a bunch of arrows going in/out of the base of the unit. However muzzleflames that are turned upwards display really buggy behaviour, basically scaling with the rotation so they disappear when pointing straight up and stretch badly.

The problem lies in the source itself:

Code: Select all

float3 sidedir = dir.cross(float3(0,1,0));
float3 updir = dir.cross(sidedir);

va->AddVertexTC(pos+updir*isize,sideTexture->xstart,sideTexture->ystart,col);
va->AddVertexTC(pos+updir*isize+dir*ilength,sideTexture->xend,sideTexture->ystart,col); va->AddVertexTC(pos-updir*isize+dir*ilength,sideTexture->xend,sideTexture->yend,col);
va->AddVertexTC(pos-updir*isize,sideTexture->xstart,sideTexture->yend,col);

The cross product of dir and (0,1,0) = straight up is obviously fine for when dir lies in or close to the horizontal plane, hence why noone noticed. If sidedir and updir would be normalized I think the problem would be sort of solved for all angles except straight up. Perhaps some random vector would work better instead of (0,1,0).

A more complete solution would have to use a rotation matrix of the actual orientation of the muzzleflame rather then just a single vector.

[imbaczek]

Screenshot? It would be best if you could make a minimalistic mod that easily reproduces the wrong behaviour so that fix could be tested. If you feel at it, fix it yourself, test it and submit a patch, all contributions are welcome.

[Zpock]

Same muzzleflame, rotating around z-axis.

I would need to figure out how to compile spring before I could patch it myself unfortunately

I'll try and get rid of all the crap in my mod folder to upload it.

[rattle]

Try using a vector of dir(0, 0.999, 0). I think the issue is that it was never intended to point upwards. I've never seen this myself either. Aren't you better off using the simple particle system by the way?

There is a thread about setting everything up in the dev forum. Just grab mingw 4.x.x from the official mingw site, the mingw libs mentioned in the thread and python 2.4 or 2.5 (dunno which version) and you're set, more or less. If you need help just bugger me.

[Zpock]

http://www.unknown-files.net/3553/bugged_flare_mod/

Instructions: put the boxy thing on repeat order and tell it to "dropoff" on itself to see the flare.

Try using a vector of dir(0, 0.999, 0). I think the issue is that it was never intended to point upwards. I've never seen this myself either. Aren't you better off using the simple particle system by the way?

That would probably work if the vectors (sidedir and updir) were normalised, or rather something like (.001, 1, 0), The flare is stretched otherwise. It's not just a problem for straight up, but any angle away from the horizontal plane. (look at the pictures, it's not pointing straight up, only nearly, but is badly scaled).

Maybe be careful to add a check so it dosn't make a Dividebyzero if it's acually is pointing straight up, when it tries to normalize sidedir.

IIRC simpleparticle system billboards the particles, only flare dosnt I think wich makes it useful. If you wonder what I'm trying to do it is something similar to the graphics for auras in WC3, some flashy stuff underneath the unit showing whats going on. I could try groundflare but I dont trust that to work when I make space maps with voidwater and stuff.

[Argh]

Um, I pointed this out in a Feature request some time ago, this is definitely the bug.

Thanks, Zpock, for getting into why it's borked- it is definitely borked guys, not just in his "mod", but in my tests with PURE code as well.

[Zpock]

Ok, just to clear things up for people who don't know enough math to understand, that code snippet shows that he basically took the cross product of dir and a vector straight up to get the "side" vector of the flare, and then similariliy for the up vector. This is since the vector product gives a new vector thats at a right angle to the two vectors it's produced from. Only the length of the new vector depends on the angle between the two and their respective lengths as

length1 * length2 * sin(angle)

So for 2 nearly parallel vectors the sin term is close to zero, actual zero if they are indeed parallel. So as you can see the code would be fine if a simple normalization of the side and up vectors where done, that is make them into length 1 but keeping the direction, so the flare isn't scaled by this.

[Argh]

Yeah, that's what I was thinking, too, since the distortion is smoothly matching the change in vector...

[ILMTitan]

Looks to me like kloot fixed this.