NURBS derivatives about nurbs-python HOT 15 CLOSED

Just a comment guys as I am poking around the nurbs landscape and I noticed this post with data.

I tried the data from your example in 3 other systems:

http://nurbscalculator.in and tinynurbs (C++ header only) and they both give a Wankel engine kind of 3 sided rotor - that is if I am doing it right.

Also tried in verb and it gives your circle. The verb test was done in javascript.

from nurbs-python.

6.x-dev is still under development, some new features are not completed in the way I indented and it is not ready for a release. I am thinking of an alpha release at the end of this month and a roadmap for the future development.

Comments are always welcome but it might be too early for PRs.

Edit: I'd be happy if you could open a new ticket for the new topics that you would like to discuss.

from nurbs-python.

I think there is a problem with the weights (or weight assignments corresponding to the control points). Would you please provide the code that generates this figure?

Edit: I understand the problem. The problem with the NURBS derivative geometries generated like this is the equation/algorithm used to find the control points of the derivative curve/surface not working with the weights. There is a high possibility to get divide by zero errors along with the weights outside the range of (0, 1] half open interval. I guess you will be able to find a reference in operations.derivative_curve function and the related commits.

As I stated earlier in some other issue tickets, The NURBS Book has so many hard assumptions in the provided algorithms. Some of them are handled but some of them are left to users using the algorithms in the correct way. I wanted to give users as much flexibility as I could but it is a black hole: with so many limitations, there would be no research but perfectly perfect working code.

(also not convinced the 7pt construction in geomdl.shapes is correct after my back of the envelope calculation for a unit circle - it looks isosceles rather than equilateral?)

This is a visualization issue, specifically how matplotlib renders the data points. That's why I had to introduce plotly and vtk-based modules. I like vtk better than the others but vtk-based visualization module still needs more improvements, as it uses minimal amount of features included in the VTK.

from nurbs-python.

@cshorler I just forgot to mention the Evaluator interface (ref). It allows using different algorithms for computing points and derivatives with minimal changes to the base classes. I'd suggest implementing a new evaluator class for any new/updated algorithms.

from nurbs-python.

The rendering in matplotlib looks okay to me, it's the control point coordinates that look wrong to me - the triangle sides are not of equal length.

w.r.t. Derivatives it would be good for me to better understand why this derivatives issues occurs ... so I will try for a deeper understanding and explore alternate evaluator implementations.

For reference here's similar code to what was used to generate the picture - it seems I didn't save / stash the original! Do you want me to attempt to remove the numpy dependency from VisMPL?

import math
import matplotlib.pyplot as plt
from geomdl import NURBS
from geomdl.linalg import linspace
r = 1.
a, h = 3. * r / math.sqrt(3.), 1.5 * r
crv = NURBS.Curve()
crv.degree = 2
crv.ctrlpts = [(0., -r), (-a,-r), (-a/2,-r+h), (0., 2*h-r), (a/2, -r+h), (a, -r), (0., -r)]
crv.knotvector = [0.,0.,0., 1./3, 1./3, 2./3, 2./3, 1.,1.,1.]
crv.weights[1::2] = [0.5, 0.5, 0.5]
derpts = [crv.derivatives(u, order=1) for u in linspace(0., 1., 50)]
legend_proxy, legend_names = [], []
fig = plt.figure(figsize=(10, 8), dpi=96)
ax = fig.gca()

cpplot, = plt.plot(*zip(*crv.ctrlpts), color='blue', linestyle='-.', marker='o')
legend_proxy.append(cpplot)
legend_names.append('control points')

curveplt, = plt.plot(*zip(*(t[0] for t in derpts)), color='black', linestyle='-')
legend_proxy.append(curveplt)
legend_names.append('curve')

derplt, = plt.plot(*zip(*(t[1] for t in derpts)), color='green', linestyle='-', marker='+')
legend_proxy.append(derplt)
legend_names.append('1st derivative')

plt.legend(legend_proxy, legend_names)
ax.set_aspect('equal')
ax.set_xlabel('x')
ax.set_ylabel('y')
plt.show()

from nurbs-python.

Thank you for sharing the code @cshorler. I'll test it in a couple of days.

Do you want me to attempt to remove the numpy dependency from VisMPL?

I tried that once but it seems like an impossible job :) Pretty much all the visualization libraries that I used in Python requires Numpy in some way. No need to worry about that.

Just a note for myself: I need move vis.py to visualization package to fix compatibility/dependency issues with Cython-compiled version of geomdl.

from nurbs-python.

@ted-dgk thank you so much for the tests! It has been real busy for the last couple of months, I couldn't find time to test this issue thoroughly.

There was another issue (I believe it was #35) about computing the derivatives of a NURBS circle. I remember checking the exact same thing with the NURBS toolbox while I was trying to find a fix. I think there were some notes on the source code of the NURBS toolbox.

from nurbs-python.

from nurbs-python.

Also note very first point in this issue about the circle construction - I believe this is also a bug.

@cshorler, you mean the geomdl.shapes issue?

from nurbs-python.

from nurbs-python.

@cshorler thanks. Let me open an issue on the geomdl-shapes issue tracker on that

from nurbs-python.

from nurbs-python.

@orbingol

I started to explore the 6.x-dev branch a little bit, some interesting changes / explorations.

some initial comments on files I'm also likely to submit PR on where I might revert locally before making PR.

• geomdl/base.py

  • I guess the introduction of GeomdlFloat is a test to manage fp roundoff issues, I'm not sure the way this is implemented is a good design decision w.r.t. fp accuracy vs. needs.

• geomdl/abstract.py -

  • the SplineGeometry degree property was changed in type for curves, probably this needs to be abstract at that level and concrete at a lower level in the inheritance hierarchy so it can be basic type for curve and list type for surfaces and others.

• geomdl/control_points.py -

  • CPManager seems to be used more widely. If the aim is to associate data to control points - some of the changes I'll propose for this issue might be interesting as they will simplify how this can be implemented (I think - use case not yet completely understood).

from nurbs-python.

I assumed this, okay will do

from nurbs-python.

I assumed this, okay will do

@cshorler thanks!

from nurbs-python.