Am 24.07.2016 um 19:19 schrieb Le_Forgeron:
> Le 24/07/2016 18:32, clipka a écrit :
>> Am 24.07.2016 um 18:10 schrieb Bald Eagle:
>>> clipka <ano### [at] anonymousorg> wrote:
>>>
>>>>> Any suggestion of name for that container ?
>>>>
>>>> "nurbs_mesh"?
>>>
>>> If it's a closed 3d shape composed of NURBS mesh(es), then maybe "envelope" to
>>> differentiate and disambiguate from a (simple) open mesh?
>>
>> Sounds far too vague and unrelated. Besides, I think it would be smart
>> to also support non-closed NURBS patch meshes, just like mesh also
>> supports non-closed triangle meshes.
>>
> 
> "package", "bundle", "parcel", "lot", "bunch" ?????
> 
> On the same way as mesh supports flat triangle and smooth triangle,
> I do not see why the "object" holding nurbs couldn't also hold other 2D finite
primitives.
> To the risk of getting another (bad & slow) kind of mesh (as a collection of
triangles).

I presume that the `nurbs_mesh` object's data structure and algorithms
would be optimized for nurbs patches, just like the `mesh` object's are
optimized for triangles.

Both triangle meshes and NURBS-based meshes have the property that any
one of them can be used to (approximately) represent arbitrary shapes.
It makes sense to support both, because each has its own unique
advantages and disadvantages, but any single object can be modelled
using just one of the two -- so it makes sense to design not just one
container to support both approaches, but to design different
containers, each optimized to support just one of them.

And even if the first implementation would be non-optimized and could
handle other 2D elements as well, it still makes sense to limit it to
NURBS patches, so that optimizations can easily be implemented in the
future.


As for having a generic container to combine surface-only primitives
into an object with a defined volume, I think that would be nice to have
as well, but that would be yet another thing (at least at the SDL level;
the NURBS-specific construct could initially be implemented by means of
such a more generic container, but as mentioned before, it would make
sense to provide a dedicated SDL syntax, so that future optimizations
are possible).

Post a reply to this message