Can someone explain differences between following kinds of ray tracing:
- backward RT
- forward RT
- recursive RT
I'm wondering which one is the best for which situation.
I'm intrested in the adventages and disatventages of this, not definitions.
Forwards RT (light ray tracing) traces the light from the source to the eye. This kind of RT is quite hard (in terms of computation time) to solve, because you don't know in which direction a photon has to leave the source in order to hit the eye. However, this is necessary if you want to calculate advanced phenomena like caustics.
Backward RT does this in the opposite direction. It traces the ray backwards, from the eye through the projection plane into the scene. This allows a straight-forward implementation, but not all effects can be simulated.
Path tracing and bidirectional path tracing as a variation that tries to combine the advantages of both approaches (performance and variety of effects).
Recursive RT is an addition to backward RT in that you create secondary rays once you hit an object. This is necessary to simulate reflection and refraction.
Related
I got two point clouds. To match them I try to do a registration with ICP. The point cloud's are not super similar but I want to at least get them very near together.
When using IterativeClosestPoint from the pcl library this works when I use my pointCloud A as a source and pointCloud B as a target. But it doesn't work when I use B as source and A as target. In the latter case it even increases the distance between my both clouds.
Does anyone know what I am doing wrong? Why should there be a difference in performance when changing the source/target?
This is my code:
pcl::IterativeClosestPoint<pcl::PointXYZ, pcl::PointXYZ> icp;
icp.setInputSource(A);
icp.setInputTarget(B);
icp.setMaximumIterations(50);
icp.setTransformationEpsilon(1e-8);
icp.setEuclideanFitnessEpsilon(1);
icp.setMaxCorrespondenceDistance(0.5); // 50cm
icp.setRANSACOutlierRejectionThreshold(0.03);
icp.align(aligned_model_cloud);
I am happy for any ideas and input.
Edit: here are the two clouds
Cloud A
Cloud B
Update:
I tried my code using Cloud A as source and Cloud A* as target. Where Cloud A* is a copy of Cloud A with just a translation on the x-axis. I did the same experiment with Cloud B and both were able to successfully converge in icp.
But as soon as I use Cloud B as source and Cloud A as target, it doesn't work anymore and converges after moving the cloud only a tiny bit (even the wrong direction). I checked the convergecriteria and found that it is CONVERGENCE_CRITERIA_REL_MSE (when transfromationEpslion is almost zero). I tried reducing the relative MSE with
icp.getConvergeCriteria()->setRelativeMSE(1e-15) but this didn't succeed. When checking the value of the relativeMSE after converging I get something like this: -124034642 which doesn't make any sense at all for me.
Update2: I moved the clouds quite near together first without ICP. When doing this ICP works fine.
Update3: I am doing an FPFH for a first estimation and afterwards ICP. Doing it like this works too.
This question is old and OP has already found a solution, but I'll just explain in case OP and someone find it useful.
First, ICP works by iteratively estimating correspondences between the two clouds and then minimize the overall distances between them. And ICP estimates correspondences using closest point data association (hence the name Iterative Closest Point).
And as you may know, closest neigbor graph is directed. That is to say, if point A has B as its closest neighbor, point B might not have A as its closest neighbor since C is closer to B than A!
Now that ICP uses closest point data association to estimate correspondences between the two clouds, specifying A as source will get a different correspondence set from specifying B. That explains the differences you observed.
Usually the difference is small and you may not notice after ICP. But in your case, I found the two clouds you provided are too different (one is extra large and the other small) and the relation becomes too asymmetric.
If you want to ensure the result is symmetric, you can just change the data association step (PCL might provide the option to do that) to make closest point correspondences come from both cloud (and this is just a variant of the classic ICP. For more information you can see my other answer).
// Compute the normals
pcl::NormalEstimation<pcl::PointXYZ, pcl::Normal> normalEstimation;
pcl::search::KdTree<pcl::PointXYZ>::Ptr tree(new pcl::search::KdTree<pcl::PointXYZ>);
normalEstimation.setInputCloud(source_cloud);
normalEstimation.setSearchMethod(tree);
Hello everyone,
I am beginner for learning PCL
I don't understand at "normalEstimation.setSearchMethod(tree);"
what does this part mean?
Does it mean there are some methods that we have to choose?
Sometimes I see the code is like this
// Normal estimation
pcl::NormalEstimation<pcl::PointXYZ, pcl::Normal> n;
pcl::search::KdTree<pcl::PointXYZ>::Ptr tree(new pcl::search::KdTree<pcl::PointXYZ>);
tree->setInputCloud(cloud_smoothed)*/; [this part I dont understand too]
n.setInputCloud(cloud_smoothed);
n.setSearchMethod(tree);
Thankyou guys
cheers
you can find some information on how normals are computed here: http://pointclouds.org/documentation/tutorials/normal_estimation.php.
Basically, to compute a normal at a specific point, you need to "analyze" its neighbourhood, so the points that are around it. Usually, you take either the N closest points or all the points that are within a certain radius around the target point.
Finding these neighbour points is not trivial if the pointcloud is completely unstructured. KD-trees are here to speedup this search. In fact, they are an optimized data structure which allows very fast nearest-neighbour search for example. You can find more information on KD-trees here http://pointclouds.org/documentation/tutorials/kdtree_search.php.
So, the line normalEstimation.setSearchMethod(tree); just sets an empty KD-tree that will be used by the normal estimation algorithm.
First of all a disclaimer: I'm posting this question here even if I realize it is quite maths heavy, because I have trouble figuring out on what other site it could belong.
I'm writing a 2d spaceships game where the player will have to select the ship's destination and a course will be automatically plotted.
Along with this, I'm offering various options to control the ship's acceleration while it gets there. All these options have to do with the target velocity at the destination.
One option is to select the desired destination and velocity vector, in which case the program will use cubic interpolation, since starting and target coordinates and velocity are available.
Another option is to just select the destination point, but let the game calculate the final velocity vector. This is done through quadratic interpolation (ie. acceleration is constant).
I would like to introduce another option: let the player select the destination and the maximum absolute value of the velocity vector, as in
sqrt( vf_x^2 + vf_y^2 ) <= Vf_max
I take I shall use a 3rd order polynomial to model the course in this case, but I'm having a pretty hard time figuring out the coefficients, since I miss one equation for each coordinate (the one given by velocity at destination). Furthermore, I'm confused as to how I should use the Vf_max constraint to help me figure out the missing coefficients.
I suspect it could be an optimization problem, but I'm quite ignorant about this topic.
Can anybody help me find a solution or point me in the right direction, please?
I've finished implementing Brélaz algorithm to try coloring a graph with the least colors possible. The fact is, until now, all the tests I've ran for it color it successfully with the minimum number of colors needed. But I've read several times that Brélaz, yet being a good algorithm does not necessarily achieve minimum coloring for a graph.
Could someone confirm this, and give me an example of a graph that would prove it?
Brélaz is a heuristic for vertex coloring from the 70s, also known as DSATUR (degree of saturation). It is known to be specially good with Erdös-Rényi graphs (uniform random) and achieves a good compromise between effort and tightness.
However it is only just that, a heuristic, and cannot certify an optimum.
Brélaz can be also used inside a full enumeration scheme, as described in [Randall-Brown 72], but I guess this is not what you have implemented.
There have also been some improvements over DSATUR, mainly concerning tiebreaks
Sewell 1996
San Segundo 2012 (algorithm PASS)
The typical FFT for audio looks pretty similar to this, with most of the action happening on the far left side
http://www.flight404.com/blog/images/fft.jpg
He multiplied it by a partial sine wave to get it to the bottom, but the article isn't too specific on this part of it. It also seems like a "good enough" modification of the dataset, rather than one based on some property. I understand that human hearing is better suited to the higher frequencies, thus, most music will have amplified bass and attenuated treble so that both sound to us as being of relatively equal strength.
My question is what modification needs to be done to the FFT to compensate for this standard falloff?
for(i = 0; i < fft.length; i++){
fft[i] = fft[i] * Math.log(i + 1); // does, eh, ok but the high
// end is still not really "loud"
// enough
}
EDIT ::
http://en.wikipedia.org/wiki/Equal-loudness_contour
I came across this article, I think it might be the direction to head in, but there still might be some property of an FFT that needs to be counteracte.
First, are you sure you want to do this? It makes sense to compensate for some things, like the microphone response not being flat, but not human perception. People are used to hearing sounds with the spectral content that the sounds have in the real world, not along perceptual equal loudness curves. If you play a sound that you've modified in the way you suggest it would sound strange. Maybe some people like the music to have enhanced low frequencies, but this is a matter of taste, not psychophysics.
Or maybe you are compensating for some other reason, for example, taking into account the poorer sensitivity to lower frequencies might enhance a compression algorithm. Is this the idea?
If you do want to normalize by the equal loudness curves, one should note that most of the curves and equations are in terms of sound pressure level (SPL). SPL is the log of the square of the waveform amplitude, so when you work with the FFTs, it's probably easiest to work with their square (the power specta). (Or, of course, you could compensate in other ways by, say, multiplying by sqrt(log(i+1)) in your equation above -- assuming that the log was an approximation of the inverse equal-loudness curve.)
I think the equal loudness contour is exactly the right direction.
However, its shape depends on the absolute pressure level.
In other words the sensitivity curve of our hearing changes with sound pressure.
There is no "correct normalization" if you have no information about absolute levels.
If this is a problem depends on what you want to do with the data.
The loudness contour is standardized in ISO 226 but this document is not freely available for download. It should be in a decent university library though.
Here is another source for
loudness contours
So you are trying to raise the level of the high end frequencies? Sounds like a high pass filter with a minimum multiplier might work, so that you don't attenuate the low frequency signals too much. Pick up a good book on filter design, maybe monkey around with this applet
In the old days of first samplers, this is before MOTU Boost people :) it wasn't FFT but simple (Fairlight or Roland it first I think) Normalisation done on the original or resulting time-domain signal (if you are doing beat slicing, recycle-style); can't you do that? Or only go for the FFT after you compensate to counteract for it?
Seems like a two phase procedure otherwise, I'd personally leave FFT as is for the task..