viewtopic.php?f=9&t=3914&start=60#p52330)

A while ago when working on the WebGL exporter I found that the docstring of Wire.discretize was inconsistent with its implementation. The same applies to Curves and Edges. This function can either be called with an integer or with a float. If called with an integer, this is interpreted as the number of vertices for the approximation. The docstring claims that a float is interpreted as the deflection of the discretization. The implementation however produces points that are uniformly spaced.

There is code out there that relies on this behaviour (viewtopic.php?f=9&t=3914&start=70#p52464)

I see multiple possibilities how to proceed:

- Leave discretize as it is, adjust its docstring and potentially add a new function discretize_deflection for the deflection discretization. This keeps compatibility and exposes deflection discretizations.
- Change discretize, leave docstring as it is. This breaks compatibility for those who relied on the current behaviour of discretize. Getting uniform discretizations of curves can still be done manually rather easily:
or (without dependency on numpy)
Code: Select all

`[curve.value(u) for u in np.linspace(curve.FirstParameter,curve.Lastparameter,n_points)]`

while doing discretizations with uniform deflection is much more difficult.Code: Select all

`du = (curve.LastParameter-curve.FirstParameter)/(n_points-1) points = [] for i in range(n_points): points.append(curve.value(curve.LastParameter+i*du))`

- Change discretize to do both things, e.g. discretize(int or float,bool=false), where discretize(int) and discretize(float) give the current behaviour, and discretize(float,true) discretizes with constant deflection. This keeps compatibility and allows to handle rounded edges in WebGL, but is not really nice, as the bool parameter only applies to calls where the first parameter is a float.