I have a simulation I am running where I would like to test for the collision of 2D objects. I am not interested in the physics simulation portion of Box2D but would like to leverage its collision detection features.
My initial thought was to make a bunch of static bodies but after reading the documentation I got the impression they were not included in collision testing and therefore don't make sense.
Is it worthwhile using Box2D to evaluate collision detection in my system, where the position of the elements is driven by a separate system, or does it make more sense to look elsewhere for a collision detection solution? If so, how would I start down that path with Box2D?
Although I have not tried it myself, I guess you could do it by using dynamic bodies, with the world gravity set to zero, and all bodies linear velocity set to zero (so they do not move in world Step call) and then position them using SetTransform. The regular BeginContact/EndContact events should still be sent to your contact listener.
Yes, use Box2D. Box2D has the best collision detection system I've used, compared to Chipmunk and Bullet.
I agree with iforce2d, you should use dynamic bodies with a world whose gravity is set to zero.
Good luck and happy coding.
Related
I've been looking for a robust method of pathfinding for a platformer based game I'm developing and A* looks like it's the best method available. I noticed there is a demo for the AStar implementation in Godot. However, it is written for a grid/tile based game and I'm having trouble adapting that to a platformer where the Y axis is limited by gravity.
I found a really good answer that describes how A* can be applied to platformers in Unity. My question is... Is it possible to use AStar in Godot to achieve the same thing described in the above answer? Is it possible this could be done better without using the built in AStar framework? What is a really simple example of how it would work (with or without AStar) in GDscript?
Though I have already posted a 100 point bounty (and it has expired), I would still be willing to post another 100 point bounty and award it, pending an answer to this question.
you could repurpose the Navigation2D node for platformer purposes. The picture below shows an example usage. The Navigation2D node makes it possible to navigate the shortest path between two point that lie within the combined navigation polygon (this is the union of all NavigationPolygonInstances).
You can use the get_simple_path method to get a vector2 array that describes the points your agent/character should try to reach (or get close to, by using some predefined margin) in sequence. Place each point in a queue, and move the character towards the different points by moving it horizontally. Whenever your agent's next point in the queue is too high up to reach, then you can make the agent jump.
I hope this makes sense!
The grey/dark-blue rectangles are platforms with collision whereas the green shapes are NavigationPolygonInstance nodes
This approach is by no means perfect. If you were to implement slopes into your game then the agent may jump up the slope instead of ascending it normally. It is also pretty tedious to create all the shapes needed.
A more robust solution would be to have a custom graph system that you could place in the scene and position its vertices. This opens up the possibility to make one-way paths and have certain edges/connections between vertices marked as "jumpable" only. This is a lot more work though if you can not find any such solution online.
I just want to get the main idea/principle of openFOAM and how you create a simulation, please let me know where I go wrong,
So basically you have a object that interacts with gas or liquid and you want to simulate this, so you create model of the object, mesh it, specify where the gas will flow in and out and what are the walls, and set the other correct parameters and then run the program (with the approprate time step etc)?
OpenFOAM is an open source C++ library which implements the finite volume method (FVM), which is widely used in CFD.
What you have explained is a vague understanding of some of the applications of CFD. Those things you specified might not always be the case (i.e. the fluid might not necessarily be (a) gas and so on.
The main stages of a CFD problem are: making the geometry - mesh generation - preprocess - solving - postprocess.
There might be more stages added depending on the resolution and other specifics of the case.
Now OpenFoam is an open source (free for all) tool which is in C++ and helps solve the CFD problems. If the problem is simple and routine, and you have access to a commercial solver such as ANSYS fluent, then you can use that since it is easier and much less work if the problem is not specific. However, if the problem is specific and there are customized criteria OpenFoam is a nice tool.
It is written in C++ thus it is object oriented and also there are many many different solvers already written and available to use, so you will not have to write all the schemes and everything on your own from scratch.
However, my main advice to you is to read more about CFD to have a clear understanding, there are tens of good books avaiable.
What are the parameters/factors that a QR detector need to detect/check before(during) decoding the QR code itself.
From what I know:
1. it need to find/locate three finder patterns
2. need to locate alignment patterns (if there is any)
3. need to check luminance
Is there anything else that need to be determined/checked?
I suppose that there are many ways to detect a QR code, and it's not required to do it one particular way or the other as long as the detection succeeds. There is a reference algorithms in the QR code specification, though in my opinion it is too slow to be practical, though it's quite thorough.
I can tell you how zxing does it. Yes, it first locates the three finder patterns. This is done by looking for 1:1:3:1:1 black/white/black/white/black crossings horizontally and vertically. It figures out which one is which by looking at the vectors between them.
Then it needs a fourth point since four points are needed to correct for perspective distortion. It uses the location of the 3 finder patterns to guess about where it is and scans for it similarly (looking for 1:1:1:1:1). You don't need to find all alignment patterns, though doing so would allow you to correct for warping in the QR code, which is very rare.
Then you can sample the image to get the black/white modules by computing the perspective transform and reversing it. Then the decoding proceeds, the processing of those black/white modules, which is a fair bit of work too but nothing to do with detection or image processing anymore.
Looking at luminance is really a step before all this, so you even have a notion of black and white in the image to begin with. That's different.
Matrix math library that is good to use alongside OpenGL to keep track of primitive co-ordinates.
Does such a thing exist? Is this the best way to track my objects for use in collision detection?
You don't describe your situation very much but I'm assuming that you are making some game or simulation application?
I would suggest you use a physics engine, like Bullet or ODE, from the start. This way you will get a properly optimized matrix library plus well tested collision detection and handling. Using some other general-purpose matrix math library may seem easier at first glance. However it will probably be less adapted to your needs and will surely be a mess to replace with a physics engine if you decide to use one later on.
You don't have to use all the fancy features of the physics engine right away. In fact you could very well just use the matrix and vector implementation and skip the rest until later.
OpenGL is simply for rendering the objects from your data store, your physics/collision library will already have matrices for all the objects within it.
I dont think there is such thing. Maybe this helps to clarify a few things:
http://nehe.gamedev.net/data/lessons/lesson.asp?lesson=30
Whats the best way to detect collisions in a 2d game sprites? I am currently working in allegro and G++
There are a plethora of ways to detect collision detection. The methods you use will be slightly altered if depending on if your using a 2d or 3d environment. Also remember when instituting a collision detection system, to take into account any physics you may want to implement in the game (needed for most descent 3d games) in order to enhance the reality of it.
The short version is to use bounding boxes. Or in other words, make each entity in the world a box, then check if each of the axises of the box are colliding with other entities.
With large amounts of entities to test for collisions you may want to check into an octree. You would simple divide the world into sectors, then only check for collision between objects in the same sectors.
For more resources, you can go to sourceforge and search for the Bullet dynamics engine which is an open source collision detection and physics engine, or you could check out http://www.gamedev.net which has plenty of resources on copious game development topics.
Any decent 2D graphics library will either provide its own collision detection functions for everything from aligned sprites to polygons to pixels, or have one or more good third party libraries to perform those functions. Your choice of engine/library/framework should dictate your collision detection choices, as they are likely far more optimized than what you could produce alone.
For Allegro there is Collegro. For SDL there is SDL_Collide.h or SDL-Collide. You can use I_COLLIDE with OpenGL. DarkBASIC has a built in collision system, and DarkPhysics for very accurate interactions including collisions.
Use a library, I recommend Box2D
This question is pretty general. There are many ways to go about collision detection in a 2d game. It would help to know what you are trying to do.
As a starting point though, there are pretty simple methods that allow for detection between circles, rectangles, etc. I'm not a huge fan of gamedev.net, but there are some good resources there about this type of detection. One such article is here. It covers some basic material that might help you get started.
Basic 2d games can use rectangles or circles to "enclose" an object on the screen. Detection of when rectangles overlap or when circles overlap is fairly straightfoward math. If you need something more complicated (such as convex artibrary polys), then the solution is more complicated. Again, gamedev.net might be of some help here.
But really to answer your question, we need to know what you are trying to do? What type of game? What type of objects are you trying to collide? Are you trying to collide with screen boundaries, etc.
Checking for collision between two balls in 2D is easy. You can google it but basically you check if the length of the two balls radius combined is larger or equal to the distance between the center of the two balls.
Then you can find the collision point by taking the unit vector between the center of the balls and multiply it with one of the balls radius.
Implementation of a collision detection system is a complicated matter, but you want to consider three points.
World of objects. Space Partitioning.
If you do a collision check against every 2d sprite in your world against everything else, you'll have a slow slow program! You need to prioritize. You need to partition the space. You can use an orthogonal grid system and slice your world up into a 2d grid. Or you could use a BSP tree, using lines as the seperator function.
Broad phase collision detection
This uses bounding volumes such as cylinders or elipses (whichever approximates the shape of your sprites the best) to determine whether or not objects are worth comparing in more detail. The math for this is easy. Learn your 2d matrix transformations. And for 2d intersection, you can even use high powered video cards to do a lot of the work!
Narrow phase collision detection
Now that you've determined that two or more objects are worth comparing, you step into your fine tuned section. The goal of this phase is to determine the collision result. Penetration depth, volume encompassed, etc... And this information will be fed into whatever physics engine you got planned. In 3d this is the realm of GJK distance algs and other neato algorithms that we all love so much!
You can implement all of this generically and specify the broad and narrow resolutions polymorphically, or provide a hook if you're working in a lower level language.
Collisions between what? It depends whether you use sprites, concave polygons, convex polygons, rectangles, squares, circles, points...