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

> > #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 ....

The second one was just comparing two vertices, for a triangle or quad you need
more vertex comparisons.

The mesh library, does it use half edge mesh? You can then count the occurences
of vertex indices. If it does the indexing proper. Too many is an indiction of
problems. Similar with your conversion to mesh2, if you make sure that for each
index you make sure the point is already in the mesh, so no multiple indices to
the same point, the problem can be signalled in that moment.

ingo

Post a reply to this message

sorry ...
maybe we meant two different things
There could be two problems

1) in a triangle a vertex can become the same as another because
a value as 100,123407 becames 100,1234 which is already at another vertex
So the triangle is corrupts

2) two different triangles, because 100,123407 <> 100,1234 can become the same
triangle cutting off excess decimals

but if I always formatted the string output for pov ray,
I think comparing strings using various instrings is the least expensive method,
because it does not have other complex mathematical operations...
in any case I always have a redundant triangle in the mesh.. and I have to
eliminate it..

Post a reply to this message

hi,

"GioSeregni" <gms### [at] hotmailcom> wrote:
> sorry ...
> maybe we meant two different things
> There could be two problems
>
> 1) in a triangle a vertex can become the same as another because
> a value as 100,123407 becames 100,1234 which is already at another vertex
> So the triangle is corrupts
>
> 2) two different triangles, because 100,123407 <> 100,1234 can become the same
> triangle cutting off excess decimals

so what is so "special" about writing only to the 4th decimal digit ?  can you
not simply write the six digits after ?  if nothing else it would much reduce
the likelihood of of two vertices or triangles becoming the same through
truncation.


regards, jr.

Post a reply to this message

"GioSeregni" <gms### [at] hotmailcom> wrote:
> sorry ...
> maybe we meant two different things
> There could be two problems

in your parser/generator output always force 6 digits after the comma. 6 as an
example, a fixed number. Even if it becomes 1.000000 (POV-Ray will pad with 0's
to float64 or what it uses internally?)

if you can't and you have four and six digits mixed, that is what the epsilon is
for. Set it to 0.0001 for example.


ingo

Post a reply to this message

"ingo" <nomail@nomail> wrote:
> "GioSeregni" <gms### [at] hotmailcom> wrote:
> > sorry ...
> > maybe we meant two different things
> > There could be two problems
>
> in your parser/generator output always force 6 digits after the comma. 6 as an
> example, a fixed number. Even if it becomes 1.000000 (POV-Ray will pad with 0's
> to float64 or what it uses internally?)
>
> if you can't and you have four and six digits mixed, that is what the epsilon is
> for. Set it to 0.0001 for example.
>
>
> ingo


I'm not sure I understand what you mean (epsilon?)
PovRay is not the problem
My parser works using double flot. It is better about rotation and normal
computation.
But al the end I prefer to cut small values. They are sometimes born in the
wrong way due to the characteristic of floats.
Sometimes because the model I'm working on was created with absurd decimal
values, due to the modeling software used by those who created them.
In my final output I cut from the fifth decimal place because it is useless for
both rendering and 3D printing.
Or rather, I round to the nearest fourth decimal place.
In any case I eventually have to clean up
duplicates and corruptions from my 4 decimal approximation.
It is not a good thing to cut while I am building a model with CAD, the results
of rotations especially may not coincide.

Post a reply to this message

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

> I'm not sure I understand what you mean (epsilon?)

"Epsilon" is a mathematical concept or symbol used to represent the smallest
value obtainable without actually being zero.
In programming, it is just used as some small value to represent the difference
between 2 values, or just a very small number - such as for use in adding or
subtracting from surfaces in POV-Ray to avoid coincident surface artefacts.


> In any case I eventually have to clean up
> duplicates and corruptions from my 4 decimal approximation.

I have not done any work with processing large meshes, so I don't know if this
will be of any help.

Can you use an octree to limit the number of vertices that you have to check
against any other for duplicates?   The pre-sorting might seem like a large
up-front cost, however the subsequent checking to see if any other vertices in
that cube have similar connections might be well worth it.

Surely there has to be some prior art to search.   Graphics Gems, academic
papers, internet article.   RedBlob games, Stack Exchange, Stack Overflow,
internet articles, YouTube videos...

It has to be a common problem with so many mesh-based applications.

- BE

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "GioSeregni" <gms### [at] hotmailcom> wrote:
>
> > I'm not sure I understand what you mean (epsilon?)
>
> "Epsilon" is a mathematical concept or symbol used to represent the smallest
> value obtainable without actually being zero.
> In programming, it is just used as some small value to represent the difference
> between 2 values, or just a very small number - such as for use in adding or
> subtracting from surfaces in POV-Ray to avoid coincident surface artefacts.
>
>
> > In any case I eventually have to clean up
> > duplicates and corruptions from my 4 decimal approximation.
>
> I have not done any work with processing large meshes, so I don't know if this
> will be of any help.
>
> Can you use an octree to limit the number of vertices that you have to check
> against any other for duplicates?   The pre-sorting might seem like a large
> up-front cost, however the subsequent checking to see if any other vertices in
> that cube have similar connections might be well worth it.
>
> Surely there has to be some prior art to search.   Graphics Gems, academic
> papers, internet article.   RedBlob games, Stack Exchange, Stack Overflow,
> internet articles, YouTube videos...
>
> It has to be a common problem with so many mesh-based applications.
>
> - BE

Yes, I already use it. Here's a test where my 3x3x3 partitions are highlighted
with colors. But I have to say, it's not very helpful. The partitioning is fast,
but it doesn't improve much over time. Perhaps it's because the faces straddle
adjacent partitions and slow down.
But it's not a huge problem, I've now ported all the features to a 64-bit
auxiliary program, and the difference is astonishing. Now I only have the
interface in 32 bit. Then, when everything is ready, I'll convert that too.

Post a reply to this message

Attachments:
Download '658895462_27369642039302458_4039020701347973422_n.jpg' (115 KB)

Preview of image '658895462_27369642039302458_4039020701347973422_n.jpg'