Can you narrow down when this happened? We know 2295 is a problem and 2263 is good. Can you split the difference and see if it works or not? Continue splitting the difference until you find the last one that worked and the first one that didn’t.
That will help us try and narrow down what change broke. I know engineering is going to also want a test app, before we can ask them to look into it.
Thanks
Rob
In order to illustrate the problem clearly, I uploaded two vidoes.
video a: Build with 2014.2275
http://www.youtube.com/watch?v=WF7pN7PlII4
video b: Build with 2014.2306
http://www.youtube.com/watch?v=tUfZa9rYP_U
In video b, the car floating in the air, and not fall to the ground.
This problem occurs on both the simulator and real device(iPad).
Hi @pickerel,
Thanks for the info, but may I request a bit more? For example:
How is the car constructed? I assume multiple body parts attached with various joints.
Are all of the parts “dynamic” in body type?
Do you use any line objects in the construction?
Is physics being assigned to a “group” of parts (display group)?
I’d be most curious to see if this issue can be reproduced outside of LevelHelper. As a 3rd-party product, we can’t know how it’s handling things internally, especially the construction of complex physics bodies. Of course we’ll try to figure out what may have changed between the two builds, but to have a car behaving normally in one build but “floating in air” in another build seems quite suspicious, and I haven’t encountered anything along these lines in normal Corona development (and I do a lot of physics stuff). If you specify how you’ve created the car (basically) then maybe I can reconstruct a similar object and test on my side.
Thanks,
Brent
I did some tests, and it seems the algorithm about the physic edge was changed afer 2014.2275 or later version.
Wish these screenshots can give you some help.
All the physic edges were stroked with sprite helper pro.
I am getting similar issues. I’m getting unexpected 60x60 squares with some physics objects.
Hi @pickerel,
Thanks for the detailed reports. I discussed this with the engineers, and to determine whether this is an issue with Corona vs. Level Helper, we’ll need you to file a bug report on the “second” example in your post (the screenshot where you’re creating physics bodies on a siren, a propeller, and a “taxi” sign. More specifically (and hopefully more simply) we need to see the physics body declarations and how Level Helper is generating the shapes for them. Can you pull those from your code and submit them as a separate project, zipped up with the assets and main.lua?
Thanks,
Brent
Hi Jeff,
How are you creating your physics objects and shapes? Can you give me an example of one that is mis-behaving in recent builds? Thanks.
Hi Brent,
This is a function that we use to create a train track on our map. The code has been working for over a year now. The square physics body problem emerged for me starting Build 2014.2281.
local function createTrack(trackObj, shapeDef) if trackObj == nil then trackObj = display.newRect(2,2,2,2); trackObj.x = 240; trackObj.y = 164; trackObj.alpha = 0; backgroundGroup:insert(trackObj); physics.addBody(trackObj, "static", shapedefs.physicsData():get(shapeDef)); end return trackObj; end
The shape definition and some other information for one of our problem cases can be found in the following discussion:
We use a physics shape def file created by Physics Editor.
In the physics debug, I see the shape trying to be created, but now I also see a 60 by 60 square collision box in the center of my screen. This has never happened before.
Hope this can be resolved soon!
Thank you.
It seems not a problem of level helper or physic editor.
this is a simple test to reproduct this bug.
-- system.activate("multitouch") display.setStatusBar(display.HiddenStatusBar) screenW = display.contentWidth screenH = display.contentHeight centerX = display.contentCenterX centerY = display.contentCenterY L = display.screenOriginX R = screenW - display.screenOriginX Ceiling = display.screenOriginY Bottom = screenH - display.screenOriginY realW = R - L realH = Bottom - Ceiling AspectRatio = realW / realH ------------------------------------------- -- \_G.physics = require("physics") physics.start() physics.setGravity(0, 9.8) physics.setDrawMode("hybrid") -- physics:setScale(60) ------------------ test physics ----------------------------------------------------------- -- -- local nebula = display.newImage( "nebula.png" ) local nebula = display.newRect( 0, 0, 50, 50 ) nebula.x, nebula.y = display.contentCenterX, display.contentCenterY -- local podT = {1,-89, 14,-83, 20,-70, 14,-57, 1,-51, -12,-57, -18,-70, -12,-83} -- local podR = {69,-20, 82,-14, 88,-1, 82,12, 69,18, 56,12, 50,-1, 56,-14} -- local podB = {1,49, 14,55, 20,68, 14,81, 1,87, -12,81, -18,68, -12,55} -- local podL = {-70,-20, -57,-14, -51,-1, -57,12, -70,18, -83,12, -89,-1, -83,-14} -- local shapeA = { -1.625, -16.625, 9.625, -12.375, 15.875, 15.625, -16.625, 15.625, -10.625, -9.125} local shapeB = { 9,-16, -1,-16, -1,-17 } physics.addBody( nebula, "static", -- { shape=podT }, -- { shape=podR }, -- { shape=podB }, -- { shape=podL }, -- { shape=shapeA } { shape=shapeB } )Hi @pickerel,
I explored this a bit further and I have some guesses on what’s going on. One thing that appears to cause this issue (and for Jeff as well) is that you’re declaring physics bodies with some coordinates that are 1 pixel apart… in other words, element definitions that are so small, my suspicion is that more recent versions of Box2D are rejecting them and demanding that the bodies be more “substantial” in size. If you increase the size of these elements, things should work as expected, and to be honest, creating bodies that small might not even register collisions very well, or they may “tunnel” into a larger object before Box2D picks up the collision of them. Effectively, you’re creating a minuscule element that’s like a hairline in terms of the physics engine, which I really don’t recommend.
I’m willing to explore this further if the issue pertains to larger body elements as well. Otherwise, I suggest that you modify your elements and build them more logically under the expectations of the physics system and the inherent limitations of it.
Best regards,
Brent
Hi Brent:
Did you update box2d engine after version 2014.2275? If it’s true, is it possible to downgraded the engine?
All the physics were created with sprite helper, it’s not an easy thing to increase the size of these elements.
I think it is a critical bug(sprite helper & physic editor have been affected ), Corona Labs should devote more time to solve it faster.
If it’s can not be resolved, give us a final conclusion.
thanks.
@Pickerel, I had a similar problem on something I was working with and ended up doing what Brent said but used physic editor to work the collision box around the sprite a little better. If you save each PE lua file as “single per image” and name it the image.lua you can simply just call it by image name when building your addBody etc. pretty simple and light weight.
I don’t think this is really a bug as it will do the same exact thing in pretty much any engine, or straight c++, java, objective-C or just physics in general.
In my experience your physics objects should be at least 2-4 px apart and as is the case with most thing I find that using multiples of 2 saves a lot of grief in the end.
Hi,
I don’t use Physic editor. All my physic shapes were created with SpriteHelper. I don’t know where to set “single per image”, and I really do not want to so, because my project has been released, and all the levels already test ok with 2014.2275.
I think it’s a critical bug, because this project runs ok with 2014.2275 and earlier build.
I read all the release notes of daily build from 2014.2275 - 2014.2295, It seems they did not changed anything about physic.
Hi again @Brent Sorrentino,
Thank you for your response.
If you don’t mind, a few more questions. I’d just like a bit more closure before I resort to seeking out all the physics bodies in our app to see which ones need reshaping (unfortunately, we have many bodies). I hope you understand.
Like @pickerel, I am also curious as to why this would happen at this build in particular. What changed in Box2D that made the expectations of the physics system different? As I stated earlier, our project was written over a year ago and has never had any such issues with the shapes. Isn’t manually re-setting the coordinates of the physics body more of a superficial solution that is ignoring the root of some issue (ie. proper handling of close vertices)? By no means am I trying to sound accusatory with that question.
In regards to the solution being that we should reposition vertices in a manner which they are not close to each other… doesn’t this mean that this issue could appear for pretty much anybody who is using the " Automated Shape Tracer" with a relatively low tolerance (pending shape complexity obviously)? Is that something that we users just have to accept?
Thank you!
Jeff
Hi guys,
We’re investigating this now but we don’t have a thorough answer at this time. We need to investigate what’s happening below the hood with Box2D. When I have an accurate response, I’ll let you know.
Thanks,
Brent
Hi @Brent,
How’s it going? I’m sorry to rush you, but I’m eager to release a new version of my app.
thanks.
Pickerel
Hi Pickerel,
This issue has been assigned to engineering but it’s behind some other high-priority items. If you need to release your game a.s.a.p. then you’ll need to use the latest build in which the issue did not appear, or locate the body elements that are causing this issue (which is what I’d recommend you do regardless since they are prone to other potential problems, but I understand that you can’t easily locate these because of the 3rd-party tool(s) you’re using).
Best regards,
Brent