CGAL users discussion list

[Rob Patro <>]

Fernando,

  I see what you are suggesting.  Very clever indeed!  My only question
is on the ability to *throw away* M1.  Since the decimation works on the
actual surface, with vertex and halfedge handles which point to the
actual surface, won't you lose M0 during the decimation process?  Is
there a way to run the simplification forward and to collect handles (as
you did in your pseudo code) which reference the original, as opposed to
simplified, mesh?

Thanks,
Rob


Fernando Cacciola wrote:
> Hello Rob,
> 
>> Fernando,
>>
>>  In order to split the vertex, v1 back into v1 and v0, we need
>> to call split_vertex( vy0_v1, vx0_v1 ).  However, the problem is that
>> the edge collapse (not General_case_step::do, but the edge collapse
>> called directly after Visitor::OnCollapsing) will alter these edges as
>> they are obtained prior to the collapse.
> 
> You are right in that the real edge collapse won't be reversible with a
> call to step::undo, that's why in my sketch there is a step::do method
> as well. What I had in mind was that you would run the algorithm with
> the PM visitor to collect the sequence of steps in decimating M0 to M1,
> but then, in the context of the PM, discard M1 and decimate *from M0*
> once again, but this time just executing step::do in order.
> 
> This way, each step::do being the one doing the actual changes (instead
> of the halfedge_collapse funtion used in the algorithm) knows exactly
> what elements have been invalidated, so the corresponding step::undo can
> operate specifically on those elements with are known to be still valid
> after a previous call to step::do.
> 
> Even if I'm missing something and there are is still need to denote the
> mesh elements in a more stable way, or to fixup handles in the remaning
> steps, or any such thing, you now has complete control since changes are
> now applied by these step:do and step::undo methods, not by the
> halfedge_collapse function the algorithm used first.
> 
> I know this is suboptimal since the decimation has to be done twice and
> goes totally astray with the current simplification code, but support
> for progressive meshes where not considered during the algorithm design,
> so this is as ugly as a workaround can be.
> Yet off the top of my head it should work.
> Consider that the algorithm does much more than just collapsing edges:
> it needs to decide which ones, which is the bulk of the problem, so
> there is still gain in calling the algorithm even if afterwards you end
> up doing the collapses "by hand" and once again.
> 
> 
> Best
> 
> Fernando Cacciola
> 
> www.geometryfactory.com
>