I'm working on a 2D physics game that involves collisions between objects which at the moment use complex polygon colliders.
When the objects collide, I get the normal of the contact point using otherObject.contacts[0].normal, and knock the objects apart in equal-but-opposite directions using Rigidbody2D.AddForceAtPosition, with the force being the normal multiplied by a constant.
Most of the time this works flawlessly, but I've found that when the collision occurs with a concave section (aka: an inward "dip") in the polygon collider, the normal will be flipped, and the objects will instead get pushed towards each other.
Alternatively, are there any other ways I could go about solving this?
The blue circled area is an example of a problematic concave section
Alternatively, are there any other ways I could go about solving this?
Yes, the standard thing in vid games is that most stuff has many small simple colliders, rather than one large complex collider.
This is a basic of game engineering.
(It can be very surprising to hobbyists and folks new to the field.)
So, imagine a car in any ordinary 3D game. You'd have a collider for the rear bumper, one for the front, maybe one for "left doors" and so on. Very typically, each has to react in a different way, and you need to know which area was touched.
In your case if the 2D poly has say 12 edges, just make 12 "small" as it were colliders for each of the edges.
We know nothing about your setup since no screenshot, but that could possibly work.
Note however that Unity's 2D poly collider in fact already does know to slice the object in to smaller triangle-like shapes if it is concave - I'm surprused it dinnae work for you.
Further: now that we can see your image.
In any video game on Earth, the way you'd do that helmet is with a square collider as in orange:
If (for some reason .. why? for what purpose? how? where? what possible reason could there be?) you were making the most precise video game, ever created by humans, on an entirely new plane of engineering, for some imaginary new hardware with quantum warpspace cores, ... in that case ... you'd maybe add the two extra colliders to cover the horns. But nobody would ever notice the difference.
I appreciate you may be doing something exceptionally unusual, like a "close up game" ("you're an atom in medieval Scandinavia, bouncing off helmets" or whatever), in which case there'd be some other solution.
The very short answer is you've stumbled on one of the most surprising things about game technology ... we use crappy, simple, colliders, you've been tricked all your life in every title you play!
Related
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!
Lets say I create many different 3D objects (Arms, legs, body, head). How would I go about making it so all of them can connect to form a body. And after the body is formed make it so they all animate in the same way. Can anyone help me in the right direction with tutorials or links on these topics?
Here are some good tutorials:
https://www.youtube.com/watch?v=q3oVAXhvQl0
https://www.youtube.com/watch?v=Ch1aJljEYp4
https://medium.com/#larissaredeker/3d-character-customization-fd95a1d57ae
And here a reddit user's answer(Named DankP3):
For body sliders you will probably want to look at blendshapes, this is done in the modelling programme. The more blendshapes you have the more complex it will get. eg. 'normal' 'thin' and 'muscular' bodies at one scale of variation and thicker eye brows at the other.... Of note though, facial morphs don't affect most clothes!
I think one of the most challenging parts will be that using the same animation on a thin character and a muscle bound character will not look good so some significant animation work may be required.
I'd probably apply hairstyle in the same way as clothes (see below), but colour can be manged for hair easily through code, swapping base colours, or textures.
For clothes, you rig to the same skeleton as the character (and you will need the same blendshapes to fit the body or if your body is to change shape). A lot of people put all clothes in the same model and turn them on and off as required (this intuitively seems messy), but looping through the bone array on the meshrenderer is not difficult and contrary to what the other reply says you don't need to match bones by angle and position. if you rig correctly, you can just swap, rather than match, the bones in the clothes mesh renderer for those on the character model when the clothes are put on and you are all done.
Again, all credit goes to DankP3
You can see his answer HERE.
Hi I have a small question on how the raycasting with layermasks work vs using RaycastAll.
I am trying to project my rays from inside my object and layermask the rays to collide with the same layer as the original object, therefore i need to ignore the "hit" on the original object itself.
My question is: when Raycasting uses a layermask does it register a collision with other undesirable layers too and then simply ignore them, or does it not even register a collision with those layers in the first place? Would it be worse or equal on performance if I used RaycastAll to logically decide to respond to a layer or not vs somehow using strictly layermasks? Or is it not even an appreciable difference?
I know some posts say that "if you cast it from inside the object it wont collide with that object" but evidently it does.
Thanks
You can take a look at official Unity's physics preformance tutorial. To start with, Raycast is rather cheap operation but it's performance really depends on how you actually do Raycasting. For example, for one of your questions - RaycastAll is more expensive than doing Raycast on a separate layer, it's also mentioned in the link above. It's based on how actually physics work. Unity doesn't implement physics itself, instead it uses existing solutions (like PhysiX for 3d, and earlier it was Box2d for 2d physics).
Also the length of your ray actually influences Raycast's performance. The shorter ray you cast the better performance you get. The worst case is Raycasting to infinity. Another case is that Collider.Raycast is cheaper than Physics.Raycast.
It's no secret, that there is nothing more that some bunch of math equations behind physics in game development so you may thing in such things - the simplier equation you have, the better performance and time to complete you get. So Raycast can be treated as system of equations where you have the equation of the line (actual Raycast) and some number of equations, which describe some 2d/3d object in plane/space and the task is two calculate the points of intersection between your line (Ray) and other objects.
If you don't have complex physics in your game you may not see the difference between RaycastAll and Raycast with layermask, or shorter ray's length, but performance really differs.
I'm new to using xna and I want to make my player collide with with multipe walls from the same class. So I looked around and I understood that the best way for doing that is to create a list of variables containing the walls id's and make a loop that circles them all and then returns the variable of the objects that collide.
My question is if there is a faster more efficient way for doing that? I mean if I have like 10000 objects that loop can cause a lot of memory use.
Thx in advance
Option 1) If these 10000 object are walls of a level, then you should probably use some sort of grid (like this very old example: https://en.wikipedia.org/wiki/The_Legend_of_Zelda#mediaviewer/File:Legend_of_Zelda_NES.PNG)
With a grid you only have to check collision with adjacent objects, or only with objects that are nearby.
Option 2) If these 10000 objects are enemies or bullets that move more freely, then you could also calculate the distance first and only check for collision if the objects are nearby.
But may I ask why you are using XNA? I used to work with XNA 4.x but in my understanding it is pretty much dead (http://www.computerandvideogames.com/389018/microsoft-email-confirms-plan-to-cease-xna-support). If you're new to XNA, I would advice to use other software to make games (like Unity3D). In Unity3D the hard part of collision detection is done for you (is has standard functions for collision detection) and Unity3D also works with C# (like XNA)
You always want to do the least amount of processing to get the job done. For a tiled 2D game you usually have a 2 dimensional grid. When the player want to walk on a certain tile you can check that tile if it is allowed to walk there. In this case you just have to check a single tile. If you have a lot of NPC's you could divide your map into sections and keep track of in what sections the NPC's are. Now you just have to do collision detection on the enemies within your section.
When you need expensive collision, pixel perfect or polygon collision you should first check if an object is even close with a simple radius float or BoundingSphere only then you go on with more expensive collision detection.
Same goes for pretty much anything, if you have a 100x100 tilemap but only need to draw 20x10 for the screen then you should just render that portion by calculations. In unreal, mappers create invisible boxes, when inside these boxes it only draws a certain part of the map and only checks collision within these boxes. GameDev is all about tricks to make things work smoothly.
xcode 5 iOS7 sprite kit.
My wish is to make a sprite that has its own gravity.
Like a planet. If another sprite comes within a certain range of it, it will slowly pull the other sprite closer.
I have two sprites. One moving and one stationary. When the moving sprite gets in a given distance of the stationary sprite the stationary sprite gravity should slowly pull the other sprite towards it. This way the moving sprite would change its path in a soft curve.
My idea would be to calculate the distance from the stationary object to any other object and if close enough start pulling and if the moving object gets out of range ageing, then stop pulling.
Would probably need to research some vector calculation.
Thats my immediate thoughts.
Is this possible and how? Does it already exist?
A friend of mine did this for his physics dissertation. multibody gravity simulation. So yeah you can but you need to be willing to learn some maths. Apparently there is a clever optimisation to make it run decently nlog(n) rather than n^2). you probably want to ask this on the physics version of stack overflow to get a good answer. I have the code at home ... will post it later but you will want an explanation - i used it in an xna app. Its badass once you get it working - although if you want naturally orbiting objects then you will want to code them using parametric equations for easy and cool orbits. Simply because its hard to solve and with time even using double will result in some errors (the good implementations also work out the error and adjust - again will post later). But the real problem is solving for stable orbits. You then use the algorithm for free moving bodies such and player objects / npcs. Although solving accurate movement for npc in a changing field is v hard.
you want to look at this question: Jon Purdys answer is the one you want
multi body physics - gravity
and this one (which is linked from above) ...
https://gamedev.stackexchange.com/a/19404
There is not a dead-simple way of doing that in any platform as far as I know maybe except for some game engines/platforms that export for different platforms (cocos2d, construct 2 etc).
What you need is a physics engine whether you write one (which is a complicated but fun thing to do) or use an available one.
Luckily I've found a link describing the usage of the famous 2D physics engine "Box2D" on iOS.
This one explains how you can include Box2D in an openGL application (but you can apply this to other environments (sprite kit) I think altough I'm not an iOS guy);
http://www.iforce2d.net/b2dtut/setup-ios
Anyways, you now know what to look for...
For iOS 8.0+ : you have SKFieldNode : radialGravityField()
For iOS 8.0- : one solution could be : 3 to 9
add your sprite ( planet ) with its physics
add an invisible SKNode ( the gravity zone ) with its own physics, as a child of your sprite, but with a radius much more than your sprite's one
you have a little explanation about invisible node here : https://developer.apple.com/documentation/spritekit/skphysicsworld
both, your sprite and the invisible node are centered in a zero gravity world
we look for contact and not collision ( set correctly your bit masks )
when any object get in contact with the invisible node ( gravity zone ), first you remove any moving action or impulse from it and then we add to this object an SKAction to move it toward the center of your sprite ( planet )
at second contact between this object and your sprite ( planet ), you remove all actions again from the object with a velocity = zero