Outlined physics bodies incompatible with trimmed spritesheets?

Physics
#1

Hello, I’m currently trying to create a side scroller where the level scrolls from right to left and where each part of the ground has a physics body (to prevent the character from falling off screen). I’m currently in the phase where I’m creating the level.

I’m using Texture Packer to create image sheets that include the ground sprites. Additionally, I’m using newOutline to get the shape of the physics body which I am attaching to each ground sprite.

I’ve run into the following issue:

If I use the “Trim” trim mode in TexturePacker, the physics body does not appear in the same position as the image if there is whitespace trimmed off the image.

I’ve created a test program that shows the difference in position.

I’m curious is this is expected behavior and if there is a way to fix this (aside from setting Trim mode to “None”)

Thank you

#2

Normally in situations where a physics body needs to be precise to the image, IMO one has two quality options:

A. Use Coronas Graphics.newOutline api to get a more accurate physics shape for objects.
https://docs.coronalabs.com/api/library/graphics/newOutline.html

B. Manually create a newRect/newPolygon that adheres to the dimensions you’re looking for, and “attach” the image to it with either a joint or a Runtime listener.

Not saying these are the only options, but I think they are the two that offer the most bang for your proverbial buck.

#3

Hey @Alex@Panc,

Thanks for the response. Hmmm, I feel like my question wasn’t very clear.

It more so refers to the fact that physics bodies made with newOutline are not placed properly if I’m using sprites that come from a trimmed TexturePacker spritesheet. Mainly, are trimmed spritesheets not compatible with physics bodies that use outlines for their shape?

As shown in my attached example, I’m using a trimmed sprite with an outline physics body and they are not in the same position. I’m guessing this is because the position of the sprite is based on untrimmed dimensions and the position of the physics body is based on the trimmed dimensions. Is there a fix for this that does not include using untrimmed spritesheets?

Thanks! :slight_smile:

#4

@jhow,

No, you were quite clear! I obviously skipped the portion where you mentioned you were utilizing the option that I referenced above. that’s what I get for reading on mobile while eating pie!

In any event, I think the problem is coming from the way TexturePacker is including in it’s additional table info. If you were to comment out the entries past “sourceY”, the physics body and sprite do line up appropriately. So, when I edit trimtester.lua to reflect this:

 -- floor1 x=274, y=140, width=90, height=18, sourceX = 0, sourceY = 132, --sourceWidth = 90, --sourceHeight = 150

Everything is more of less right in the world (the ball, if physics is added to it, will now hover above the image itself, but this has more to do with the trimmed bounding of the image, obviously). Granted, I’m not a savant when it comes to TexturePacker so I’m not entirely certain if those commented out values are causing/will cause issues later, but they didn’t appear to be important, since the other subtable for “floor2” didn’t have them listed. One would presume that graphics.newOutline() and TexturePacker don’t play nice together, insomuch as newOutline expects a more simplified table from which to obtain bounding info? Again, I’m no mathemagician so I’m going to leave it there.

This still makes a good case for using a dead-simple newRect and assigning the x/y/width/height values from the image to it, but for your use, it might be reinventing the wheel if the above solution/workaround operates within variance for you.

Hope this helps!

#5

Hey @Alex@Panc,

Thanks so much for the quick responses!

If you were to comment out the entries past “sourceY”, the physics body and sprite do line up appropriately.

Unfortunately, I believe that sourceWidth/Height is necessary for placing the sprite in the correct position (see Important section here). 

So while they are snapped back together, this shifts the sprite to the incorrect position. I’ve created another test program, which can be downloaded from Google Drive here. If you go to Test 2 in the program, you can see on the left what it should be like. On the right you can see what’s there. Now, if you go into the spritesheet and remove the source dimensions, you’ll notice that instead of the physics body snapping to the right position (where the sprite is), the sprite snaps to the wrong position (where the physics body is).

This still makes a good case for using a dead-simple newRect and assigning the x/y/width/height values from the image to it, but for your use, it might be reinventing the wheel if the above solution/workaround operates within variance for you.

If I could I would use basic shapes and stuff for this. But since this is a driving minigame, we want to be able to use environmental physics bodies like hills and bumpy roads and stuff, which is why weirdly shaped sprites and newOutline is useful for this scenario.

Thanks anyways for looking out, Alex.

I’m curious as to if Corona wants it to work this way. Or if it is expected behavior. Or if Corona/TexturePacker is considering doing anything about this. Also, submitted a bug report (#6098573) to get more exposure to this topic.

#6

@jhow, makes sense, I’ll leave your further inquires to minds sharper than I. Good luck!

#7

Alrighty, thanks anyways, @Alex@Panc.

Corona, any advice?

#8

Normally in situations where a physics body needs to be precise to the image, IMO one has two quality options:

A. Use Coronas Graphics.newOutline api to get a more accurate physics shape for objects.
https://docs.coronalabs.com/api/library/graphics/newOutline.html

B. Manually create a newRect/newPolygon that adheres to the dimensions you’re looking for, and “attach” the image to it with either a joint or a Runtime listener.

Not saying these are the only options, but I think they are the two that offer the most bang for your proverbial buck.

#9

Hey @Alex@Panc,

Thanks for the response. Hmmm, I feel like my question wasn’t very clear.

It more so refers to the fact that physics bodies made with newOutline are not placed properly if I’m using sprites that come from a trimmed TexturePacker spritesheet. Mainly, are trimmed spritesheets not compatible with physics bodies that use outlines for their shape?

As shown in my attached example, I’m using a trimmed sprite with an outline physics body and they are not in the same position. I’m guessing this is because the position of the sprite is based on untrimmed dimensions and the position of the physics body is based on the trimmed dimensions. Is there a fix for this that does not include using untrimmed spritesheets?

Thanks! :slight_smile:

#10

@jhow,

No, you were quite clear! I obviously skipped the portion where you mentioned you were utilizing the option that I referenced above. that’s what I get for reading on mobile while eating pie!

In any event, I think the problem is coming from the way TexturePacker is including in it’s additional table info. If you were to comment out the entries past “sourceY”, the physics body and sprite do line up appropriately. So, when I edit trimtester.lua to reflect this:

 -- floor1 x=274, y=140, width=90, height=18, sourceX = 0, sourceY = 132, --sourceWidth = 90, --sourceHeight = 150

Everything is more of less right in the world (the ball, if physics is added to it, will now hover above the image itself, but this has more to do with the trimmed bounding of the image, obviously). Granted, I’m not a savant when it comes to TexturePacker so I’m not entirely certain if those commented out values are causing/will cause issues later, but they didn’t appear to be important, since the other subtable for “floor2” didn’t have them listed. One would presume that graphics.newOutline() and TexturePacker don’t play nice together, insomuch as newOutline expects a more simplified table from which to obtain bounding info? Again, I’m no mathemagician so I’m going to leave it there.

This still makes a good case for using a dead-simple newRect and assigning the x/y/width/height values from the image to it, but for your use, it might be reinventing the wheel if the above solution/workaround operates within variance for you.

Hope this helps!

#11

Hey @Alex@Panc,

Thanks so much for the quick responses!

If you were to comment out the entries past “sourceY”, the physics body and sprite do line up appropriately.

Unfortunately, I believe that sourceWidth/Height is necessary for placing the sprite in the correct position (see Important section here). 

So while they are snapped back together, this shifts the sprite to the incorrect position. I’ve created another test program, which can be downloaded from Google Drive here. If you go to Test 2 in the program, you can see on the left what it should be like. On the right you can see what’s there. Now, if you go into the spritesheet and remove the source dimensions, you’ll notice that instead of the physics body snapping to the right position (where the sprite is), the sprite snaps to the wrong position (where the physics body is).

This still makes a good case for using a dead-simple newRect and assigning the x/y/width/height values from the image to it, but for your use, it might be reinventing the wheel if the above solution/workaround operates within variance for you.

If I could I would use basic shapes and stuff for this. But since this is a driving minigame, we want to be able to use environmental physics bodies like hills and bumpy roads and stuff, which is why weirdly shaped sprites and newOutline is useful for this scenario.

Thanks anyways for looking out, Alex.

I’m curious as to if Corona wants it to work this way. Or if it is expected behavior. Or if Corona/TexturePacker is considering doing anything about this. Also, submitted a bug report (#6098573) to get more exposure to this topic.

#12

@jhow, makes sense, I’ll leave your further inquires to minds sharper than I. Good luck!

#13

Alrighty, thanks anyways, @Alex@Panc.

Corona, any advice?