Moving and scaling an object with a weld joint to another object.

Solar2D General Questions/Discussion
#21

Just wanted to give little feedback about how I solved it in case someone else faces a similar issue:

Regardless of whether I use sprites or particle emitters, the problem of having to move the thruster flames relative to the spaceship as the space shiprotates, remains. The only way I could solve this was to remove the weld joint and instead set the position of the thruster flames in an event frame listener.

In a sprite listener in the “began”, “next” and “ended” phases, I updated an index to know exactly in which of the sprite frames the spaceship is when rotating. This index is then read in the event fram listener and the position of the thruster flames is set accordingly.

It’s a bit tricky to explain but if someone needs a more thorough explanantion, please let me know.

#22

i’m late to this discussion and probably don’t follow everything, but i’d maybe set it up like…

if your thrusters were single-flame sprites, thus three total bodies and two separate welds to hold it all together, then I think it would have “just worked”.

you’d want to “draw” your sprites such that any implied “motion” between frames is included in the sprites, so that all frames share the same internal reference.  (that is, say you have 16x16 worth of actual drawn pixels that can moves up and down by 8 pixels between frames, so you’d really want 16x32 as dimensions, so that the “zero y” for each frame can occur at the same location)  that’ll keep your frames aligned without having to manually shift the sprite.

then during the initial physics setup you’ll have to specify offset coordinates (as engine centers presumably aren’t at hull center) for the sprites and welds, but that’s a one-time thing (and presumably at a known fixed rotation) rather than a per-frame thing at an arbitrary rotation.

having got all of that set up there should be no need to manually per-frame change the x/y position of the sprites.

#23

@davebollinger: thanks for your reply. The setup you are describing works well unless you vant to be able to scale the thruster flames in both x and y directions.

Assume a spaceship with its nose pointed upwards on the screen. At the bottom of it, left and right, are the flames coming out of the engines. As the spaceship rotates (i.e. rolls along the y axis), the sprites have to move in the x direction. This movement can, as you say, be “built in” into the sprites by just positioning the flames diffrently in each sprite frame (which then has to be wider than the actual flame itself  to have room for the movement).

Scaling in the y direction is no problem, but scaling in the x direction poses a problem since scaling is done relative to the anchor point of the frame. Since the thruster flames are placed in different positions within the frames, they will move in the x direction just as an effect of the scaling itself. To compensate for this, I would have to move the “weld point”, which is not possible.

Or did I misunderstand you?

#24

nope, it was my misunderstanding – by “rotation” i thought you meant z-spin (asteroids) not y-roll (galaga), what i wrote wouldn’t work for galaga.  your last-written solution seems best - forget the welds, just reposition the flames in an enter frame listener.

perhaps at least set the anchor at top center, and position each flame right at the “nozzle exit” of its engine, so that scaling won’t ALSO require adjusting coordinates.  then table the frame offsets (and scales if appropriate, if “discrete” values) to simplify that a bit, ex:

-- assuming they're asymmetric about x-center (due to baked in perspective) -- then you'll need separate l/r tables (ie can't just do +/- of a single value) leftFlame.x = shapeship.x + leftFlameOffsets[yRollIndex] -- presumably negative values rightflame.x = shapeship.x + rightFlameOffsets[yRollIndex] -- presumably positive values leftFlame.xScale = flameScales[thrustPowerIndex] -- etc
#25

Yes, Galaga was the kind of view/rotation I meant (never crossed my mind to refer to classic games, sorry).

I have set the y anchor to zero in order to avoid having to adjust the y position. The flame is positioned at the nozzle and the scaling just affects how long the flame is while always starting at the nozzle.

Thanks for your input, Its really valuable to have someone question my ideas, espcecially when I think I might have found a solution.

#26

btw, just food for thought…

if your sprite is hand-drawn none of this will apply, but… (many “if’s” follow)

IF your sprite is 3D-rendered

IF the true xz-center of the model was used as origin of y roll

IF you know the amount of rotation used per frame

and IF any one of the following

  1. was rendered with an orthographic projection (no perspective distortion)

  2. was rendered with a “distant long lens” (to flatten perspective distortion to the degree it can be ignored)

   (otoh, a near camera with a wide lens would *exaggerate* perspective distortion == bad)

  1. you know enough about the camera setup to correct for the perspective distortion

  (it’s a simple “1/z” -type operation, but there are some “constants” you’d need to know, or at least have a good guess at)

THEN, you could *exactly* calculate the x-offsets for your engines per frame.  imagine a circle in the x-z plane, centered on the y-axis, of radius engine-distance-from-center-y.  the position of your engines, as the ship rolls on y, will be the cosine of that angle times that radius.  (at zero degrees, it will be exactly that radius, at +/-45 degrees it’ll be sqrt(2)/2 that radius, etc)

fwiw, hth

#27

@Divergent Monkey,

You could try using a “Piston” joint for this. It’s basically like a joint that allows an object to “slide along a line” which, assuming you set it up properly, you could use to let your thrusters slide left and right. You can also set limits on the range of sliding.

https://docs.coronalabs.com/guide/physics/physicsJoints/index.html#piston-joint

Brent

#28

@Brent,

I looked into that but I need to be able to control the thruster positions manually on a per-frame basis as the spaceship rotates. As far as I can tell, manually setting the x position and let it stay there is not possible with piston joints.

#29

I’m not sure exactly what level of precise control you need, but you should be able to set/reset the piston joint “limits” in runtime, and then move the object (on the joint) to either side of the joint’s limit.

https://docs.coronalabs.com/api/type/Joint/setLimits.html

Actual “moving” of that object would be done by toggling the motor speed between 0 and whatever speed seems reasonable:

https://docs.coronalabs.com/api/type/Joint/motorSpeed.html

Brent