Very general question about the implementation of vectors, vertices, edges, rays etc

[RipX]

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.

OK, I wondered why a parametrized 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 also new to the math behind lines and line segments, so please bare with me. I'm pretty sure that you can define an infinate line with only a normal or a vector and origin 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 implimentation 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?!?

Anyway, 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. Any help, source or some good dialog about of this kind of thing would be great.


RipX

[Freshmaker]

Originally Posted by RipX

OK, I wondered why a parametrized line is not used instead of a ray(or are they??).

They are.

a couple of resources define a Ray.cpp object

A Ray* object.

I would not do this myself as it would force explicit conversions from ray to line/segment, which is almost definitely more trouble than it's worth, imo.

one with a vertex and a vector,

This doesn't make sense. What does a vertex have to do with a ray?

another used a point and a vector.

There is a strong duality between a point and a vector, so this is probably the correct approach.

I would not suggest using separate types for points and vectors, however, as they differ only conceptually. Since the math for each individual type would apply to the other as well, you would write an exponentially larger number of functions to accomodate both in all combinations.

vector and origin

Again, this is a good way to do it.

Lines, rays and segments can all be represented by:


With the the following substitution for t:

Where b represents a fixed vector which coincides with the line and a represents the fixed offset of the base of the vector.

In words, substituting any real value for t in the above equation will produce a point on the line in terms of the length of b. For a unit vector, for example, t would represent the distance from a along the line directly. Constraining t from 0 to infinity inclusive produces a point on the ray that coincides with b, and from 0 to -infinity inclusive produces a point on the ray which coincides with -b. Constraining t from [0, 1] or [-1, 0] produces a point on the line segment the length (or negative length) of b.

But you may have understood all of this already.

the end points of a line segment are often vectors

Remember that the differences between vectors and points are only conceptual.

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 have not seen the function, but would guess that it takes two points, one component at a time, and determines the line they form. The inconsistency between function parameters and return type is likely a poor design decision.

Converting two points to the parametric form of a line above can be done by subtracting the two points (again, remember that points and vectors are structurally the same, so this operation is possible) and substituting the vector formed for b above. In pseudocode, something like:

p0 + t*(p1 - p0)