PCL's github directs these questions here so I don't really know where else to ask this.
I'm trying to implement pose estimation given a mesh and a generated point cloud. Using PCL, I know you can do pose estimation with two point clouds from the tutorial. In my case I have an accurate faceted model of my target object. Does there exist a PCL pose estimator that can consume faceted truth models? I would like to avoid using mesh_sampling or mesh2pcd as a work around.
Googling does not bring any results relevant to my search with the following 54 terms
point cloud library pose estimation with
mesh
triangles
facets
truth data
model truth data
model
mesh truth data
vertexes
vertices
point cloud library point set registration with
(above)
point cloud library registration with
(above)
point cloud library 6DOF with
(above)
point cloud library pose with
(above)
point cloud library orientation with
(above)
Maybe I don't know the right words to search?
but it appears like it might be possible, because functors like this
pcl::SampleConsensusPrerejective<PointNT,PointNT,FeatureT>
and this
pcl::Registration< PointSource, PointTarget, Scalar >
take what seem to be pretty generic template arguments, only requiring PCL base functionality. But placing pcl::mesh did not compile (though it doesn't appear to be the only "mesh" type in PCL), since mesh doesn't seem to inherit off of base. The documentation does not talk about what is or is not possible with template types. Additionally I have found zero documentation that states this is impossible or indicates that only point clouds are allowed.
Can I use the model directly with out point cloud conversion, and if not why?
PCL is a library for point cloud processing. While some mesh support is available (pcl::PolygonMesh), practically all the implemented algorithms are based on point cloud data.
However keep in mind that a mesh is just a point cloud + additional triangulation information (faces) - so this means that any point cloud algorithm can be applied on a mesh. You just need to generate a point cloud from your mesh's vertices, and ignore the faces - no need for mesh sampling.
Related
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.
I want to use PCL(point cloud library) to implement cube or rectangle detection for any size in a scene.
Can anyone give me some direction?
You may want to take a look at this PCL tutorial or, in general, at all the techniques implemented in the pcl::recognition module.
On the PCL users mailing list archive (here), there is an older but yet useful discussion about simple object recognition. For simple objects, as in your case, you may consider using Sample Consensus for segmenting the model inside your scene point cloud.
I need to find connected components for a huge dataset. (Graph being Undirected)
One obvious choice is MapReduce. But i'm a newbie to MapReduce and am quiet short of time to pick it up and to code it myself.
I was just wondering if there is any existing API for the same since it is a very common problem in Social Network Analysis?
Or atleast if anyone is aware of any reliable(tried and tested) source using which atleast i can get started with the implementation myself?
Thanks
I blogged about it for myself:
http://codingwiththomas.blogspot.de/2011/04/graph-exploration-with-hadoop-mapreduce.html
But MapReduce isn't a good fit for these Graph analysis things. Better use BSP (bulk synchronous parallel) for that, Apache Hama provides a good graph API on top of Hadoop HDFS.
I've written a connected components algorithm with MapReduce here: (Mindist search)
https://github.com/thomasjungblut/tjungblut-graph/tree/master/src/de/jungblut/graph/mapreduce
Also a BSP version for Apache Hama can be found here:
https://github.com/thomasjungblut/tjungblut-graph/blob/master/src/de/jungblut/graph/bsp/MindistSearch.java
The implementation isn't as difficult as in MapReduce and it is at least 10 times faster.
If you're interested, checkout the latest version in TRUNK and visit our mailing list.
http://hama.apache.org/
http://apache.org/hama/mail-lists.html
I don't really know if an API is available which has methods to find strongly connected components. But, I implemented the BFS algorithm to find distance from source node to all other nodes in the graph (the graph was a directed graph as big as 65 million nodes).
The idea was to explore the neighbors (distance of 1) for each node in one iteration and feeding the output of reduce back to map, until the distances converge. The map emits the shortest distances possible from each node, and reduce updated the node with the shortest distance from the list.
I would suggest to check this out. Also, this could help. These two links would give you the basic idea about graph algorithms in map reduce paradigm (if you are already not familiar). Essentially, you need to twist the algorithm to use DFS instead of BFS.
You may want to look at the Pegasus project from Carnegie Mellon University. They provide an efficient - and elegant - implementation using MapReduce. They also provide binaries, samples and a very detailed documentation.
The implementation itself is based on the Generalized Iterative Matrix-Vector multiplication (GIM-V) proposed by U Kang in 2009.
PEGASUS: A Peta-Scale Graph Mining System - Implementation and
Observations U Kang, Charalampos E. Tsourakakis, Christos Faloutsos In
IEEE International Conference on Data Mining (ICDM 2009)
EDIT:
The official implementation is actually limited to 2.1 billions nodes (node id are stored as integers). I'm creating a fork on github (https://github.com/placeiq/pegasus) to share my patch and other enhancements (eg. Snappy compression).
It is a little old question but here is something you want to checkout. We implemented connected component using map-reduce on Spark platform.
https://github.com/kwartile/connected-component
Does anyone have any good implementation strategies or resources for putting together a b-rep modeling system?
OpenCascade is an apparently good library for b-rep modeling (used by FreeCad and PythonOCC are both very cool) but the library is huge, complicated and may not be a good starting point to learn about b-rep modeling 'engines'.
I've done quite a bit of research paper reading, and while the fundamental math is useful for understanding why everything works, its left me with some implementation questions.
The halfedge data-structure seems to be the preferred way to store information about a body in b-rep implementations.
So a handful of questions in no particular order:
Using the halfedge data-structure how is rendering typically implemented? Triangulation based on the solid's boundaries?
How are circular faces/curved surfaces typically implemented? For instance a cylinder in one basic introduction to b-rep's I read, was internally stored as a prism. IE an extruded triangle and meta-data was stored about the cap faces denoting that they were indeed circular.
How are boolean operations typically implemented? I've read about generating BSP-Tree's along the intersection curves then combining those tree's to generate the new geometry. Are there other ways to implement boolean operations and what sort of pro's/con's do they have?
Thanks!
If you'd like to provide a code example don't worry about the language -- the questions are more about algorithmic/data-structure implementation details
I'm working on a B-Rep modeler in C# (I'm in a very early stage: it's an huge project) so I ask myself the same questions as you. Here is my answers:
Triangulation: I've not done this step, but the strategy I'm thinking about is as follow: project the face boundaries in parameter space to obtain 2D polygons (with holes), triangulate that with the ear clipping algorithm and then reproject triangle vertices in 3D space. For curved surfaces, I need to split the polygons with a grid in order to follow the surface;
For a cylinder, there is 3 edges : two circulars and one line segment. I have classes for each type of curves (Segment3d, Circle3d...) and each half-edge hold an instance of one of theses classes. Each face hold an instance of a surface object (plane, cylinder, sphere...);
There is an interesting project here based on BSP-Tree, but it uses CSG method, not B-rep. I'm still researching how to do this, but I don't think I will need a BSP tree. The difficulty is in computing intersections and topology.
The best books I've found on this subject:
3D CAD - Principles and Applications (old but still relevant)
Geometric Modeling: The mathematics of shapes (more recent than the previous one, but less clear)
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...