Re: [Gnu3dkit-discuss] G3DLine -intersectsLine:

[Philippe C . D . Robert]

On Monday, October 21, 2002, at 10:20  Uhr, Brent Gulanowski wrote:
> On Monday, October 21, 2002, at 02:08  PM, Brent Gulanowski wrote:
>
> > This method does a blanket failure if the direction vectors are 
> > parallel. I am not a geometry math whiz, but as far as I can tell, 
> > this ignores the case where the lines are coincident.
>
> I've been looking more closely at this class, and I have some 
> suggestions.
>
> By having a factor ivar (_t), we are in fact defining a line segment, 
> not a line. In which case, I don't understand the decision to describe 
> the object using the origin/vector approach. Really, a line and a line 
> segment are two different things. I wonder if we should make this a 
> true line and remove the factor. IMHO, a line segment is best 
> described as origin/endpoint -- I'm not sure whether such a simple 
> object needs a class definition or not.

It is true, the current G3DLine implementation is kind of a hybrid - 
and therefor does not have a clean API either. I was thinking of 
splitting it into a G3DRay (origin + direction) and a G3DLine (start pt 
+ end pt) class.

> If we make the line class more generalized, I also recommend 
> standardizing it further by making the origin point the point on the 
> line which is closest to the origin of the coordinate system. This 
> could be done with a no side effects method (return a new, 
> standardized line). Suggested implementation provided.

Why would you need this? Do you have a real world scenario in mind?

>  I'd appreciate if you could check my code, btw. It depends on the 
> fact that the direction vector is normalized when producing the 
> distance along the line to the new origin (calculated with 
> G3DScalarProduct3fv).
>
> -(G3DLine *) standardize {
>
>   // nearestP = knownP + [knownP . directionVec]*directionVec  ... use 
> origin for knownP
>
>   G3DTuple3f nearestP;
>   float temp[3];
>
>   G3DScaleVector3fv( temp, [direction elements], G3DScalarProduct3fv( 
> [origin elements], [direction elements] ) );
>   G3DVectorAdd3fv( temp, [origin elements], temp );
>   nearestP = [[G3DTuple3f alloc] initWithElements:temp];
>
>   // OK, this is where I freak out from not having autorelease. What 
> is GNUstep doing in these cases?
>   // This is being returned with a ref count of 1, and so violates the 
> Cocoa standard
>
>   return [[G3DLine alloc] initWithOrigin:nearestP direction:direction 
> factor: _t];
>
> }
>
> Note: if you like my other idea (dump the factor ivar), the last line 
> would look like:
>
> return [[G3DLine alloc] initWithOrigin:nearestP direction:direction];
>
> because we'd have to change the relevant init method.

I guess the API will change anyway if we are going to have a ray and a 
line (segment) class. BTW the naming in the GK is like

- (void)process;
  // performs the operation in place
- (AnObject *)processedObject;
  // returns an autoreleased object which has been processed

I will have a look at all it this evening, if I can find some time.

-Phil
--
Philippe C.D. Robert
http://www.nice.ch/~phip