Child objects moving independently of links?
by Scott Hyndman · in Torque X 2D · 01/16/2007 (4:00 pm) · 9 replies
Let me explain what I'd like to do.
I have a SceneObject with multiple mounted children living inside. Now I'd like to move the children. How can I do this? I'm tearing my hair out here. I can set position manually (but setting velocity doesn't work), but the mount points like to take over when you least expect it and snap the child back into place. It's important that I inherit the positioning and rotation of the parent object. What should I do?
I have a SceneObject with multiple mounted children living inside. Now I'd like to move the children. How can I do this? I'm tearing my hair out here. I can set position manually (but setting velocity doesn't work), but the mount points like to take over when you least expect it and snap the child back into place. It's important that I inherit the positioning and rotation of the parent object. What should I do?
#2
01/17/2007 (7:50 am)
Velocity has nothing to do with location. velocity is a measure of the speed and direction an object is moving. Ben's tip is a good one, or you can not have it mounted at all and simply test for where the parent is and move accordingly. I do this in my current game with bullets to produce a desired effect. The bullet when created looks at the weapon to see where it is and then adjusts properly.
#3
I'm surprised this engine doesn't support relative movement, and that mountpoint offsets are the only solution. Big drawback in my opinion. I'm just going to write it myself as a component.
01/17/2007 (7:54 am)
Um...yeah, I realize. But the velocity is having no effect on the object regardless of how high I set it. Is that clearer?I'm surprised this engine doesn't support relative movement, and that mountpoint offsets are the only solution. Big drawback in my opinion. I'm just going to write it myself as a component.
#4
Try setting angularvelocity and see if it spins, just for testing.
If you are setting it in code, paste the code you use in here.
01/17/2007 (9:24 am)
Did you include the phsyics component? Is it a templated item? I've noticed at times that setting the velocity in TGBX doesn't always work. I'll change it several times, put it sky high and it'll finally work. I didn't have time to look into this further. Try setting it in code (or are you already?).Try setting angularvelocity and see if it spins, just for testing.
If you are setting it in code, paste the code you use in here.
#5
When an object is mounted to another, it's (the mounted object's) T2DPhysicsComponent will be disabled (so things like Velocity, AngularVelocity, etc. will not affect the mounted object). Instead, the mounted object receives its positional updates via the mountee (the object it is mounted to).
There are exceptions, such as rotation. If the mounted object sets its TrackMountRotation property to false, it can rotate independent of its mountee.
01/17/2007 (10:00 am)
Re: velocity not working:When an object is mounted to another, it's (the mounted object's) T2DPhysicsComponent will be disabled (so things like Velocity, AngularVelocity, etc. will not affect the mounted object). Instead, the mounted object receives its positional updates via the mountee (the object it is mounted to).
There are exceptions, such as rotation. If the mounted object sets its TrackMountRotation property to false, it can rotate independent of its mountee.
#6
I'd have to agree with Scott on this one. We should be able to move and rotate independantly from the mountee. I guess the best option at this point is to dismount, move the object and then move it to where it can remount by tracking the original mountee's location.
Is there a sort of 'moveToObject' method in TXE? If not there should be! ;)
Does the mounted object piggyback on the collision and combustable components of the mountee as well?
01/17/2007 (10:18 am)
@Trevor - You said AngularVelocity is taken from the mountee, but then say the mounted can rotate independent. So if you set TrackMountRotation to false, then AngularVelocity on the mounted is re-enabled?I'd have to agree with Scott on this one. We should be able to move and rotate independantly from the mountee. I guess the best option at this point is to dismount, move the object and then move it to where it can remount by tracking the original mountee's location.
Is there a sort of 'moveToObject' method in TXE? If not there should be! ;)
Does the mounted object piggyback on the collision and combustable components of the mountee as well?
#7
Prior to my switching over to TorqueX from straight XNA, I had set up a 3D scene graph that allowed for relative motion and rotation of all objects inside the graph. Each graph had a child graph and child object list, and each object was able to calculate it's position relative to all it's parrent graphs. This allowed for me to do things like place a sun at the center of a solar system and give it a rotation. I could create planets that had moons and the planets would rotate around the planet and had their own rotational velocity so I know it's possible to do since I did it.
The problem I see is I know my code wasn't exactly the most computationally friendly as I was just trying to get it to work and get all the math right before I tried to optimize it for a large number of objects. How this kind of idea would intergrate into the TorqueX engine, I don't know because I haven't seen the source code, but it's definatly possible hehe.
I do feel strongly that the engine should be able to support that sort of thing though, as it would make certian things a whole lot easier on the game developers, and that's the whole point of using an engine isn't it? :)
01/17/2007 (11:06 am)
I have to agree, not being able to move an object relative to it's mount point is going to suck for me down the line with some of the things I was thinking about doing... When you have to kludge around a problem by moving an object and then remounting it, it's an issue the engine should be taking care of... Prior to my switching over to TorqueX from straight XNA, I had set up a 3D scene graph that allowed for relative motion and rotation of all objects inside the graph. Each graph had a child graph and child object list, and each object was able to calculate it's position relative to all it's parrent graphs. This allowed for me to do things like place a sun at the center of a solar system and give it a rotation. I could create planets that had moons and the planets would rotate around the planet and had their own rotational velocity so I know it's possible to do since I did it.
The problem I see is I know my code wasn't exactly the most computationally friendly as I was just trying to get it to work and get all the math right before I tried to optimize it for a large number of objects. How this kind of idea would intergrate into the TorqueX engine, I don't know because I haven't seen the source code, but it's definatly possible hehe.
I do feel strongly that the engine should be able to support that sort of thing though, as it would make certian things a whole lot easier on the game developers, and that's the whole point of using an engine isn't it? :)
#8
If you force mount an object, it will consantly seek the mount point. This doesn't sound like what you are looking for.
If you want to move one object relative to another object, you aren't really looking for a mount point. Surprise! A game engine won't solve all your problems. But you sound like a capable person, problems like this should be simple enough to figure out. In this case, simply keep track of relative offset and update your position each tick. You can use the process list to make sure you always get ticked after the object you want to move relative to.
01/23/2007 (7:57 pm)
Mounted objects can be rigidly mounted or force mounted. If rigidly mounted -- they are rigidly mounted so of course you can't move them around. You can, however, animate the mount offset (as Ben suggested) or the mount point itself.If you force mount an object, it will consantly seek the mount point. This doesn't sound like what you are looking for.
If you want to move one object relative to another object, you aren't really looking for a mount point. Surprise! A game engine won't solve all your problems. But you sound like a capable person, problems like this should be simple enough to figure out. In this case, simply keep track of relative offset and update your position each tick. You can use the process list to make sure you always get ticked after the object you want to move relative to.
#9
Also, unless this has been changed, collision wouldn't be checked because moves are tested from within the physics component (what physics would it check collisions with?). There was talk about possibly re-enabling it because now the mount parent slams the Velocity (and AngularVelocity if TrackMountRotation is true) of the mount child, but there would be cases where the collision results could potentially be innacurate due to 'rotated offset' issues. It's something we talked about a while back, but I don't think has made it in.
Regardless, that's why the OP was experiencing trouble setting the Velocity. Velocity is never used by the physics component of the mount child, so you could throw any number in there and not get a different response. The reason the value appears to update is that, as stated above, the parent slams the value of the child. This is solely for the purpose of allowing other objects to accurately query the velocity of the child.
If TrackMountRotation is false, the mount child doesn't track it's mount parent's rotation (wild!). So in that case, yea your mount child would be able to rotate freely via AngularVelocity, or whatever else.
As for the combustible component.. I assume you're talking about the one in TankBuster and I can't possibly immagine a case when you would want all mounted objects to display the same explosion as the mount parent. If you're asking if mount children are deleted along with their parents, the answer is, yes - if they are owned by their mount (IsOwnedByMount = true).
Edit: Spelling.
01/24/2007 (3:48 am)
About MoveToObject, are you looking for something like this?// assume: // offset is a vec2 // speed is a float // child is not mounted child.Velocity = ((target.Position - child.Position) + offset) * speed; // <- moveToObject?
Also, unless this has been changed, collision wouldn't be checked because moves are tested from within the physics component (what physics would it check collisions with?). There was talk about possibly re-enabling it because now the mount parent slams the Velocity (and AngularVelocity if TrackMountRotation is true) of the mount child, but there would be cases where the collision results could potentially be innacurate due to 'rotated offset' issues. It's something we talked about a while back, but I don't think has made it in.
Regardless, that's why the OP was experiencing trouble setting the Velocity. Velocity is never used by the physics component of the mount child, so you could throw any number in there and not get a different response. The reason the value appears to update is that, as stated above, the parent slams the value of the child. This is solely for the purpose of allowing other objects to accurately query the velocity of the child.
If TrackMountRotation is false, the mount child doesn't track it's mount parent's rotation (wild!). So in that case, yea your mount child would be able to rotate freely via AngularVelocity, or whatever else.
As for the combustible component.. I assume you're talking about the one in TankBuster and I can't possibly immagine a case when you would want all mounted objects to display the same explosion as the mount parent. If you're asking if mount children are deleted along with their parents, the answer is, yes - if they are owned by their mount (IsOwnedByMount = true).
Edit: Spelling.
Torque Owner Ben R Vesco