"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