> re 'trace', yes, you can use the optional parameter to check the normal's not
> zero and take whatever "action" is needed.
>

sorry I can't explain myself well in English
I don't need that POV to "fixes" the errors in the final render, or give me an
error message step by step over the lines.
I'd like two alternatives.
A precise report on "where" the errors are (es. list numbers line).
Or the elimination of corrupt triangles, physically, by overwriting the file I
pass it.
My goal is to generate clean meshes.
Thanks!
G.

Post a reply to this message

Am 03.04.26 um 20:13 schrieb GioSeregni:
> 
>> re 'trace', yes, you can use the optional parameter to check the normal's not
>> zero and take whatever "action" is needed.
>>
> 
> sorry I can't explain myself well in English
> I don't need that POV to "fixes" the errors in the final render, or give me an
> error message step by step over the lines.
> I'd like two alternatives.
> A precise report on "where" the errors are (es. list numbers line).
> Or the elimination of corrupt triangles, physically, by overwriting the file I
> pass it.
> My goal is to generate clean meshes.
> Thanks!
> G.
> 
> 
I fear there more than one misunderstanding here.

POV cannot debug meshes. The #debug statement displays messages to the 
log only. It can be helpful while debugging a scene but does nothing 
more than displaying text.

To fill holes, eliminate duplicate vertices, adjust wrong normals and do 
other repairs on meshes ypu should consider meshlab. Some of these tasks 
can also be achieved using Blender.

Best regards
Michael

Post a reply to this message

hi,

"GioSeregni" <gms### [at] hotmailcom> wrote:
> > re 'trace', yes, you can use the optional parameter to check the normal's not
> > zero and take whatever "action" is needed.
> sorry I can't explain myself well in English

write (an email) in Italian if you prefer.  (I've Google Translate to hand :-))


> I don't need that POV to "fixes" the errors in the final render, or give me an
> error message step by step over the lines.
> I'd like two alternatives.
> A precise report on "where" the errors are (es. list numbers line).
> Or the elimination of corrupt triangles, physically, by overwriting the file I
> pass it.
> My goal is to generate clean meshes.

the file you pass to POV-Ray already is a mesh I assume; I looked at your
'furgone' and 'bmwvintage' files.  problem 1 -- you pass a mesh to POV-Ray.
meaning, that will simply get parsed and "we" (users) get no information.
problem 2 -- selective overwriting, no can do.  if you could pass CSV files with
(sets of three) vectors, then one could read and process those, and "line
numbers" and eliminating unwanted triangles would become "doable" (if slow).
with your current file format, ie fully specified meshes, POV-Ray is the wrong
tool, imo.


regards, jr.

Post a reply to this message

> (sets of three) vectors, then one could read and process those, and "line
> numbers" and eliminating unwanted triangles would become "doable" (if slow).
> with your current file format, ie fully specified meshes, POV-Ray is the wrong
> tool, imo.
>
>
> regards, jr.

Yes, POV-ray isn't responsible for editing files, but for rendering them.
But I had the idea because it can instantly identify small errors in the shape
that I'd missed when switching from double to single. So I wondered if there was
a way to have it list or correct them without having to go back and re-filter
again.....

Note :In the models I finally store, I generally save the final result in single
float with 4 decimal places.
If they're POV or INC, they're more compact and still satisfactory. If they're
3D for print, even more so, because STL requires single float.
thanks!
BR
G.

Post a reply to this message

Gio,

It sounds to me like what you want to do is read in a mesh, and perform a vector
cross product calculation.

That should identify any degenerate triangles, since the cross product will be
0.

Discard those, and write the good triangles to a new file.

- BE

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Gio,
>
> It sounds to me like what you want to do is read in a mesh, and perform a vector
> cross product calculation.
>
> That should identify any degenerate triangles, since the cross product will be
> 0.
>
> Discard those, and write the good triangles to a new file.
>
> - BE
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.
TX
G.

Post a reply to this message

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