Error in Triangles with a small side

soldatino

First, Excuse my bad English
In some plugin of mine I have a filter working of the faces that I import or export in SU.
This is the code for a 3 points face:


if (pts[0].vector_to(pts[1]).parallel? pts[1].vector_to(pts[2]))==false
     if (pts[1].vector_to(pts[2]).parallel? pts[2].vector_to(pts[0]))==false
           nu=ent.add_face pts[0..2]
           nu.material=matf
           nu.back_material=matf
     end
end

It is my workaround because I need to filter for example a false triangle, where all the 3 points are filled in the same segment, and the face has not really area.
Well, luckily this code traps also captures TRUE faces that have 2 long sides and one side very small.
EXAMPLE:
-42.711087, 3.524699, 0.0 (vertex 1)
-42.711084, 3.524691, 0.0 (vertex 2)
1705.049441, 820.900776, 0.0 (vertex 3)
This is a valid triangle but, if I attempt to import it, without the filter I wrote, SU fails and the plugin exit out.
The concept is : SU allows floating points, these points are really imported, I debug using
UI.messagebox( (pts[0]).to_s)
UI.messagebox( (pts[1]).to_s)
UI.messagebox( (pts[2]).to_s)
but the sides ARE NOT parallel, even if the API say YES!
And also if I attempt to create a triangle!
What a kind of floating values does SU use?

slbaumgartner

To avoid issues with floating point arithmetic, SketchUp has an internal tolerance of about .001". This was chosen based on its original use in architecture. In various operations, it tests values (especially vertices) for match to within tolerance. Depending on the operation, it may merge nearby vertices into one (basically, making the assumption they differ only due to numeric error) or may do things like you observed and proclaim two lines parallel when they are "close enough". In your very narrow triangle, the short side has its points so close together that they are hitting these effects.

Note: this is also what will sometimes cause a follow-me or intersect operation to leave some holes or gaps in the result.

The usual workaround is to scale the model up until the points are separated by more than the tolerance and then to scale it back down when completed, as the problem isn't really with the floating point values, it is with how SketchUp handles them in certain operations.

soldatino

Many thanks for the quick response, I suspected but now I am sure I did not make mistakes, so I'll keep the filter. The problem is theoretic and practically it shows in "wrong" , or better "bad", drawings , and also the import plugin is already very slow and an operation of this kind, much much more slow. Indeed I thought in the practice of what is necessary to enlarge the incoming data so as to insert acceptable values, and then reduce the modified product after extracted again from SU.
I now have a very clear idea then! Thanks again!

AdamB

Just as some background. When conditioning geometry, we make a distinction between zero-area triangles - which are useful to ensure the surface is fully connected, and degenerate triangles in which 1 vertex is repeated. The latter is something you generally want to filter out of your model - and SketchUp does this.

Adam

soldatino

Yes, this is a opinion, but I need to export to PovRay, one of the best rendering engines, which does not recognize a triangle which is a straight line with the apex of the triangle placed at an intermediate point. And I can not manually delete step by step all the lines of code that stop and report.

AdamB

@soldatino said:

Yes, this is a opinion, but I need to export to PovRay, one of the best rendering engines, which does not recognize a triangle which is a straight line with the apex of the triangle placed at an intermediate point. And I can not manually delete step by step all the lines of code that stop and report.

Well that would mean POVRay cannot process any geometry with T-junctions. Which in turn means you're going to have cracks in your rendered surfaces because in removing zero-area 'stitching' triangles, you've broken topology.

Get a better renderer is my opinion.

soldatino

Lol PovRay does not want triangles because they are redundant information. They are simple edges of something that it does not exist, the edges are not rendered. A triangle of these would be in any case invisible. Some graphics engine uses them but for their own reasons computational graphics. For example sculpties in Second LIfe absolutely needs the mesh is continuing to wrap objects, and I used these invisible triangles to have two detached objects but part of the same mesh ....

This is a PovRay example !

AdamB

@soldatino said:

Lol PovRay does not want triangles because they are redundant information. They are simple edges of something that it does not exist, the edges are not rendered. A triangle of these would be in any case invisible. Some graphics engine uses them but for their own reasons computational graphics. For example sculpties in Second LIfe absolutely needs the mesh is continuing to wrap objects, and I used these invisible triangles to have two detached objects but part of the same mesh ....

Yes, I don't think you're understanding my simple point.

A triangle is inscribed on a plane and its boundary is defined by edges. Any renderer must has topologically manifold surfaces to avoid cracks showing up. Its nothing to do with how small your triangles are, its nothing to do with whether you render (sic) edges.

This is a good paper you should read: http://www.imr.sandia.gov/papers/imr14/patel.pdf

soldatino

Thank indication but I already know something about the triangles.
Here we are talking about special triangles.
The false (type 1), and the triangles of the topic in the title (type 2). I had a very good answer on SketchUp behavior, which in extreme cases consider them in the same way.

@slbaumgartner said:

To avoid issues with floating point arithmetic, SketchUp has an internal tolerance of about .001". This was chosen based on its original use in architecture. In various operations, it tests values (especially vertices) for match to within tolerance. Depending on the operation, it may merge nearby vertices into one (basically, making the assumption they differ only due to numeric error) or may do things like you observed and proclaim two lines parallel when they are "close enough"...

If you read the start of the topic you will see what the problem was.
Anyway, thank you, there is always more to learn each other, I made a drawing to explain better the concepts already discussed.

driven

are you updating su2pov3.rb or starting again?
john

AdamB

Type 1 triangles are valid in the context of rendering. Yes, they are zero-area - but that's OK because they are also guaranteed to never be hit by a ray. What they do is preserve topology.

However, when you have a zero-length edge (A and C at the same position) - aka a degenerate triangle - that is invalid and should be removed.

The reason you really want zero-area, non-degenerate triangles is for this case:

The triangle ABC has zero-area - BUT is critical to retaining a continuous surface. If you remove ABC, what happens is you get tiny cracks in the rendering because computers use a finite precision floating point representation - cracks in your render are entirely unavoidable without these 'stitching triangles'.

Anyway, best of luck with your solution.

soldatino

@adamb said:

The reason you really want zero-area, non-degenerate triangles is for this case:
[attachment=0:1fn6aq9s]KeynoteScreenSnapz018.png[/attachment:1fn6aq9s]

The triangle ABC has zero-area - BUT is critical to retaining a continuous surface. If you remove ABC, what happens is you get tiny cracks in the rendering because computers use a finite precision floating point representation - cracks in your render are entirely unavoidable without these 'stitching triangles'.

Anyway, best of luck with your solution.

Of course, but I have no plans to remove the false triangles in SU, the filter of mine is working in output to other engines, which do not like the fake triangle. But the problem is present in SU, that does not accept them as input, SU uses only three decimals and does not import certain triangles with a small side ... but it's only a problem conceptually. These faces are so thin that do not get "cracks" visible.

soldatino

@driven said:

are you updating su2pov3.rb or starting again?
john

No, it's an old version, I'm working on a new one, but unfortunately I'm trying to understand how to use SketchUp Alpha declared a value on one side, and a different value in the same back_face simultaneously. All this is complicated by the same concept in the statements of the parent block. A problem that for now I can not find answer .....

This is a version a bit less old, but I hope to improve soon
http://imitidicthulhu2.blogspot.it/2010/12/skup2ray-v006.html