I want to know if there is a way to check the perfect collision of two SpriteKitNode objects. Below I added an example of what I want.
I tried the SKNode.intersects(_:) but this check the collision of the whole object yellow and pink rather than the object from images.
The objects I will use will be a SKSpriteKitNode with a png SKTexture.
Thanks!
This is not an answer, but an attempt to illustrate my comment above. Physics bodies used for collision detection can be (in increasing order of computational cost) circles, rectangles, polygons or bitmap perfect.
Unless you have a very-real need for pixel-perfect collisions (large sprites, slow-moving etc), using circular and rectangular physics bodies for your scenario (the red outlines in the 'wrong' section' of the image below) might be enough:
The axe body could be easily change if necessary to an 'L' shaped polygon, for more accurate collisions with a (hopefully) slight increase in cost.
Related
I'm creating a puzzle game that generates random sized pieces with 2D meshes. The images contain transparent portions and sometimes a piece is completely transparent. I need to detect what percentage of a piece is transparent. One way I found to do this is to go pixel by pixel. I posted my solution to this HERE. However, this process adds a few seconds during loading which I'd like to avoid and I'm looking for other ideas
I've considered using the selection outline of a MeshCollider to somehow to get a surface area I can compare to the surface area of the mesh but everything I find is on the rendering of outline with specialized shaders. Does anyone have any ideas on to solve this?
.
1) I guess you could add a PolygonCollider2D to your sprite and use its Path for the outline and calculation of the surface area. Not sure however if this will be faster.
PolygonCollider2D.GetPath:
A path is a cyclic sequence of line segments between points that define the outline of the Collider
Checking PolygonCollider2D.GetTotalPointCount or path length may be good enough to determine if the sprite is 'empty'.
Sprite.vertices, Sprite.triangles may also be helpful.
2) You could also improve performance of your first approach:
instead of calling GetPixel as you do now use GetPixels or GetPixels32 and loop through the array in one for loop.
Using GetPixels can be faster than calling GetPixel repeatedly, especially for large textures. In addition, GetPixels can access individual mipmap levels. For most textures, even faster is to use GetPixels32 which returns low precision color data without costly integer-to-float conversions.
check only every 2nd or nth pixel as it should be good enough for approximation
limit number of type casts
I try to begin new game development that has rotating circle that has one or many holes as in the attached image , the problem is I need to use circle collides for the big circle., in addition I need to use small collides for the smaller holes to prevent and particles(smaller circles ) input the circle and to count no of collisions occurred
enter image description here
The circle collider itself does not have this functionality since it can only check collisions between perfect circles. (Behind the scenes all circle colliders just check the distance between points and these distances do not work with holes) The best solution I can think of would be to use a polygon collider and make a rough circle that you can then remove parts of (would require some advanced geometry but not impossible). I have tried simillar things in 3D and with the mesh collider, removing parts of it using a method known as CSG (Wikipedia) and something simillar should be possible in 2D however it is really, really hard and even experienced programmers struggle to come up with a system that can handle every scenario.
All hope is not lost though, depending on what you need the collision for, there might be other ways. If you just need to check if two objects intersect and don't want rigibodys and stuff to interact with the collider just checking the distance between the big circle and the object (too figure out if it's close enough) and then checking the distance between the object and the holes (too see if it's inside a hole on thus not colliding) is the best way to solve the issue.
I'm sure someone who have done more in this field than I have will be able to help you out but without more information of what you need it's impossible to say. It all depends on the circumstances!
Like the image attached, I want to get a polygon collider of the area of the biggest collider subtract the areas of these two smaller colliders inside the big one?
I just want to have a collider that covers only the gray area in the image below.
At runtime please, it's ok to get a composite / polygon or what other types of collider.
Thanks very much.
Fastest way would indeed be to have 3 separate Colliders, and when collision happens with the big one, you also check that it does NOT happen with the two smaller colliders.
Check the Clipper library for polygon operations (also worth checking the eppz! Geometry library, which itself uses Clipper).
You can then use the resulting polygon "paths" (as it's called in the Clipper library) to create several EdgeCollider2Ds (you can [set its points][4] to create the shape of each polygon.
There is a problem with this approach though, which is that in the end you will not have a "solid" collider with an inside and an outside, and instead you will just have lines to collide with. Hopefully this will not be an issue for most of the cases.
I am not sure but you could use separate box colliders to get the same affect. Just need multiple references in the script.
I have this situation: http://mokainteractive.com/example.png
I'd like to move the white ball inside the red track and detect wherever the balls touch the limit of the red track.
Which is the best solution? I have to create multiple transparent shape along the borders? Do you have other ideas?
thanks so much
In iOS8 you can create a single physics body for that kind of shape.
Make a texture of your shape with p.e. Adobe Illustrator and use this method:
init(texture texture: SKTexture!,alphaThreshold alphaThreshold: CFloat,size size: CGSize) -> SKPhysicsBody
The SKTexture is your shaped image. The body is defined by the colored pixels.
The alphaThresHold: The minimum alpha value for texels that should be part of the new physics body.
The Size is clear I think.
The texture is analyzed and all invisible pixels around the egg are ignored and only the color pixels are interpreted as the body of the SKPhysicsNode. You should use too many of these because they are very expensive to calculate for the Physics Engine.
Variations of this method are found in the SpriteKit Class Reference.
To your problem. Make an inverse texture of your area which should be transparent and pass it as texture to the physics body. It will be analyzed and a body around the free zone is created.
You cannot create a single physics body for that kind of shape.
Using bodyWithPolygonFromPath: will only allow you to create a convex polygonal path which obviously does not work for your shape.
I think you have 3 options here:
Use a number of bodyWithPolygonFromPath: bodies (probably the hardest to do and time consuming).
Use a number of various size bodyWithRectangleOfSize: bodies (not so hard but time consuming).
Use only straight lines in your image and use bodyWithRectangleOfSize: (the easiest and fastest). If you choose this option remember you are still free to rotate your straight lines to various angles.
I'm rendering particles in a 2D game. Each particle is a quad (2 triangles). How can I make the drawing the fastest possible? All the particles has the same texture, I'm only changing it's positions.
Now I'm using a call to glVertexPointer and glDrawArrays for each particle. So I'm sending 4 vertices each time to the GPU.
Is there any other approach that could be faster?
I'm using OpenGL ES 1.1 (iPhone)
Thanks!
Every draw call you make (glDrawArrays) is expensive. Doing this once per particle is DEFINITELY way too often. All your particles can be drawn with a single draw call; just set up a big array of all the triangle verts and another big array with the texture coords, and call glVertexPointer/glDrawArrays once-- that's the power of glVertexPointer: arbitrary geometry of the same type in one call. :)
For what you're doing, you should also look into point sprites (GL_POINTS), which also function as tiny textured quads. They're 2D only, so you can't map your texture into the Z axis, but if your particles are just 2D quads of the same texture over and over, point sprites will likely do exactly what you want.
There's a way to do that all in one draw routine. I THINK it's by adding an extra vertex after each quad, which is the same as the previous vertex, but I could be wrong.
EDIT: After looking into it a bit, it looks like you need two in between; essentially one after, and one before. It does add up to quite a few extra vertexes, but I know from experience that it makes a HUGE positive difference on the iPhone to do it all in one draw operation (we were drawing text from a texture, so essentially the same thing).
EDIT2: Also note, I'm referring to using GL_TRIANGLE_STRIP - if you were using GL_TRIANGLES instead, you wouldn't need the extra vertices... except, then you'd be doing the same amount extra anyway, due to repeating 2 for each second triangle.