are there any plans to support NURBS curves and surfaces?
Sometime in the distant future? Or the answer is definitely NO?
"Extending the Library" text talks about new formats, not new kinds of faces.
Since there are hints about 3.0 release coming soon, it may be a right time to introduce new members
into aiMesh, even if rewriting importers/exporters/viewers will be done much later.
the answer is definitely not 'no', but we need a proposal how the data structure could look like.
One thing to consider is that we don't have many formats that support NURBS surfaces - I think Collada, Ifc and Blend are the only candidates at this time.
It's imho a topic that is worth talking about, maybe someone else reading this forums has a opinion on this, too (or someone post up on assimp-discussions).
The BSP- and the OBJ-format supports something similar, too. Maybe it is a good idea to add this feature.
If we find a data structure to represent all of the options, it might be a good idea. Of course we'd need an accompanying Post Processing Step to bake them into triangles for those who do not want to use it.
> If we find a data structure to represent all of the options, it might be a good idea.
> Of course we'd need an accompanying Post Processing Step to bake them into triangles for those who do not want to use it.
That is a lot of work (both thinking and coding) to do.
May be piecemeal approach is better -
create some "aiPrivateObject" base class,
that holds an class id and virtual destructor.
The derived classes will hold format-specific data.
If a hook to add such objects is added, it will be possible to
add NURBS support by writing an importer/exporter, without patching Assimp
(so it will be possible to use system-wide Assimp instead of a private copy).
My plans to extend some exporters with NURBS support are just plans,
but once Assimp 3 is released it will be too late to include that hook.
After some time, after NURBS support is implemented in format-specific ways,
it will be possible to create common group of NURBS and, may be, Platonic objects
to be implemented in any exporter/importer.
All of the above is at wishful thinking level, "it'd be nice to have" before ver 3 API/ABI is cast in stone.
I think defining some hooks for user-specific extensions is a good idea. If you want to use a special feature of a loader which is not part of the assimp-data-structure you can use this, too.
What about openNurbs? http://www.opennurbs.org/
There are NURBS in STEP also. www.stepcode.org can code generate an importer/exporter for EXPRESS schemas like IFC and STEP AP's. STEP AP242 has a new tessellated format as well as other updates over the legacy AP214 and AP203.