"estimated arc length based on summing the individual lengths of the line segments computed with computeVertices(int)."
...which is not clear - do these vertices have to be included in the spline manually before calling getEstimatedArcLength()? Or does the computeVertices() automatically include the vertices in the spline?
I know that the best answer is experiment, but for some reason I cannot do it right now.
Hi noncom, can you please advice how to phrase it better, if the docs are not clear in your opinion? "estimated arc length based on summing the individual lengths of the line segments computed with computeVertices(int)."
You do need to call computeVertices() first, because that's where you really set the working "precision" of the spline and the result of that function is both returned to you, but also cached internally... (i.e. for getEstimatedArcLength()). So the order of procedure is:
Hi! Well, maybe it's just me, but the following two advices as you say:
1) For comuteVertices() say explicitly that the results are cached and used in the following methods: 'method_enumeration_here' .
2) In the docs of methods that depend on it, you may also explain what will happen if I do not call computeVertices() anywhere before like 'If you do not call the computeVertices() method before this one, the results will be...'. OR something like 'For this method to return a meaningful result, the computeVertices() must be called first, setting the segmentation precision'....
Well that's at least what I can think of. Maybe you could phrase it better)
Also, another question - as far as I understand, the smaller the segments, resulted from computeVertices() are, the higher is the precision of the getEstimatedArcLength() since they repeat the actual curve more closely?
Is this really surprising? This class has always been stateful since it also stores the original control points (which can be added one by one). The Spline2D is an "abstract" curve until you ask it to produce a number of points/samples (and even beyond that point). The only methods depending on a previous call to computeVertices() are getDecimatedVertices() and getEstimatedArcLength(), but both of them have meanwhile been re-homed into the more generic LineStrip2D/3D classes for better re-use and also to make it explicit that these functions operate on interconnected line segments.
So from v0021 onwards, you'll have to do something like this to get the arc length:
Me too and I'm very tempted to adopt immutability wherever possible... would make so many things much easier, but it's not as straightforward to do without breaking everything. Would also need something like Clojure's persistent collections to remain efficient instead of cloning objects en mass everywhere... that immu-switch is on the TODO list! :)
What about encapsulating the thing into the library, turning this into the following, overriding the method:
Spline2D s=new Spline2D();
Though it may be not as explicit as the full variant, and also i think it is not very logical.. but libraries are libraries because they deliver me from all these things... don't know.. both variants seem strange)))
The main reason for the move of that function into the LineStrip class was because the latter is much more general. You can estimate the arc length of any list of interconnected points, not just splines. So yes, I could have kept an overwritten/wrapper version in Spline2D/3D, but then would argue it's better to have that functionality only available in one place and keep the API streamlined. Thinking about it, the real culprit seems to be computeVertices() which should really be deprecated & renamed into toLineStrip() and return an instance of which. This would also fit better with the other common conversion patterns (e.g. to3D(), toMesh(), toPolygon2D() etc.)
toLineStrip makes a lot of sense to me. Perhaps if "getEstimatedArcLength" was called "getStripLength" or just "getLength"? getDecimatedVertices should still live in Spline2D to maintain accuracy IMHO.
Yes, the 'to...' paradigm seems more organic. I also agree with Hellochar that the method name might be simplified. However, as far as I understand, the 'estimated' word still should be in place because the length is not a real absolute mathematical length, but an estimation, based on the user set approximation and might differ from the absolute length quite well (i might be wrong in the understanding here).
However, whether the getDecimatedVectices() should belong to Spline2D or LineStrip2D is a good question. I believe that the source of the question is the lack of a strict definition of what objects do Spline2D and LineStrip2D describe. From the JavaDoc I can understand that Spline2D describes a generic spline curve which is ok, but I cannot tell what is LineStrip2D, since, it is probably new to 0021 and is not present in the JavaDoc. The source code here:
did not make it clear also. I believe that it is a work in progress and is in it's process of establishment. Therefore it is importatnt to outline the essense of these entities, their relations and usage targets so as to be able to stick to it when it is required to make such decisions as we discuss here.
I am only beginning with toxiclibs but it is a great lib! I wish it to become better and better.
"There are times when amount of inherit chaos in a created system rises to an extent that renders the system illogical and, as a consequence, harder to understand and fruitfully interact with. Usually, the first attempts to swap and change minor things here and there trying to recall what the lost order might look like, do not decrease the degree of disorganization. Then, after a while, it is realized that a greater change is required. A change to the very way the system is seen by it's creator. An appeal to a higher order. One of the most extatic experiences known to us. The change first occurs in the creator and his perception and then he projects the new vision on his creation. This is seen as life. Blessed are those who are conscious of these movements inside them."
Leave a comment on noncom's reply
Change topic type
Link this topic
Provide the permalink of a topic that is related to this topic