Error in Triangles with a small side
-
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.
-
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! -
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
-
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.
-
@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.
-
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 !
-
@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
-
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.
-
are you updating su2pov3.rb or starting again?
john -
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.
-
@adamb said:
The reason you really want zero-area, non-degenerate triangles is for this case:
[attachment=0:1fn6aq9s]<!-- ia0 -->KeynoteScreenSnapz018.png<!-- ia0 -->[/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.
-
@driven said:
are you updating su2pov3.rb or starting again?
johnNo, 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
Advertisement