Normally Intersection of two planes A and B (not parallel) will return a line L. I know how to implement this, but if now given a plane A and the line of intersection L to find plane B. Is there a solution? Thanks in advance!
No, it is not possible to find (or "recover") the plane B, because an infinite number of planes (Bs) can intersect plane A exactly at the line L but still are allowed to "hinge" (or rotate) about it (within certain limits of course so as to not be parallel as you mention).
You need a little bit more information to define one single plane (three points, a point and a line, a point and a normal vector, for more information please see here). Also, Paul Bourke's website contains really a wealth of information if you are working in computer graphics.
Perhaps there is a way to get this little bit of information from your problem (?)
(By the way, i am not sure that this a question for Stackoverflow, perhaps it would fit better to the Mathematics part)
Related
Is there a simple/quick way to find out the dimensions of a 3D axis aligned bounding box for an item with rotations in the <x,y,z> axes? I know that in math there are different methods/equations to come up with the same answer for a problem and I've previously in the past explained with bare bones information about a method that worked for me, that I probably didn't explain well.
I also know that there are (downloadable)functions available for some languages like java and python to help solve/tackle parts of the math. Though that might not help those that want to understand those different methods better or might not have access to those particular functions for the language they are using.
So if a person has the following information:
The item center point coordinate in the x,y,z
The item x,y,z size
Along with the x,y,z rotation(s)
What would be the easiest approach with a person knowing that information, while either using or not using the item center point, matrix/matrices or cos and sin. Though an approach that would also be compact enough to take up the least amount of memory usage.
I have a pair of geo coordinates I don't understand. Does anybody know this coordinate system and how to translate them to longitude and latitude in degrees?
Long. 7662.251 West, Lat. 9144.590 North
Has to be a position in Honduras (13- 16°N and 83-89° W)
You really need to investigate the source of the data, files, print outs, local gandolphs etc. Even if someone can find something with a stab in the dark it's likely to be wrong in some tiny detail. Where did the pair of coordinates come from? A text file? An email? Were there any auxiliary files? With the same file name, but different extension? In the same folder? Attached to the email? Who gave it to you? What sort of computer do they use? Are they alive? Etc.
There's simply not enough information in this question to answer it - tell us at least how you know that they are "geo coordinates" - how do you know that they must be in the Honduras?
Unfortunately this level of cultural metadata is quite often about the best we have. As a massive stab in the dark they might be projected coordinates in km, rather than metres - but they could be in feet - or anything, there's really only educated guesses that can improve on this as it stands.
If it's not one of the common ones, such as UTM, have a search on the epsg registry for coordinate systems for Honduras:
http://www.epsg-registry.org/
and see if any work out. Would be a lot easier if you have any more coordinate pairs that are also in Honduras, because then we can work out an approximate scale.
I'll have a play and see if one of the UTM zones works out...
Not a long question. Can anyone explain what the word "translation" means in the context of graphics? Thanks a lot.
Translation is just moving something (up, down, or sideways).
Move an object - don't rotate or scale or distort it, just move it
Translation, as said, is moving an object. This is one of the affine transformations (which means it doesn't distort the object). There are a few others, the 2D versions of which are described here. (Note that shearing, the final one listed, isn't affine).
It literally means to translate coordinates from one graph system to another using a mathmatical function.
In normal 2d/3d geometry this is accomplished by adding or subtracting values to move the origin of one system to the orgin of the other.
Ie - move the object from one spot to another.
(Ps this is somewhat simplified.)
I have a tile based map where several tiles are walls and others are walkable. the walkable tiles make up a graph I would like to use in path planning. My question is are their any good algorithms for finding a path which visits every node in the graph, minimising repeat visits?
For example:
map example http://img220.imageshack.us/img220/3488/mapq.png
If the bottom yellow tile is the starting point, the best path to visit all tiles with least repeats is:
path example http://img222.imageshack.us/img222/7773/mapd.png
There are two repeat visits in this path. A worse path would be to take a left at the first junction, then backtrack over three already visited tiles.
I don't care about the end node but the start node is important.
Thanks.
Edit:
I added pictures to my question but cannot see them when viewing it. here they are:
http://img220.imageshack.us/img220/3488/mapq.png
http://img222.imageshack.us/img222/7773/mapd.png
Additionally, in the graphs I need this for there will never be a situation where min repeats = 0. That is, to step on every tile in the map the player must cross his own path at least once.
Your wording is bad -- it allows a reduction to an NP-complete problem. If you could minimize repeat visits, then could you push them to 0 and then you would have a Hamiltonian Cycle. Which is solvable, but hard.
This sounds like it could be mapped onto the traveling salesman problem ... and so likely ends up being NP complete and no efficient deterministic algorithm is known.
Finding a path is fairly straight forward -- find a (or the minimum) spanning subtree and then do a depth/breadth-first traversal. Finding the optimal route is the really difficult bit.
You could use one of the dynamic optimization techniques to try and converge on a fairly good solution.
Unless there is some attribute of the minimum spanning subtree that could be used to generate the best path ... but I don't remember enough graph theory for that.
For instance:
An approach to compute efficiently the first intersection between a viewing ray and a set of three objects: one sphere, one cone and one cylinder (other 3D primitives).
What you're looking for is a spatial partitioning scheme. There are a lot of options for dealing with this, and lots of research spent in this area as well. A good read would be Christer Ericsson's Real-Time Collision Detection.
One easy approach covered in that book would be to define a grid, assign all objects to all cells it intersects, and walk along the grid cells intersecting the line, front to back, intersecting with each object associated with that grid cell. Keep in mind that an object might be associated with more grid-cells, so the intersection point computed might actually not be in the current cell, but actually later on.
The next question would be how you define that grid. Unfortunately, there's no one good answer, and you need to consider what approach might fit your scenario best.
Other partitioning schemes of interest are different tree structures, such as kd-, Oct- and BSP-trees. You could even consider using trees combined with a grid.
EDIT
As pointed out, if your set is actually these three objects, you're definately better of just intersecting each one, and just pick the earliest one. If you're looking for ray-sphere, ray-cylinder, etc, intersection tests, these are not really hard and a quick google should supply all the math you might possibly need. :)
"computationally efficient" depends on how large the set is.
For a trivial set of three, just test each of them in turn, it's really not worth trying to optimise.
For larger sets, look at data structures which divide space (e.g. KD-Trees). Whole chapters (and indeed whole books) are dedicated to this problem. My favourite reference book is An Introduction to Ray Tracing (ed. Andrew. S. Glassner)
Alternatively, if I've misread your question and you're actually asking for algorithms for ray-object intersections for specific types of object, see the same book!
Well, it depends on what you're really trying to do. If you'd like to produce a solution that is correct for almost every pixel in a simple scene, an extremely quick method is to pre-calculate "what's in front" for each pixel by pre-rendering all of the objects with a unique identifying color into a background item buffer using scan conversion (aka the z-buffer). This is sometimes referred to as an item buffer.
Using that pre-computation, you then know what will be visible for almost all rays that you'll be shooting into the scene. As a result, your ray-environment intersection problem is greatly simplified: each ray hits one specific object.
When I was doing this many years ago, I was producing real-time raytraced images of admittedly simple scenes. I haven't revisited that code in quite a while but I suspect that with modern compilers and graphics hardware, performance would be orders of magnitude better than I was seeing then.
PS: I first read about the item buffer idea when I was doing my literature search in the early 90s. I originally found it mentioned in (I believe) an ACM paper from the late 70s. Sadly, I don't have the source reference available but, in short, it's a very old idea and one that works really well on scan conversion hardware.
I assume you have a ray d = (dx,dy,dz), starting at o = (ox,oy,oz) and you are finding the parameter t such that the point of intersection p = o+d*t. (Like this page, which describes ray-plane intersection using P2-P1 for d, P1 for o and u for t)
The first question I would ask is "Do these objects intersect"?
If not then you can cheat a little and check for ray collisions in order. Since you have three objects that may or may not move per frame it pays to pre-calculate their distance from the camera (e.g. from their centre points). Test against each object in turn, by distance from the camera, from smallest to largest. Although the empty space is the most expensive part of the render now, this is more effective than just testing against all three and taking a minimum value. If your image is high res then this is especially efficient since you amortise the cost across the number of pixels.
Otherwise, test against all three and take a minimum value...
In other situations you may want to make a hybrid of the two methods. If you can test two of the objects in order then do so (e.g. a sphere and a cube moving down a cylindrical tunnel), but test the third and take a minimum value to find the final object.