I am creating a spritenode, setting its position and changing its anchorpoint to (0, .5) and then creating a phyicsbody.
The physicsbody thinks my anchorpoint is still at (.5, .5), stupidly.
The same problem is referenced here, but unsolved: Physicsbody doesn't adhere to node's anchor point
The order I am doing things in is correct, it's just my physicsbody is stubborn.
The anchorPoint determines where the node's texture is drawn relative to the node's position. It simply does not affect physics bodies because it's a purely visual property (a texture offset).
For physics-driven nodes it is actually counter-productive to change the anchorPoint from its default because that will change the point around which the texture will rotate. And the physics body will usually also change the node's rotation.
So even if you were to move the physics body shape's vertices to match the sprite with a modified anchorPoint, the physics shape will be misaligned with the image as soon as the body starts rotating. And it'll seem to behave weird.
Plus whatever you want to achieve using anchorPoint you can more flexibly achieve by using the node hierarchy to your advantage. Use a SKNode as the physics node, and add a non-physics sprite node as child to that node and offset it the way you wanted the image to be offset by changing the sprite's anchorPoint.
You end up having two nodes, one invisible representing the physics body and one (or more) sprite(s) representing the visuals for the body but not necessarily tied to the body's center position.
Related
I am adding the main node and the child nodes to it.
All nodes should be rotating from a variable anchorpoint.
So when I change the anchorpoint of the main node, the distance between the child nodes and the main nodes is being changed(the distance between the childnodes remain the same).
Why is this happening and how can it be solved?
EDIT: 6-5-2015
Here I draw my situation. The anchorpoint of the Main piece is (0.5, 0.5). So when I change the zrotation the whole road will turn around the main part. Than I change the anchorpoint to the second piece(child) so the anchorpoint of the main part becomes (0.5, 1.5). But when I do this the main part moves downwards and I still don't have the rotation point I want..
How can I do this?
The anchorPoint has a value range of 0.0 to 1.0 (0% to 100%). If the anchorPoint is 0.5x0.5 (the default for nodes with textures) then the texture is centered on the node's position. If the anchorPoint is 0x0, then the texture's lower left corner aligns with the node's position. If the anchorPoint is 1x1 then the texture's upper right corner aligns with the node's position. This makes anchorPoint most popular when it comes to left, right, top or bottom align nodes. It is most often used to align text labels or to align screen elements with screen borders. Here are some examples:
I am using Apple's Sprite Kit to create a game, and currently I have drawn an SKShapeNode object that looks similar to the following:
My actual sprite has rounded edges, but for simplicity, I am trying to get everything working with this shape first. I am able to draw the sprite perfectly fine. However, I am having trouble creating a physics body to cover the sprite. I want the sprite to recognize collisions anywhere along its surface, so I want a physics body that covers only the dark gray area. Also, I want the sprite to respond to forces and impulses, so I need a volume-based physics body.
My first idea was to simply use the same CGPathRef that I used to create the image for the sprite, and pass it to the bodyWithPolygonFromPath method to create a corresponding physics body. I have come to find this will not work, as my shape is not convex.
So, now I am thinking I should be able to use bodyWithBodies to create a physics body shaped appropriately. I want to create three rectangular physics bodies (one to cover the left of the gray area, one to cover the top, and one to cover the right), and use those to create one physics body whose area covers the gray area of my sprite by using this:
mySprite.physicsbody = [SKPhysicsBody bodyWithBodies:#[body1, body2, body3]];
However, the main problem I am having is correctly positioning the individual bodies that go into the array, which is passed to the bodyWithBodies method. By using the above method, I obviously have no way of controlling where these physics bodies are being placed in relation to each other. The result is all three physics bodies stacking on top of each other in the center of mySprite.
How exactly are you supposed to position the physics bodies in the array relative to each other before passing them to the bodyWithBodies method?
Docs for SKPhysicsBody bodyWithCircleOfRadius: says:
Creates a circular physics body centered on the owning node’s origin.
So is origin a node position? Couldnt find it anywere.
So is origin a node position?
The origin is the point with coordinates (0, 0) in a given coordinate system. However, you typically deal with a number of different coordinate systems when working with computer graphics, and each one has its own origin. For example, every view in a view hierarchy has its own coordinate system. So, you need some context to know exactly which one you're talking about.
From the SKNode docs:
Every node in a node tree provides a coordinate system to its
children. After a child is added to the node tree, it is positioned
inside its parent’s coordinate system by setting its position
properties.
You also commented:
Im confused becouse 'origin' also is mention in SKScene docs, and its different than frames origin
SKScene is a subclass of SKNode, and so it's also the case that every scene provides a coordinate system. This isn't surprising -- a scene is just the root node in a tree of nodes.
Don't confuse the origin of a node's frame with the origin of the node's own coordinate system. A CGRect is defined by two things: a CGPoint called origin, and a CGSize called size. A node's frame is the rectangle that defines the node's bounds in the coordinate system of the parent node. The node's origin might happen to be at the same place as it's frame's origin, but they're not the same thing. For example, the origin of a scene is at it's anchorPoint -- that is, the anchorPoint property of a scene indicates some point in the view that contains the scene, and that point has coordinates (0, 0) in the scene. Neither of these have anything to do with the frame or frame.origin.
Origin is normally a point. However, it is slightly confusing to speak of a SKNode's origin, because that is not a property of the SKNode in the same sense that it is a property of the SKNode's frame. If you do a keyword search in apples' sknode docs for the word 'origin' you will find it zero times. However, I agree with the consensus below that despite this lack of mention in the SKNode's docs, the origin of a node is more likely to refer to its position than to its frame's origin. So while you would get the SKNode's frame's origin's x and y values like this:
node.frame.origin.x
node.frame.origin.y
That does not necessarily describe the node's origin. I hope I have made this answer more accurate and less confusing :)
Here is my setup:
SKScene with a node called world
to this world, I attach another node: vehicle
to this vehicle, I attach three nodes that make up the vehicle; a body and two wheels
the wheels are attached to the body via SKPhysicsJointPin specifying their anchors
Now, everything is fine until I zoom out of my world:
[_world runAction:[SKAction scaleTo:0.5 duration:0.75]];
My vehicle suddenly lifts off the wheels. It appears as if the same distances as in the not-zoomed-in-world are kept. All parts of the vehicle are properly scaled- except the distances to its parts.
Do I have to apply the zoom to my joints as well? Or do I need to reset the anchor of my joints?
Thanks for your help!
Physics don't scale. Changing a node's scale is a purely visual effect, it does not alter physics in any way.
Even if you manually update physics positions synchronized with a node's scale you'll find that you can't scale each body's shape without removing the previous body and replacing it with a corresponding body of the same shape, just scaled. During a scale action you would have to through away and create new bodies every frame, which will probably cause a serious framerate issue.
In Cocos2D I am creating my CCSprites with anchor points of (0,1) which is similar to the way UIKit does it. Anyway, I am trying to change the anchor point in Box2D, is this possible?
If so how would I do it with an anchor point of (0,1)?
Thanks!
Box2D bodies don't have an anchor point.
The anchorPoint is an offset of a node's texture relative to the node's position. Box2D bodies don't have a texture, hence no anchor point.
Generally speaking you're going to make a lot of things more difficult by changing the anchorPoint from its default 0.5,0.5 position. Like, for example, the issue that lead you to ask this very question.
Changing anchor point of shapes in body :
do a for loop to get the smallest x vertice and the biggest, substract to get the width, you can do in the same loop get smallest y vertice and the biggest and substract,
if you then move all vertices with the differences you will position the shape in the 0,0.
it works not sure if the best solution.