Let's see if I can make myself understood with a simple example.
I have a triangle.

<1,1,1><2,1,1><2,1,1.00000009>
this is a valid triangle
ok?

but if I made automatically a pov ray file that uses the format ###.####,
writing the pov file , the triangle becomes with

the vertex 3 becomes = vertex 2
and the triangle is invalid
obviously !!!

If I want to avoid re-checking for every triangle in the formatted file, is it
possible to have POV Ray remove them from my file?
In a new, clean file
or, returning a list of the triangles to delete.

Post a reply to this message

"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

Post a reply to this message

"GioSeregni" <gms### [at] hotmailcom> wrote:

> I've studied the #debug feature a bit, but I don't understand. Is there a way to
> tell PovRay to generate a file with only the incorrect entities, or to rewrite
> my file to clean them up?
> It would save me some often long and tedious work.

The mesh2 files are not accessible as arrays, so you can't loop over the content
and check for vertices being ~equal.

Options:
- manually or using a script turn your mesh-file into a file of arrays. Then you
can loop over them and check

- write a small mesh2 parser in a scripting language. There then loop over the
triangles. I once wrote a mesh2 to obj converter in Python. It may still be
somewhere in the newsgroups. I myself lost it.

- use a mesh cleaner. May have to convert to an other format first, or if you
use an other format before converting to mesh2, use that file format to clean.

- check what PoseRay can do (for you) in this regard. I really don't know, it's
been a long time since i used it.

ingo

Post a reply to this message

"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

"GioSeregni" <gms### [at] hotmailcom> wrote:
> Nothing, I think the most efficient solution is to ignore float comparisons,
> much less divisions.

something like:

##for floats:
## Almost equal.
proc ae(a, b): bool
const Epsilon = 0.000001
return abs(a - b) <= Epsilon


#for tw vac's a & b
proc ae(a,b): bool
return ae(a.x, b.x) and ae(a.y, b.y) and ae(a.z, b.z)


depending on the lang.


ingo

Post a reply to this message

"ingo" <nomail@nomail> wrote:
> "GioSeregni" <gms### [at] hotmailcom> wrote:
> > Nothing, I think the most efficient solution is to ignore float comparisons,
> > much less divisions.
>
> something like:
>
> ##for floats:
> ## Almost equal.
> proc ae(a, b): bool
> const Epsilon = 0.000001
> return abs(a - b) <= Epsilon
>
>
> #for tw vac's a & b
> proc ae(a,b): bool
> return ae(a.x, b.x) and ae(a.y, b.y) and ae(a.z, b.z)
>
>
> depending on the lang.
>
>
> ingo

does not works
the triangles can to be
a.x - a.y - a.z
VS
b.y . b.z - b.a

and other cases ....

Post a reply to this message