This is just a LARGE generalized question regarding rays (and/or line segments or edges etc) and their place in a software rendered 3d engine that is/not performing raytracing operations. I'm learning the basics and I'm the first to admit that I don't know much about this stuff so please be kind. :)
I wondered why a parameterized line is not used instead of a ray(or are they??). I have looked around at a few cpp files around the internet and seen a couple of resources define a Ray.cpp object, one with a vertex and a vector, another used a point and a vector. I'm pretty sure that you can define an infinate line with only a normal or a vector and then define intersecting points along that line to create a line segment as a subset of that infinate line. Are there any current engines implementing lines in this way, or is there a better way to go about this?
To add further complication (or simplicity?) Wikipedia says that in vector space, the end points of a line segment are often vectors, notably u -> u + v, which makes alot of sence if defining a line by vectors in space rather than intersecting an already defined, infinate line, but I cannot find any implementation of this either which makes me wonder about the validity of my thoughts when applying this in a 3d engine and even further complication is created when looking at the Flash 3D engine, Papervision, I looked at the Ray class and it takes 6 individual number values as it's parameters and then returns them as 2 different Number3D, (the Papervision equivalent of a Vector), data types?!?
I'd be very interested to see an implementation of something which actually uses the CORRECT way of implementing these low level parts as per their true definitions.
I'm pretty sure that you can define an infinate line with only a normal or a vector
No, you can't. A vector would define a direction of the line, but all the parallel lines share the same direction, so to pick one, you need to pin it down using a specific point that the line passes through.
Lines are typically defined in Origin + Direction*K form, where K would take any real value, because that form is easy for other math. You could as well use two points on the line.
Related
I apologize for any formatting mistakes, first time here.
I'm currently working on program in Java as a personal project that simulates and allows for the design of a lens system with surfaces generally defined using the equations covered here (Wikipedia). In this case the "order" of the surface referring to the greatest axrx value. Although possible, I'm pretty sure the order rarely is above 12.
Single solution:
Multiple solutions:
The linked images show two possible cases for a complex aspherical lens defined using this particular equation:
Assuming a "ray" comes from somewhere below the frame upwards as seen in the examples, how would I calculate the first point of collision between that ray and the lens surface? Specifically in three dimensions, as the examples above are only two dimensions as limited by Desmos. Being a lens, the resulting surface in three dimensions is possesses rotational symmetry where the 2D examples have reflection symmetry.
Edit removes unneeded sentence.
I want to write a program with 'geometry automata'. I'd like it to be a companion to a book on artistic designs. There will be different units, like the 'four petal unit' and 'six petal unit' shown below, and users and choose rulesets to draw unique patterns onto the units:
I don't know what the best data structure to use for this project is. I also don't know if similar things have been done and if so, using what packages or languages. I'm willing to learn anything.
All I know right now is 2D arrays to represent a grid of units. I'm also having trouble mathematically partitioning the 'subunits'. I can see myself just overlapping a bunch of unit circle formulas and shrinking the x/y domains (cartesian system). I can also see myself representing the curve from one unit to another (radians).
Any help would be appreciated.
Thanks!!
I can't guarantee that this is the most efficient solution, but it is a solution so should get you started.
It seems that a graph (vertices with edges) is a natural way to encode this grid. Each node has 4 or 6 neighbours (the number of neighbours matches the number of petals). Each node has 8 or 12 edges, two for each neighbour.
Each vertex has an (x,y) co-ordinate, for example the first row in in the left image, starting from the left is at location (1,0), the next node to its right is (3,0). The first node on the second row is (0,1). This can let you make sure they get plotted correctly, but otherwise the co-ordinate doesn't have much to do with it.
The trouble comes from having two different edges to each neighbour, each aligned with a different circle. You could identify them with the centres of their circles, or you could just call one "upper" and the other "lower".
This structure lets you follow edges easily, and can be stored sparsely if necessary in a hash set (keyed by co-ordinate), or linked list.
Data structure:
The vertices can naturally be stored as a 2-dimensional array (row, column), with the special characteristic that every second column has a horizontal offset.
Each vertex has a set of possible connections to those vertices to its right (upper-right, right, or lower right). The set of possible connections depends on the grid. Whether a connection should be displayed as a thin or a thick line can be represented as a single bit, so all possible connections for the vertex could be packed into a single byte (more compact than a boolean array). For your 4-petal variant, only 4 bits need storing; for the 6-petal variant you need to store 6 bits.
That means your data structure should be a 2-dimensional array of bytes.
Package:
Anything you like that allows drawing and mouse/touch interaction. Drawing the connections is pretty straightforward; you could either draw arcs with SVG or you could even use a set of PNG sprites for different connection bit-patterns (the sprites having partial transparency so as not to obscure other connections).
I'm working on a problem to eliminate common line segments in a collection of Paths. Many of these paths share the same segment.
It seems that a 2D line would have some way to uniquely identity itself. Like a Key.
So a Line [(A,B), (C,D)] is the same as [(C,D), (A,B)]
Only Solution I could come up with is to sort the points.
This seems like it would be a common problem in Math or Graphics but the solution escapes me.
From a mathematical point of view, this looks like a matter of an undirected graph (as opposed to a directed graph).
Sorting the points is one way to handle this: it's a straightforward way to represent an unordered edge with a single, unambiguously selected value (it shouldn't matter what ordering you choose, as long as it is consistent for all possible segments). You do need to ensure that you maintain this ordering as an invariant: accidentally slipping in a mis-ordered edge could cause problems for anything that depends on the ordering.
However, mathematically speaking, undirected graphs are often defined as directed graphs with a symmetry property: if (A,B) is an edge, then so is (B,A). This suggests another way: ensure that you always store both (A,B) and (B,A). Perhaps both segment orderings could have a link to any common data, and possibly a fast way to access one from the other. (As with the sorted point method, you need to maintain this symmetry as an invariant.)
The best choice depends on your application. If you're using your segments as a key, the sorting method might be best. However, some applications are a better match for the symmetric method. For example, the doubly connected edge list is a data structure which represents each edge as two linked "half-edges", one in each direction.
Since you mention graphics, note that the doubly connected edge list is often used to represent the edges of 3-D polytopes.
Also, note the similarity to oriented triangles: there are good, practical reasons for computer graphics to treat triangles as "one-sided", such that drawing a triangle visible from one side is distinct from drawing the same triangle visible from the other. Like half-edges, this distinction is determined by the order of the vertices: clockwise for one side, counterclockwise for the other.
I have a question I didn't find an answer to on google or the forum and decided to ask here for help.
I am a fairly seasoned programmer and have had many successes on various platforms but I didn't use/need a lot of mathematics until now.
Now I need to know how to build a function which receives an array of 5 points (4 sided pyramid) and a single vector. The Question is whether this 3d vector lays inside of the pyramid.
The function would ultimately be written in (Mono) C# but if you have hints or code for other languages or you can help with plain mathematics that would be absolutly fine, too.
A vector never lays inside anything. I guess you meant that you have a 3D point, not a 3D vector.
In that case, a simple solution (that works for any convex polyhedron) is to check whether your point is on the correct half spaces when considering each face of your pyramid.
Specifically, take two vectors in the first face of your pyramid (e.g., two edges) and form a third vector with one point on this face (e.g., one of the vertices) and the point to be tested. Using the sign of the mixed product (i.e., take the cross product of the two edges, which results in a vector orthogonal to the pyramid face, and check with a dot product whether this normal is in the same direction as your third vector), you can determine on which side your point is.
Repeating the procedure for all faces allows you to conclude.
I have been looking at posts about determining if a point lies within a polygon or not and the answers are either too vague, abstract, or complex for me. So I am going to try to ask my question specific to what I need to do.
I have a set of points that describe a non-straight line (sometimes a closed polygon). I have a rectangular "view" region. I need to determine as efficiently as possible whether any of the line segments (or polygon borders) pass through the view region.
I can't simply test each point to see if it lies within the view region. It is possible for a segment to pass through the region without any point actually inside the region (ie the line is drawn across the region).
Here is an example of what I want to determine (red means the function should return true for the set of points, blue means it should return false, example uses straight lines and rectangles because I am not an artist).
Another condition I want to be able to account for (though the method/function may be a separate one), is to determine not just whether a polygon's border passes through the rectangular region, but whether the region is entirely encompassed by the polygon. The nuance here is that in the situation first described above, if I am only concerned with drawing borders, the method should return false. But in the situation described here, if I need to fill the polygon region then I need the function to return true. I currently do not need to worry about testing "donut" shaped polygons (thank God!).
Here is an example illustrating the nuance (the red rectangle does not have a single vertex or border segment passing through the on-screen region, but it should still be considered on-screen):
For the "does any line segment or polygon border pass through or lie on screen?" problem I know I can come up with a solution (albeit perhaps not an efficient one). Even though it is more verbose, the conditions are clear to me. But the second "is polygon region on screen?" problem is a little harder. I'm hoping someone might have a good suggestion for doing this. And if one solution is easily implemented on top of the other, well, booya.
As always, thank you in advance for any help or suggestions.
PS I have a function for determining line intersection, but it seems like overkill to use it to compare each segment to each side of the on-screen region because the on-screen region is ALWAYS a plain [0, 0, width, height] rectangle. Isn't there some kind of short-cut?
What you are searching for is named a Collision Detection Algorithm A Google search will lead you to plenty of implementations in various language as well as a lot of theory
There are plenty of Geometric theory behind, from the simplest bisector calculus to Constrained Delaunay Triangulations and Voronoi Diagrams (that are just examples). It depends on the shape of Object, the number of dimensions and for sure the ratio between exactness needed and computing time afforded ;-)
Good read
PS I have a function for determining
line intersection, but it seems like
overkill to use it to compare each
segment to each side of the on-screen
region because the on-screen region is
ALWAYS a plain [0, 0, width, height]
rectangle. Isn't there some kind of
short-cut?
It's not an overkill, its neccessary here. The only kind of shortcut I can think of is to hardcode values [0, 0, width, height] into that function and simplify it a bit.