Question about edge lines and 'overlapping'

[Roland Melkert]

Hello all,

I've been investigating the reason behind some rendering issues in LDCad.

Very noticeable in e.g 2345p04.dat


  renderIssue.png (Size: 22.51 KB / Downloads: 26)

I'm suspecting it comes from the single type 2 lines overlapping multiple triangle/quad edges.

I know this is more of a rendering engine problem then an authoring problem, but I would like to make a case for dividing such edges into segments so they connect with each polygon on the edge.

This because it makes smoothing easier as you can then use edge lines to determine when to average a group of normals.

This is demonstrated in the rendering issue of LDCad as its smoothing algorithm will break normals into groups based up on the fact a point is also used for a type 2 line

A condition which fails for all polygons touching the side or part 2345p04, hence the 'crumbled' paper look.

I could probably fix it, but it would take a whole lot op processing power and administration to try and find all points touching a type 2 line.

Any thoughts on this?

[Travis Cobbs]

I know this is more of a rendering engine problem then an authoring problem, but I would like to make a case for dividing such edges into segments so they connect with each polygon on the edge.

This because it makes smoothing easier as you can then use edge lines to determine when to average a group of normals.

This is demonstrated in the rendering issue of LDCad as its smoothing algorithm will break normals into groups based up on the fact a point is also used for a type 2 line

A condition which fails for all polygons touching the side or part 2345p04, hence the 'crumbled' paper look.

I could probably fix it, but it would take a whole lot op processing power and administration to try and find all points touching a type 2 line.

Much as I hate to admit it, I don't think this is something that we can require of parts authors.

As an aside, LDView's POV export code uses an algorithm similar to yours (using the presence of type 2 lines to indicate creases, instead of using type 5 lines to indicate smooth facets like the main LDView renderer does). I tested it with this part, and it seems to work, so it looks like I went the extra step of detecting which polygon edges overlap the type 2 lines, even when they don't share any vertices.

Note, you can do a quick first-pass check to see if two edges might overlap by storing the normalized direction vector and x,y,z intercept for the infinite line associated with each segment. If the direction vector and intercepts don't match (within some floating point tolerance), you can quickly know that the two segments cannot overlap. This will be the case most of the time. If the vector and intercepts do match (once again, within some floating point tolerance), you can do the more expensive check to see if (and how) the two segments overlap. (Or, more specifically, you can check to the see if the triangle edge is completely inside the type 2 line segment.)

[Philippe Hurbain]

Your requirement is clearly outside the way patterns are done: they consider only surfaces, not edges (or condlines). This is not the case for this particular part, but generally this edge line would be included into the structual subpart without unpatterned areas.