Re: [Meshlab-devel] quadric filters

[Paolo C. <pao...@is...>]

skunkwerk wrote:
> thanks team,
>     i did some more testing on the quadric-texture filter with border
> preservation enabled, on about 100 different models.
>
> 1)  on some models (example file: www.akbars.net/20.zip) you simply can't
> reduce the model past a certain number of faces (in this case, 55,000) with
> border preservation on - the filter will run, but will stop after having
> reduced not all the way... is this intentional?
>   
in some sense yes.
Preserving borders means that you do not change at all boundary edges, 
only the vertices not on the boundary will be considered for removal.
If you model is compose mostly by borders it is quite evident that you 
will not simplify a lot.
The fuselage of model 20 is mostly composed by non manifold faces, that 
are considered as border, so you will not simplify it a lot.
The real issue is that for everitying holds the golden rule : rubbish in 
rubbish out.

The plane model is a really trashy one, with a lot of geometric 
inconsistencies, modeling errors, non manifold faces etc...
It will be really hard to get something good from it without a complete 
remeshing....

> 2)  on some models (example file: www.akbars.net/27.zip) turning on border
> preservation results in the model turning into a blob (shape doesn't look at
> all the same), whereas with the same number of target faces, the regular
> quadric will keep the shape, though lose some faces - is it possible that
> the border isn't being preserved correctly with the quadric-texture filter?
>   
It is the correct behaviour. the shape that you get is the shape of an 
object where all the border vertices are preserved, and almost all the 
internal vertices have been deleted.
If you flag border preservation and ask for a face number that is 
smaller of the number of faces on the boundary you have to cope with the 
fact that border are preserved (doh!)

This model is junky as the previous one... one of the tree has approx 
26k faces in the leaves. All the leaves has no internal vertex so, by 
definition, they cannot be simplified if you preserve the border....
> 3)  is it possible that the lack of the 'preserve normals' option could be
> the cause of the different performance between the 2 filters?  would it be
> possible to enable this feature for the quadric-texture filter?
>   
No. I do not think so.

> 4)  is there any way to get an estimation of the "error" introduced by the
> reduction, so maybe you could try each filter and go with whichever one has
> the least error?
>   
Almost, in the sampling plugin you have a filter that measures the 
hausdorff distance between two meshes. that is probably the most used 
error measure in simplification.

> 5)  i haven't seen a good explanation for what the "quality threshold"
> actually does... how does changing this value affect the reduction?
>   
in the standard quadric means that edge collapsed that generate faces 
with bad aspect ratio, will be penalized.
In your case it did not matter a lot, these two meshes are incredibly 
horrible from a quality triangle point of view (a lot of very long 
skinny triangles, etc)

> 6)  it seems like the 'border preservation' works best on models that are
> not separated into different pieces... is this likely to be true?
>
>   
obviously if you want border preservation in objects that are composed 
mostly by border vertices  you do not simplify much.

Final Note.
Edge collapse based Simplification algorithms (all of them!) works well 
in the case of mesh composed by a large number of triangles uniformly 
distributed over the surface. If your mesh is already composed by a 
reasonable number of triangle it is difficult to remove a lot of them

In other words you cannot simplify a cube composed by 12 triangles, and 
similarly you cannot simplify a mesh composed by 100000 cubes without 
affecting in a significant way its appearance.

hope this helps a better understanding of the real capabilities of this 
class of algorithms.

cheers
p.

> all the best,
> imran
>
> On Sun, Jul 20, 2008 at 9:52 AM, skunkwerk <sku...@gm...> wrote:
>
>   
>> thanks paolo,
>>     i tried it again and the results look much better... though still
>> slightly worse performance than the regular quadric.  i'll do some more
>> testing.
>>
>> imran
>>
>>
>> On Wed, Jul 16, 2008 at 11:27 PM, Paolo Cignoni <pao...@is...>
>> wrote:
>>
>>     
>>>  Thanks Marco!
>>>
>>> We did it at the same time. :)
>>>
>>> Yes it was rather simple.
>>> There was a couple a small bugs that i have found when looking in the
>>> code,
>>> borders were not computed correctly (you used ff topo instead of VF topo)
>>> (and i did something wrong when restoring the border preserving markings)
>>>
>>> So let me commit my version later.
>>>
>>> p.
>>>
>>>
>>>
>>> Marco Pirosu wrote:
>>>
>>> so i actually implemented it.
>>>
>>> Then i think i just did copy and paste from the regular one, because i
>>> do not remember doing anything special.
>>>
>>> I don't know why their outcome differs so much.
>>>
>>> On 7/16/08, skunkwerk <sku...@gm...> <sku...@gm...> wrote:
>>>
>>>
>>>  thanks Marco,
>>>        Paolo, is this feature something we could ask Marco to implement?  I
>>> re-did my tests, restarting meshlab each time so as not to be affected by
>>> the bug you mentioned.  the 'preserve boundary' option does seem to work,
>>> but even without it selected the regular quadric preserves much more of the
>>> boundary than the quadric-with-texture does.
>>>
>>> i'm working on fixing the filter texture (texture atlas) plugin right now
>>>
>>> imran
>>>
>>> On Wed, Jul 16, 2008 at 1:55 PM, Marco Pirosu <pi...@gm...> <pi...@gm...> wrote:
>>>
>>>
>>>
>>>  the original quadric algorithm has been written by paolo cignoni. I
>>> think to remember i did not manage it because it wasn't part of the
>>> course project, even if the option is there (i think it has been put
>>> there in order to be uniform with the normal one). Also, if i remember
>>> well. the two algotithms work in a different way. The regular one is
>>> dedicated for 3D geometry, while my algorithm is based on the Garland
>>> multidimensional algorithm.
>>>
>>>
>>> On 7/16/08, skunkwerk <sku...@gm...> <sku...@gm...> wrote:
>>>
>>>
>>>  it looks like the extra options in the regular quadric filter make no
>>> visible difference (i tried reductions with them on and off) -
>>> especially
>>> the 'preserve boundaries' option that I thought would account for the
>>> different performance.
>>>
>>> but sure enough, the regular-quadric is performing better (dropping less
>>> geometry for the same number of output faces) than the quadric-texture
>>> filter.  any ideas why?
>>>
>>> imran
>>>
>>> On Wed, Jul 16, 2008 at 9:55 AM, skunkwerk <sku...@gm...> <sku...@gm...> wrote:
>>>
>>>
>>>
>>>  is that the source of the problem, you think?
>>> who wrote the regular quadric filter?
>>> would it be possible to copy-paste the code from the regular quadric
>>> filter
>>> that handles boundary preservation to the quadric-texture one?
>>>
>>> imran
>>>
>>>
>>> On Wed, Jul 16, 2008 at 4:19 AM, Marco Pirosu <pi...@gm...> <pi...@gm...> wrote:
>>>
>>>
>>>
>>>  i think it wasn't part of the course project, so i didn't implement
>>> it.
>>> It
>>> should be doable, through.
>>>
>>> On 7/16/08, skunkwerk <sku...@gm...> <sku...@gm...> wrote:
>>>
>>>
>>>
>>>  there seems to be a difference in the performance of the
>>> quadric-with-texture filter and the regular quadric.
>>>
>>> see these two files:www.akbars.net/classicford.saved.dae (regular quadric)www.akbars.net/classicford.savedtextured.dae (quadric-with-texture)
>>>
>>> the quadric-with-texture file has polygons missing from the wheels,
>>> if
>>> you look at them from the side.  is this supposed to happen?  they
>>>
>>>
>>>   were
>>>
>>>
>>>   both
>>> reduced to about ~50,000 polygons.
>>>
>>> Is there a reason the quadric-with-texture filter doesn't have a
>>> "preserve boundary" option?
>>>
>>> thanks,
>>> imran
>>>
>>>
>>>
>>>
>>>
>>>   -------------------------------------------------------------------------
>>>
>>>
>>>   This SF.Net email is sponsored by the Moblin Your Move Developer's
>>> challenge
>>> Build the coolest Linux based applications with Moblin SDK & win
>>> great
>>> prizes
>>> Grand prize is a trip for two to an Open Source event anywhere in the
>>> worldhttp://moblin-contest.org/redirect.php?banner_id=100&url=/
>>> _______________________________________________
>>> Meshlab-devel mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/meshlab-devel
>>>
>>>
>>>                              -------------------------------------------------------------------------
>>>
>>>
>>>   This SF.Net email is sponsored by the Moblin Your Move Developer's
>>> challenge
>>> Build the coolest Linux based applications with Moblin SDK & win great
>>> prizes
>>> Grand prize is a trip for two to an Open Source event anywhere in the
>>> worldhttp://moblin-contest.org/redirect.php?banner_id=100&url=/
>>> _______________________________________________
>>> Meshlab-devel mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/meshlab-devel
>>>
>>>
>>>               -------------------------------------------------------------------------
>>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>>> challenge
>>> Build the coolest Linux based applications with Moblin SDK & win great
>>> prizes
>>> Grand prize is a trip for two to an Open Source event anywhere in the
>>> worldhttp://moblin-contest.org/redirect.php?banner_id=100&url=/
>>> _______________________________________________
>>> Meshlab-devel mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/meshlab-devel
>>>
>>>        -------------------------------------------------------------------------
>>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
>>> Build the coolest Linux based applications with Moblin SDK & win great prizes
>>> Grand prize is a trip for two to an Open Source event anywhere in the worldhttp://moblin-contest.org/redirect.php?banner_id=100&url=/
>>> _______________________________________________
>>> Meshlab-devel mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/meshlab-devel
>>>
>>>
>>>
>>> --
>>> Paolo Cignoni  -- Senior Researcher
>>> Visual Computing Laboratory - ISTI - CNR http://vcg.isti.cnr.it/~cignoni <http://vcg.isti.cnr.it/%7Ecignoni>
>>>
>>> ISTI - CNR
>>> Via Moruzzi 1,
>>> 56124 Pisa
>>> ITALY
>>>
>>>
>>> -------------------------------------------------------------------------
>>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>>> challenge
>>> Build the coolest Linux based applications with Moblin SDK & win great
>>> prizes
>>> Grand prize is a trip for two to an Open Source event anywhere in the
>>> world
>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>> _______________________________________________
>>> Meshlab-devel mailing list
>>> Mes...@li...
>>> https://lists.sourceforge.net/lists/listinfo/meshlab-devel
>>>
>>>
>>>       
>
>   
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> Meshlab-devel mailing list
> Mes...@li...
> https://lists.sourceforge.net/lists/listinfo/meshlab-devel
>   


-- 
Paolo Cignoni  -- Senior Researcher
Visual Computing Laboratory - ISTI - CNR 
http://vcg.isti.cnr.it/~cignoni

ISTI - CNR 
Via Moruzzi 1,
56124 Pisa
ITALY