non-normalized direction vectors on some projectile trails
Moderator: Moderators
non-normalized direction vectors on some projectile trails
Some projectiles give non-normalized direction vectors to their trails. That's both good and bad, it's obvoiously bad for adding effects that assume normalized vectors but it's good for making effects that use the actual speed of the projectile for something (which can vary for some types so it can't be simulated in the CEG). So I'm unsure if it should really be fixed.
Re: non-normalized direction vectors on some projectile trails
Forgive my ignorance but could you further explain, I am not sure I am getting what you are asking.
Re: non-normalized direction vectors on some projectile trails
In normalized vectors, the largest component is always 1. Working with vectors that aren't normalized can give some quirky results in some situations but the magnitude of the vector is preserved.smoth wrote:Forgive my ignorance but could you further explain, I am not sure I am getting what you are asking.
Re: non-normalized direction vectors on some projectile trails
normalize means that the length of the vector is scaled
to 1.0, while maintaining the same direction, as in:
length = sqrt((x*x) + (y*y) + (z * z))
newX = x / length
newY = y / length
newZ = z / length
Peet's explanation confuses me.
to 1.0, while maintaining the same direction, as in:
length = sqrt((x*x) + (y*y) + (z * z))
newX = x / length
newY = y / length
newZ = z / length
Peet's explanation confuses me.
Re: non-normalized direction vectors on some projectile trails
Perhaps he means the largest possible component.
Re: non-normalized direction vectors on some projectile trails
Yeah...bad explanation on my part. Working and foruming do not combine gracefully.
Re: non-normalized direction vectors on some projectile trails
What benefits would this yield?
Re: non-normalized direction vectors on some projectile trails
Benefit to 'fix': Effects that assume it's 1 in length work properly, and can save a very small calculation if they don't confirm.
Benefit to keep: Effects know the speed and can use it.
Benefit to keep: Effects know the speed and can use it.
Re: non-normalized direction vectors on some projectile trails
sqrt is not small, though. I'd fix it and add something that returns speed in CEGs (but I have no idea how they work, so don't know how hard would that be.)
Re: non-normalized direction vectors on some projectile trails
but wouldn't the 'fix' be worse performance-wise, as some effect dont need normalized direction, and fix would normalize it for all?imbaczek wrote:sqrt is not small, though. I'd fix it and add something that returns speed in CEGs (but I have no idea how they work, so don't know how hard would that be.)
LUA does square root just as fast as C anyway...
edit: or you're thinking of case when theres a lot of effects some having sqrt some not and those that have doing it over and over again on same vector?
Re: non-normalized direction vectors on some projectile trails
pretty much that, yes; also, principle of least surprise - I'm used to direction vectors being normalized.dizekat wrote:a lot of effects some having sqrt some not and those that have doing it over and over again on same vector?
Re: non-normalized direction vectors on some projectile trails
I'd suggest a keyword like "velocity" for vector values to get the velocity vector.
Re: non-normalized direction vectors on some projectile trails
I am not sure it is worth fixing. I do not see any reasonable advantage to changing it and with all the effects that would have to be refactored it would create a lot of work.
on the other hand a secondary set would be confusing also. I understand legacy tags for TA content but for engine specific stuff I would hate to see it. Unfortunately I suspect this change will break many of the CEGS in use.
or do I understand it wrong?
For such a change to break soo much it would have to have some seriously great advantages which I am somehow missing.
on the other hand a secondary set would be confusing also. I understand legacy tags for TA content but for engine specific stuff I would hate to see it. Unfortunately I suspect this change will break many of the CEGS in use.
or do I understand it wrong?
For such a change to break soo much it would have to have some seriously great advantages which I am somehow missing.