Setting rotation on a projectile
by Lee Latham · in Torque Game Engine · 04/01/2008 (10:07 am) · 5 replies
I wonder if anyone's run into this before. I have some large, slow moving projectiles. I thought it would be nice if they could be rotated in random directions on each shot, so the user would be presented with a more visually interesting threat.
Doing a dump on a projectile, I see that there is a getTransform() and setTransform() method. Problem is, setting it doesn't seem to do anything. I've been trying to hardcode some rotations on the ::onfire method:
I've tried putting the transform both before and after the MissionCleanup.add, but they always fire in the same orientation.
Any input would be greatly appreciated!
Doing a dump on a projectile, I see that there is a getTransform() and setTransform() method. Problem is, setting it doesn't seem to do anything. I've been trying to hardcode some rotations on the ::onfire method:
function GoofBallImage::onFire(%this, %obj, %slot)
{
// if (%obj.hold > 0)
// return;
%projectile = %this.projectile;
// Decrement inventory ammo. The image's ammo state is update
// automatically by the ammo inventory hooks.
%obj.decInventory(%this.ammo,1);
// Determin initial projectile velocity based on the
// gun's muzzle point and the object's current velocity
%muzzleVector = %obj.getMuzzleVector(%slot);
%objectVelocity = %obj.getVelocity();
%muzzleVelocity = VectorAdd(
VectorScale(%muzzleVector, %projectile.muzzleVelocity),
VectorScale(%objectVelocity, %projectile.velInheritFactor));
%pos = %obj.getMuzzlePoint(%slot);
// %pos = VectorAdd (%pos, "10 10 10");
// Create the projectile object
%p = new (%this.projectileType)() {
dataBlock = %projectile;
initialVelocity = %muzzleVelocity;
initialPosition = %pos;
sourceObject = %obj;
sourceSlot = %slot;
client = %obj.client;
};
[b] %transform = %p.getTransform();
%transform = setWord(%transform, 5, 1);
%transform = setWord(%transform, 4, 0.5);
%p.setTransform(%transform);[/b]
MissionCleanup.add(%p);
return %p;
}I've tried putting the transform both before and after the MissionCleanup.add, but they always fire in the same orientation.
Any input would be greatly appreciated!
#2
04/01/2008 (11:34 am)
I haven't looked at it recently either, but rotation may very well be blocked at the network transmission layer (bandwidth optimization).
#3
I presume it has the setTransform method for a reason? Although...it looks like that may be inherited, and projectile doesn't actually do anything with it perhaps. I'm still pretty ignorant in C++ unfortunately. One day... :-)
04/01/2008 (1:10 pm)
Hmmm, interesting, thanks guys. 'course I'm looking here at rotating once beforehand, and that's it. I presume it has the setTransform method for a reason? Although...it looks like that may be inherited, and projectile doesn't actually do anything with it perhaps. I'm still pretty ignorant in C++ unfortunately. One day... :-)
#4
However, I did find a ghetto way to get each projectile to be transformed a different way--different projectiles, each rotated differently.
LOL.
04/02/2008 (5:04 am)
BTW I tried the animation thing, but no joy. Frankly I'd have been surprised if it did work, for some reason, but when I checked the log I realized that projectile doesn't have any sort of playthread method! So of course not...However, I did find a ghetto way to get each projectile to be transformed a different way--different projectiles, each rotated differently.
LOL.
#5
In case someone comes along after:
For many things, there is no substitute for digging into the C++ code. There are a lot of shortcuts and network optimizations in the projectile class.
To orient the projectile on the client (interpolateTick) does use the current velocity to determine the attitude to display (my memory is wrong again),
via MathUtils::createOrientFromDir(mCurrentVelocity) (essentially)
The attitude is NOT sent over the network as Stephen correctly mentioned, rather rederived in this way on the client (a packet optimization). Note that the "roll" component of the attitude is lost doing this. (This just rotates the body to point along the velocity) so a spear would appear to arc in flight.
To orient the velocity as the projectile flys along on the server, the projectile ... doesn't.
On the server, the assumed attitude of the projectile is always an identity matrix. If your collision volume for your projectile is long and skinny, this can cause obvious problems. Perhaps better to do a snmall box at the origin or change the code.
If someone builds a caber (think tree) tossing game, and the player starts facing +Y but then staggers left and throws, he could mow down half the audience rather than just squashing 1 or 2. ;)
04/02/2008 (9:34 am)
Luckily you are doing spheres ;) In case someone comes along after:
For many things, there is no substitute for digging into the C++ code. There are a lot of shortcuts and network optimizations in the projectile class.
To orient the projectile on the client (interpolateTick) does use the current velocity to determine the attitude to display (my memory is wrong again),
via MathUtils::createOrientFromDir(mCurrentVelocity) (essentially)
The attitude is NOT sent over the network as Stephen correctly mentioned, rather rederived in this way on the client (a packet optimization). Note that the "roll" component of the attitude is lost doing this. (This just rotates the body to point along the velocity) so a spear would appear to arc in flight.
To orient the velocity as the projectile flys along on the server, the projectile ... doesn't.
On the server, the assumed attitude of the projectile is always an identity matrix. If your collision volume for your projectile is long and skinny, this can cause obvious problems. Perhaps better to do a snmall box at the origin or change the code.
If someone builds a caber (think tree) tossing game, and the player starts facing +Y but then staggers left and throws, he could mow down half the audience rather than just squashing 1 or 2. ;)
Torque 3D Owner Matthew Jessick