- Hi Roger

On Mon, 1 Feb 2010, Roger Kaufman wrote:

> I went over the code they have on their page. The noteworthy change is

> the P = P0 + sc*u change from P = P1 + ... same for Q.

Well done for finding the solution. I have checked and I introduced

this error into the development code when I was renaming function

arguments to try to make them consistent between the various

functions.

I use the function in kcycle and the examples I have tried

have worked with both forms of the function!

You are right about the need for these functions to

take an epsilon argument.

> if(lines_nearest_points(P, P_dir, Q, Q_dir, N1, N2, epsilon)) {

...

> The call to lines_nearest_points uses P_dir instead of P+P_dir. Same for Q.

I don't think that should work, generally. lines_nearest_points

is expecting two points that lie on a line and P_dir won't

generally lie on the line through P and P+P_dir (only

in the case where the line passes through the origin.)

Regarding the parameters, it is probably better for

lines_intersection to have the same line parameters

as lines_nearest_points. I will change it to take all

point parameters. (No plans to add it in, but it would

be nice to be able to distinguish position vectors and

free vectors).

> This maybe should be the only way it can work. If N1 and N2 are two far

> apart it probably shouldn't give an answer? (it is suppose to be

> intersection)

I originally added it as a convenience function to find the

intersection of lines lying in the same plane. It therefore

always returns a "best" intersection point (the lines may

just miss), and returns an unset vector if the lines are

parallel. Maybe it would be better to call the function

coplanar_lines_intersection. I will also improve the

documentation.

> vec3d lines_intersection_in_segment(vec3d P, vec3d P_dir, vec3d Q, vec3d Q_dir, double epsilon)

> bool in_segment(vec3d intersection_point, vec3d P, vec3d P_dir, vec3d Q, vec3d Q_dir)

...

> So far in what I have tested this works.

I'll wait until you send me something, and then add them into vec_utils

with the others.

> I am finding the triangle overlap code is going to be fairly complex!

Did you look into using the GLU Tesselator? It appeared that

it would make it quite straightforward to pick out the overlapped

and non-overlapped parts.

Adrian.

--

Adrian Rossiter

adrian@...

http://antiprism.com/adrian - Hi Adrian,

> > program was not finding the co-planar faces! This could would not work

This was a bit of a panic on my part. The code works on everything unitile2d produces. But is possible to create a tiling by hand such that the normals point in opposite directions and it isn't possible using the code above to determine direction. The program doesn't need to be able to work with models that are already just one plane.

> > in this case

> >

> > vec3d norm = face_norm(verts, faces[i]).unit();

> > double D = vdot(verts[faces[i][0]]-C, norm);

> > if(D < 0) // Make sure the normal points outwards

> > norm = -norm;

> >

> > Is it because the centroid is also on the plane with the two coplanar

> > triangles? I think that was the reason.

>

> If you have a triangle on a plane then the vertices, in

> order, wind in some direction around the triangle centroid

> relative to one side of the plane. The direction of the

> normal depends on this winding direction. If you have two

> triangles on the same plane that wind in different

> direcions then they will have normals that point in

> opposite directions.

> I haven't had chance to comment on your utility to display

The program is becoming a mix of code. Where it should all end up can be dealt with later. It is possible some of it might go in src_extra if desired.

> normals yet. I was thinking that the face attached normals

> would be of visual interest and could be an option in off2*

> and antiview. If there is a geometric use then an option

> could be added to off_util for now.

But it is nice to plot the normals and see how they stay put no matter what position the model is translated to. I am wondering if a polyhedra can be scaled and positioned such that all the normal to face distances are minimial.

> > says that is is not orientable and is not oriented! I am hoping there is

Again more panic on my part. The planes only need to be found before triangulation. On 3D models it is no problem to force normals to all point one way. So in that respect it doesn't even matter of the model is oriented on the way into the program!

> > a bug going on somewhere. Or perhaps some limitation happened.

>

> This is a good one to find. I haven't checked but I

> think I know what is going on. It looks like a bug

> caused by having incomplete information about how

> faces are connected when more than two meet at an edge.

>

> The first minor issue is that after finding a polyhedron

> is oriented it isn't necessary to try and orient it to

> check whether it is orientable!

It also doesn't matter if the output is orientable. The models are being produced for the sake of viewing. I am not even sure yet, that the output will always come out as closed polyhedra, although I am hoping this is the case!

Roger