It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 11 years ago.
I'm trying to implement a basic ray tracer, which involve transform each ray into each object space and test intersection with the affinely deformed object by multiply the inverse of the affine transformation matrix with the ray. The intersection test is correct when the object is rotated, scaled, but not translated. When the object is translated (and the object should be still viewable), the intersection test fail, and no object is displayed.
When applying transformations the order of the operation is important. Applying them in the different orders gives you a different result.
For example, let's say you have a box with the centre at (0,0,0). You now rotate, then translate the box. The rotation will happen with respect to the origin of the coordinate system.
If you instead start by translating the box, say to (1,0,0), then do the rotation. The box will still rotate with respect to the centre of the coordinate system. However, the box is now longer at the centre of the coordinate system so it swings around in an arc.
This is a useful write-up about order of transformations
If you already knew about all this then sorry.
The only other thing I can do is point you in the direction of my ray tracing project on github pvtrace. It's all written in Python and you should be able to use it to debug your intersection code. If has different primitive shapes with which you can apply transformations too. The transformations are all applied by using the append_transformation() method of the primitives. All transformations are 4x4 homogeneous matrices which are passed to this method. The homogeneous matrices themselves are constructed using transformations.py which is bundled with the source code.
I hope that helps.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
I have a project that my team should implement an algorithm about detecting a sphere from point clouds, but I really don't know how to start it and where I can learn the knowledge. Would you recommend me some relevant articles or papers? Thank you very muych!
Regularly Spread?
You could try PCA and look at the eigenvalues of the covariance matrix. If they are roughly the same then this means the data is spread roughly the same in each direction. This means it's probably a sphere but could be a cube...
Sphere vs Cube
How to tell if it's a sphere or a cube? This is pretty tough. The only thing I can think of would be to take the distance of the farthest point from the center in several different directions and see if they are all roughly the same (low variance) then it's likely a sphere. If the distances vary a lot, maybe you're getting the corners or sides that are closer to the center, then it's probably a cube (or maybe some other polygon).
Spheres in CV
Something sort of related to this is the (Circle) Hough Transform which is used in Computer Vision to detect circles. Basically works doing a sort of polar transform with edges and can also find lines.
How to find what to test
How to find what points to look at? You can try some kind of clustering like k-means. If you don't know how many clusters, DBSCAN is interesting and might be worth checking out. Basic idea is to take the points and expand ε-balls around them to see what other balls they connect to. Eventually most things are connected and you have the clusters and outliers.
I am currently reading over Yasutaka Furukawa et al.'s Paper "Accurate, Dense, and Robust Multi-View Stereopsis" (PDF available here), where they describe an MVS-algorithm for reconstructing a 3D point-cloud from images.
I do understand the concepts and the main steps, but there is one detail that I am struggling with. This may be because I am not an English native speaker, so maybe a small hint would be enough.
On page 4 of the linked source, in chapter 3.2 "Expansion", there is the definition of "n-adjacent" patches:
|(c(p)−c(p'))·n(p)|+|(c(p)−c(p'))·n(p')| < 2ρ_2
My question is about ρ_2, that is described as in the following:
[...] ρ_2 is determined automatically as the distance at the depth of the
midpoint of c(p) and c(p') corresponding to an image displacement of β1 pixels
in R(p).
I do not understand what "distance" in this context should be, and I do not understand the stated correspondence to the image displacement.
I know that this is a very specific question, but since this paper is somewhat popular I hoped, that there is somebody, that can help me.
Alright, I think I do get it now.
It just means, that ρ_2 is the distance you have to move in a plane, located as far away from the camera (depth) as the midpoint of c(p) and c(p'), so that you get a displacement of β1 pixels in the image showing the scene.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
As I noticed, many 3D games (almost all, I think) use simple algorithm for computing perspective. It works almost ideal, but all objects significantly deform at the edges of the FOV. The sipliest example of this effect is the fact that all spheres at the edges of FOV look not like circles.
The OpenGl function gluPerspective() creates perspective with same defect.
I have a rough idea of better algorithm that, as I think, will fix this problem.
So, question is:
Is there any algorithms that don't have this defect and where I can read about them?
Is there any algorithms that don't have this defect and where I can read about them?
There are several: Spherical projections, Stereographic projections. Cylindrical projections. Tiled panoramic projections, and so on, you name it.
Rastering systems that are based on triangles however have a very important requirement on the projection to work properly: Straight lines must be projection into to straight lines (affine projection). This is the cause for the unpleasant distortions you see. Any of the projections I mentioned above (and many more) can be approximated with OpenGL using an appropriate vertex shader. However to look good the geometry must be sufficiently fine tesselated, because straight edges need to be broken down into sufficiently many segments to allow mapping to curves. A tesselation shader can be used for this. Another approach is rendering a wide field view into a cube map (cube maps require an affine projection for their creation). Then you can apply and other mapping on the cubemap, which leads to more robust results.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 9 years ago.
when we take a video from moving vehicle backward, we will see vehicles behind you moving slowly, while the background(trees, houses, road markers) moving quite fast. Given two successive images from the video, the car behind you will not change much, but the background change a lot. I would like to consult how to automatically identify this car from the two images. They share similar position, size and all other features.
The equivalent question is how to identify the background which changes a lot.
I do know there are a bunch of algorithms to identify vehicles and have tried some of them. But is it possible to use similarity of the same vehicle in successive images to identify the vehicle?
I am using a monocular camera and updating frequency is 2Hz.
Six successive images are uploaded as a reference.
In terms of similarity, the classical way is to use histogram. Divide your graphs into small grid and computer RGB histogram for each grid. Good luck.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
What I'm specifically grappling with is not just the layout of a graph, but when a user selects a graph node and starts to drag it around the screen area, the line has to constantly be redrawn to reflect what it would look like if the user were to release the node. I suppose this is part of the layout algorithm?
Also some applications get a bit fancy and don't simply draw the line in a nice curvy way, but also bend the line around the square shaped node in almost right angles. See attached image and keep in mind that as a node is dragged, the line is drawn as marching ants, and re-arranged nicely, while retaining its curved style.
alt text http://img260.imageshack.us/img260/5458/nodesr.png
If your diagrams are not crazy full you should not need an extra-fancy algorithm for this, but just use some common sense.
Cover the surface with a rectangular grid and then find a way to connect to boxes with straight lines along grid lines with a minimum number of angles: if the boxes are not on the same grid lines and you don't care where you connect you need one angle if there is no other node in between. If there are e.g. nodes in the way you need at least one more angle.
As a second step for fuller diagrams add code that not only optimizes for minimal number of edges but also for minimal length of the lines. If your diagrams are not crazy full this should be hardly noticeable in terms of application response.
For extra eye candy round the angles taking into account the lengths of both legs and checking for intersections with other objects on the surface. I would use 90°-pies of circles and adjust the radius of the circles (apparently not what was done above) -- for longer legs the radius should be bigger. Maybe the toolkit you are using can help you here.
Are you familiar with Graphviz? I'm not sure how "dynamic" and resuable the layout algorithms are, but it could be a good starting point.
Why don't you look in Dia source code to see how they are doing it?
http://live.gnome.org/Dia/Download
to extend #honk answer: for smoother curves you can just take 3 or 4 pivot points and connect them using quadratic/cubic bezier lines.
this is an example in javascript from raphael plotting library
There's not really a need for anything dramatic beyond directly drawing onto Cartesian coordinates. Simple heuristics can be used to handle the pathing and likely to hit the optimal minimum number of angles the majority of the time, but and likely the shortest length path even more often. All of this can be done dynamically as you require, but while maintaining precision of graphics without breaking the screen up more discretely that it needs to (pixels should remain the most discrete level) and without the need for complex algorithms.
For the overlay, just set all pixels to the color of your lines and modify the alpha channel bits to transparent or opaque depending on if the pixel is or isn't part of the line. To figure out which bits that are part of the line requires a bit of geometry, but that's a piece of cake once you have everything in place.
To figure out how to draw your line onto the alpha channel, you'll need to figure out the style of your lines. A lot of what you'll do depends on style. A common style is using straight lines that are horizontally and veritcally aligned with quarter circles for right angles.
For the "avoidance" algorithms, these aren't too difficult to implement when you just want to avoid the "boxes" representing your nodes... to decluster all your lines is a bit larger of a task and something that not even Visio employs. To avoid the boxes/nodes, using the midpoint between the edges of the box (such as the vertical edges between geo1 and geo3) is nice to do for symmetry and then picking a simple predefined distance to keep non-connecting lines (that is lines that do not connect to that particular box) away from the boxes also works well. A generalized algorithm for this is simple to do, but a little too verbose to describe here, but is essentially a set of generalized checks and switches working on horizontally and vertically align lines and quarter turns. If you end up wanting more detail on how to do this, just post a comment on this answer.
If you're looking for something that's already made for you, the type of connections and rearranging that you want really depends on the application and not a lot of people make tools that are low in demand or too specific of a demand. Obviously this type of software is out there since Visio and others employ it, but whether or not it's available as open source or part of some other free libraries I'm not certain.