Re: [K3d-development] Mesh data structures

[Timothy M. S. <ts...@k-...>]

Bart Janssens wrote:

>> * Un-deprecate the k3d::legacy::mesh data structures, and allow them to
>> be used in plugins wherever they simplify the implementation.  Pros:
>> they're very mature and already have conversions to/from k3d::mesh.
>> This is where I would have steered Ian :)
> 
> I'd leave these in the legacy namespace. It's true the old structure
> is easy to use, but it's also used in a lot of legacy plugins that
> could benefit greatly from using arrays directly. Think of the
> ExtrudeFaces plugin, for example, which should be upgraded to use aray
> meshes at least for changes to parameters that don't affect topology,
> like modification to the extrusion length. This would greatly improve
> the interactivity on complex meshes. Leaving the old structure in the
> legacy namespace makes plugins that still need conversion easier to
> detect.

>> * Incorporate some other split-edge structures into the SDK, such as
>> CGAL.  Possible benefits would be that CGAL appears to have greater
>> mathematical rigor than K-3D.  The downside would be the additional
>> overhead of incorporating CGAL into the K-3D tree.
> 
> We could allow CGAL::Polyhedron_3 for topology changes. The advantage
> is that the structure is very flexible, as connectivity is stored in
> all directions: edges point to their faces, faces point to their
> edges, vertices point to their edges and facets, edges point to both
> predecessor and successor, ... In addition, the Euler operations are
> available under CGAL, which saves us the work of implementing them.
> 
> The disadvantage of using all this functionality is that we have the
> overhead of converting to the CGAL structure. In my opinion, this
> should not be a huge problem, since topology changing operations are
> relatively expensive as it is, and any cached data is bound to be
> flushed, which may dwarf the conversion cost. We'll have to do some
> benchmarks to verify this, of course.

Something that hadn't occurred to me when I posted originally is that 
all of the existing modifiers are going to require modification, 
especially the "topological" ones, because they currently don't maintain 
the user data, which is a big bug.  If *I* were doing that work I'd 
probably bite the bullet and use the array-based meshes, so it may be moot.

I thought that CGAL::Polyhedron_3 doesn't support holes in faces?

Cheers,
Tim