LDraw.org Discussion Forums

Full Version: Point matching Re: Question about edges
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3
I'm going to split this off as a new thread since the old one is unwieldy...

When we develop a list of points (via check and snap), there will be (hopefully only a few) remaining points that have not been snapped to each other and remain with only _one_ tri or quad accessing them. We can exploit this as these points must be:
  • Part of a t-junction
  • A point that has not been snapped properly
  • An edge point (but this should be illegal in an LDraw part)

There is absolutely no other reason for a point not the be shared amongst at least two tris/quads. We can store the number of facet prims accessing the point via a simple count on the list of points.

So here's the deal:

foreach Point not in TwoTris/Quads
  # Check if the point is part of a t-junciton
  If CheckForTJunction then  SplitTJunction

  # Check for nearby points with a larger (eg. 0.05) tolerance

If, at the end of this code, there are points that are still not shared then the part can probably be flagged as bad.

Quote:An edge point (but this should be illegal in an LDraw part)
Could be a point inside interpenetrating surfaces.
Hmmm. I'm not exactly sure what you mean. But trust you completely to have thought of something I've missed Smile

Do you have an example?

That is exactly the way Gapfinder is working (http://ldraw.heidemann.org/index.php?page=gapfinder) (except of snapping before).
Not a partnumber at the moment, but there are many parts that uses primitives (mostly curved) that builds the shape, but not truncated as needed (as that would eliminate the build in smoothing for that primitives) and the egdeline is just generated by isecalc. The remaining part of the primitive just pokes into the inside of the part and is never visible except at parts that can also occur as transparent. Therefore at those parts this technic should be avoided.
Thanks, gotcha. I've even done that myself and it is of course allowable in parts.

Hi Guys,

Tim, I'm not sure I understand the algo: are you saying that you can optimize the number of T junction searches by ignoring already-shared points? I think this would not be the case when two properly-shared meshes are connected to each other without proper T-junction removal.

Or did I misunderstand the intent here?

For Michael and Philippe's case, I've been assuming that I will not try to fix T junctions that cannot participate in smoothing because they are not coplanar with a surface, on an edge, or the angle of the two surfaces in question is larger than the global crease angle.

In terms of permformance, I think that only finding T's "on a line" will give a good speed-up if a spatial index is used; I'll post back when I have this running. Finding interpenetration would be much slower (you have to query 'everywhere') but isn't necessary for smoothing.

Do you mean parts like 32495.dat?

These are giving me sleepless nights at the moment Smile Smoothing trips over them, and doing T-Junction fixes makes it even worse because it's actually trying to join the individual segments, at places where polygon edges happen to almost toch one of the 'grid' indexed vertices.

This also happens on e.g. 1x1 round plates. But with them it isn't noticeable.
Ben Supnik Wrote:In terms of permformance, I think that only finding T's "on a line" will give a good speed-up if a spatial index is used

Fixing only stuff on edges won't work, take for example the standard grin minifig head, it's whole face is edgeless and this is exactly the place that needs to be tj-fixed.

On the other hand I have nearly perfect TJ-Fixing running at the moment but the smoothing results on detailed curved surfaces are still a mess. I'm going to fix the non bfc awareness today, but I doubt it will help much (judging from the bfc-ed minifg heads).
Yes, that is a good example Smile
Pages: 1 2 3