I have integrated box2d in my engine, ( Debug Draw, etc. ) and with a world I can throw in some 2d squares/rectangles etc.
I saw this post, where the user is basically not using a world for collision detection, however the user doesn't explain anything about how he's using the manifold (b2Manifold), etc.
Another post, is in the cocos2d forum, ( scroll down to the user Lam in the third reply )
Could anyone help me a bit with this?, basically want to add collision detection without the need of using b2World ,etc etc.
Thanks a lot!
Is there any reason you can't use a b2World? Just because you use it, doesn't mean you have to use the physics simulations, unless you're severely performance limited.
See this example on using Box2D for collision only in Cocos2d. Maybe you can apply something similar to your project: http://www.raywenderlich.com/606/how-to-use-box2d-for-just-collision-detection-with-cocos2d-iphone
The code in both of those posts seems complete to me. You begin with two polygon shapes and their corresponding transforms and from b2CollidePolygons you get back a contact manifold.
The b2Manifold is just a collection of points at which the two shapes' boundaries intersect. In the posted code the author uses that if the manifold's point count is greater than zero there is an overlap. Depending on the nature of the shapes there can be different number of intersection points when they overlap.
Note that the collision handling of the b2World is quite robust. Beyond simple collision queries it has broad-phase culling, ray-casting, a spatial tree, begin-contact and end-contact events, efficient memory management to name some things. There are classes in the API for most of these tasks but I can't say I'm familiar with using them manually. Could be worth a look.
Related
I am going to split this question in 3 parts
First, I've been given this problem, and I don't know where to start, if you have been solving related problem, would you give me some hints and keywords to help me do some more research?
I have done some research on my own
So here is some 2D chest CT scans (sorry due to reputation rule i can't implement images directly)
All photos are in the same angle. So I think I can simply read each photo to a vector of pixels, do some thresh holding to make all black and black-ish pixels going to be a non-colored pixel. Next, I'll create a vector called vector_of_photo of those vectors. Then the index of each vector in vector_of_photo are now the Z-index.
Now I can render a 3d photo from those vectors of pixels right?
In the second place, I got trouble understand raycasting algorithm,
I think the idea here is, when I already got a box of pixel then everytime I rotate the box, it cast straight-lines from that angle of the camera to the box, each line found a has-colored pixel going to stop casting and render that pixel (or more specific, copy the pixel to the exactly location on the plane).
Did I understand it correctly?
At last, the OPENGL/c++ part is just the option I think I'm going to use to solve this problem. And I'm not pretty sure it is a good idea or not, so give me some more hint about the programming language, library or module I should take a look at.
I happen to be working on the same problem in my spare time. Haha :)
Here is one approach to your problem:
Load the images into your application, such that you get the 3D volumetric dataset that you describe
Remove all points that don't fit within some range of values (e.g. 0.4/1.0 to 0.6/1.0 brightness). You may need to apply preprocessing and filtering.
Fit a mesh to the resulting point cloud with open-source software. Here is a good blog post about that
https://towardsdatascience.com/5-step-guide-to-generate-3d-meshes-from-point-clouds-with-python-36bad397d8ba
Take the resulting mesh (probably, an STL file) and visualize it in any software your want (Blender 3D, Unity 3D, Cinema 4D, a custom OpenGL application), anything really.
My own approach to this problem is very similar to the one you suggest in your question, and I have already made some headway. Therefore, I thought it would be good to suggest another route.
NOTE Please be aware that what you are working on is not a trivial problem. It's a large project, and there are many Commerical companies that put years into doing just this. This is a great project for learning OpenGL, rendering, and other concepts. It's perfectly doable, but you may be looking at several months of work, and lots of trial and error. Good luck!
Its not often that two people would happen to work on the same problem, so if you want to discuss further, feel free to contact me over linkedin and/or post a comment below. www.linkedin.com/in/michael-sohnen-a2454b1b2
Actually, I'm currently working on a simple project to detect collision between 2 specific objects in a surgery scene. The problem is that I don't have background on such problems so I'm really newbie to such things and I don't know yet what to do. After a little bit of research, I found Bullet library which can be used as a collision detection tool but not sure yet if it suits my case. I already checked some examples where the developer create the objects of interest manually which led me to think that I should detect first the objects of interest then launch the collision detection process.
In my case, I have 2 types of data:
Video shooting the operating room
Cloud points representing the room in 3D
I need to detect the collision between two objects in the scene. Is there any way to use Bullet to achieve such thing? Is it common to use a video as input for a detection collision problem(I'm wondering since I could find too much resources on it)?
I'm just starting so it might be a fuzzy question so sorry in advance for any inconveniences.
EDITED:
I already checked it but my point was to understand what options can be used before digging into the details. For me, a collision detection problem should have 2 parts: the objects of interest (The 2 or more objects that we're trying to detect their collision) and the scene in which we will be trying to detect the collision of the objects of interest. For the scene, the data I have is presented in 2 types mentioned above. So, I was asking about which type of data should be used as input for bullet collision process. Should it be an image taken from the video or should it be a list of 3D points? Or something else?
I have used Bullet half a year ago. I remember, that you need to register objects to Bullet with a collision shape. In simplistic case of your points, it could probably be small spheres. In case of your video, you need to have a 3d representation. I do not understand a 100% what you mean by detecting a "video" for collisions. However, to use Bullet, you need to have a collision shape associated with the object.
Further, you register a Collision Callback. This is one function called for each collision detected. All callbacks are listed here: http://www.bulletphysics.org/mediawiki-1.5.8/index.php?title=Collision_Callbacks_and_Triggers
As the wiki says - and I implemented it this way - to detect a specific collision, you need to iterate over allr esulting manifolds from Bullet manually. A little bit painful and performance wise strange approach. So you cannot register a specific callback for a specific object with another specific object!
Once the objects are registered, you run the algorithm and then you can check all manifolds in the callback.
To get started with Bullet, I used Bullet Physics Simplest Collision Example with the answers at that time.
Say there are 3 boxes on the screen, how can I go about touching one of them to pick it up and "throw" it at the others? I have the rest of the world implemented but can't find much information on how to grab/drag/toss physics objects. Any sample code or documentation out there that would help with this?
It depends what you are attempting to do. It is a physics simulation and as such a typical way of interacting with the system is by applying forces to objects opposed to direct manipulation of the x,y coordinates. But you can in fact do either. I believe the most common approach is to use a mouse joint. A google search on b2MouseJoint will show the documentation and several examples including this one.
http://muhammedalee.wordpress.com/tag/b2mousejoint/
I'm interested in trying to create realistic fluids (water), for a 2D game. This game is similar to Terraria. I have heard about how you can slap a bunch of colliding particles on the scene and render over it and voila, realistic acting water.
Terraria uses tile based water, which I am not a fan of.. I want something more advanced.
I thought about using bullet 3D physics (box2d has limits I would hit). For non colliding particle effects, I am thinking about using something like SPARK, since I think that'd give me the best of both worlds.
The issue I am thinking about, is that each block is 16x16, so on a 1600x900 scene, there are about 5 thousand tiles.
So I need to tell the physics engine that these tiles are collidable. Of course, there are void tiles that are considered to be non collidable.
Does anyone have ideas on this? Language is C++, I doubt that's relevant though.
EDIT: i think i'm going to have to cave in and use grid based water. I suppose, in retrospect particle based just makes everything more difficult but for what gain?
Your question is about tiled fluids, but you seem to actually be asking about a particle based approach.
If that's the case, what you're looking for is "Smoothed Particle Hydrodynamics", or SPH, which is a very popular technique for 2D and 3D fluid simulations in realtime situations.
Yes, it's basically just a particle system, with each particle responding to the forces in your environment (gravity, collisions etc.) in a reasonable (mathematically stable) way, combined with a constraint that they must stay a certain distance apart in order that the fluid is incompressible.
You can render the particles as points, if you have enough of them, or you can use them as a source for deriving a surface (for example using marching-cubes, though in 2D I wouldn't worry about that).
http://en.wikipedia.org/wiki/Smoothed-particle_hydrodynamics
It has the advantage of being relatively easy to code, and indeed to accelerate on a GPU.
Indeed I think they're probably a better approach than trying some kind of tile-based approach, and you get some more interesting results, such as spray kicking up, waves kicking against the edges of objects, etc. It's not too hard to get something pleasing working, I'd give it a go.
I am working on a simple 2D openGL project. It contains a main actor you can control with the keyboard arrows. I got that to work okay. What I am wanting is something that can help explain how to make another actor object follow the main actor. Maybe a tutorial on openGL. The three main things I need to learn are the actor following, collision detection, and some kind of way to create gravity. Any good books or tutorials to help get me in the right direction would be great.
You could use a physics library like Chipmunk Physics, which lets you attach springs and things between the two objects and detect when they hit each other and other things.
A pre-rolled library would be good, but the concepts you describe are ones you need to know if you are going to do any sort of game programming anyways:
A simple way to make one actor follow behind another is to have the lead actor store its position every time it moves. Feed these positions to a trailing actor with a delay of a few values - the longer the delay, the further behind they travel. Simple, but doesn't handle dynamic collision (other actors moving the block collision.)
Collision detection in 2D can simply be axis aligned (AA) bounding boxes. Search for this and you'll see the 4 ifs or so that are needed.
Gravity is just adding a fixed velocity (usually down) to every object every game loop. This is constant acceleration which is exactly how gravity works.