"Bald Eagle" <cre### [at] netscapenet> wrote:
> "GioSeregni" <gms### [at] hotmailcom> wrote:
>
> > That's what I already do. I wanted to know if, alternatively (when I go from a
> > double float with area to a single float that becomes arealess), when POV
> > automatically detects and marks them, it can also do this in the file.
> >
> > To avoid reprocessing all the normals in the single float.
>
> It cannot.
> That sort of file processing is left to the user.
>
> At present, we have what we have been given in our little open-source collection
> of modules.
>
> And as clipka was fond of saying: "POV-Ray is a raytracer".  And so there's not
> a lot of "extraneous" capability tied in to the parser.
> And we all know clipka's legendary love for the parser.
>
> So, you either need to write a processor yourself in SDL,
> or as a 3rd-party tool in some other language,
> or write something that can perform that task and be integrated into source.
>
> IIRC, I think MeshLab will detect all the bad triangles, close any holes, and
> save a good file.
>
> - BE

OK, now I'm sure there's no way; studying the #debug function, I couldn't figure
out if it was possible.
I'll implement an additional control filter in my parser, along with the
formatting function I use when generating the pov and inc files.
Note: I normally use MeshLab, but be careful with filters. Sometimes, when
closing holes, and especially in decimation, it introduces intersections that
become tedious to track down. If I use these functions, I then test and ask the
entire shape to normalize again, to verify that no bugs have been generated.
Decimation is really dangerous.

Post a reply to this message

ok, thanks to all
my trouble was about the format of vertex only on ####.#### that can to
degenerate triangle losing last decimals ...
if the #debug cannot try them out, I have to control the triangle again after
the formatting procedure of my parser
no proble... this is my parser working
sketch-up , cad, pov STL ..

Post a reply to this message

Attachments:
Download 'screenshot 2026-04-06 163214.png' (546 KB)

Preview of image 'screenshot 2026-04-06 163214.png'

"GioSeregni" <gms### [at] hotmailcom> wrote:
> ok, thanks to all
> my trouble was about the format of vertex only on ####.####

Is there a way to filter out those triangles from the start?
Are they even necessary / visible?

You can probably test just the fractional portion of your double/float by using
modulo.

#if (mod(Number, 1) < threshold) then ignore triangle #else keep it #end

- BE

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "GioSeregni" <gms### [at] hotmailcom> wrote:
> > ok, thanks to all
> > my trouble was about the format of vertex only on ####.####
>
> Is there a way to filter out those triangles from the start?
> Are they even necessary / visible?
>
> You can probably test just the fractional portion of your double/float by using
> modulo.
>
> #if (mod(Number, 1) < threshold) then ignore triangle #else keep it #end
>
> - BE

Unfortunately, it's more complicated. If the mod exists beyond a certain decimal
point, the parser must first clean up the vertex by the small part of float,
then check if a twin face exists.
I'll have to create a twin face search loop after writing the mesh with
formatting that trims small decimal points... that is, a loop nested within
another loop... a lot of runtime.
povray forgives a duplicate face, but the other formats I use do not (for an STL
this is a serious mistake)

Post a reply to this message

Nothing, I think the most efficient solution is to ignore float comparisons,
much less divisions.
But create the pov file as a temporary one, and reprocess it by comparing
vertices with string functions. If a triangle has two equal vertices, it should
be removed.

Post a reply to this message