pradeep-pyro / tinynurbs

C++ library for NURBS curves and surfaces

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Enable custom vector type (not only from glm)

Flarkk opened this issue · comments

Hi there,

Happy to see this well written cpp NURBS library exists !
Although it's not featuring all major NURBS operations yet, I'm evaluating the opportunity to use it in a personal project.

First I would like to know if it would make sense I submit a modified version of tinynurbs allowing using an arbitrary vector type (for my use it would be boost::qvm vectors).
It would imply adding a VECTOR_T template parameter for most classes and functions, as well as writing vector back-end classes for vector interfaces that do not match with your implementation based on glm.

Any feedback from main contributors here is welcomed.

Best,
Flarkk

Hello, thanks for your interest.

I'd prefer not to make the codebase more complex with another dependency as it doesn't add much to the feature set.

I haven't used boost qvm but it seems to support interop with plain C arrays (http://boostorg.github.io/qvm/#_c_arrays). You could access the glm types used by tinynurbs as plain arrays using glm::value_ptr() function. There also appears to be a notion of view proxies (http://boostorg.github.io/qvm/#view_proxy) for interop with other types so I'd suggest exploiting these features rather than modifying tinynurbs for your use-case.

Hello,
And thanks for your response.
To be clear : my proposal was not to add a dependency, but rather to remove any (glm in this case). Anyone could then use tinynurbs with the vector type of its choice (provided it supports all required operations).

Ah I see, thanks for the clarification. I hope I'm not missing anything, but I still don't see a huge benefit in introducing that level of genericity.

There is no guarantee that different math libraries adhere to the same interface/concept e.g., Eigen uses methods, glm uses free functions. So writing those backend classes is going to result in some complexity.

Plus it is already quite easy to interop glm types with other libraries (without incurring unwanted copies) since all types are consistently in column-major order.

Thanks this makes sense !
I will consider again the option you suggest.