@menno Here you go Menno, not the same curve but showing similar errors…
Elmo.3dm (44.3 KB)
What I’m seeing while in Elmo (note how the deviation isn’t being measured normal to the original curve)…
…and this is what I’m seeing when I run CrvDeviation…
P.S. I’d really like pretty polygon back again too!
I’ve reported both issues
https://mcneel.myjetbrains.com/youtrack/issue/RH-85265/
https://mcneel.myjetbrains.com/youtrack/issue/RH-85266
Very useful almost always have to edit fonts to make them work
I am missing pretty polygon as well.
It also started outputting non-periodic curves:
ElmoNonPeriodic.3dm (43.1 KB)
_Elmo PointCount=12 Degree=3 Method=Rhino9 MatchTangents=No Smoothing=Medium SplitAtKinks=No DeleteInputCurve=No OutputLayer=Current
I’ve fixed the periodic bug Eric reported.
The original (python based) Elmo command’s PrettyPolygon option simply toggled the visibility of two options:
EqualizeSegmentsStrength = None/Low/Medium/High
SmoothingStrength = None/Low/Medium/High
The newer Elmo command combined these two options into a single option
Smoothing = None/Low/Medium/High
If possible, I’d like to see some examples of what the two original options accomplished that the newer single option does not so that I can make appropriate adjustments to the new code. Do you have some sample files I could look at along with the original settings you used to get the results you liked?
The original (python based) command is still available by typing ElmoPy so that it’s easy to make accurate comparisons between it and the new version that is run by typing Elmo.
I’ll fix the deviation display in the near future.
Thank you for reporting the bugs.
@dalelear Thanks Dale. I don’t have any examples kept but will have plenty as I do more work. Will send through once I’ve got a few to show.
From memory, the new output was very close to what we have in R8.
Also from memory, the equalise seg strength was the most useful with smoothing either being set to none/low. But I’ll confirm in the near future.
But why combine these settings into one even coarser setting? I also feel I needed more control over these two variables with slider controls, not less. Or was the output getting just too good?! 
The reason for changing the “fairing” calculation was to make the results scale independent and to experiment with a simpler interface at this early point in the release cycle.
This phase in the release cycle is the most forgiving where we can add/remove/change to get a better idea of what will work for y’all. It’s nearly impossible to guess what’s best without trying it out in public.
The feedback you give in this forum is incredibly valuable.
@dalelear Dale, my first set of curves in the file below…
Elmo1.3dm (61.6 KB)
It looks like the actual problem isn’t the curve that the new Elmo produces but the deviation reporting in some circumstances. Hopefully the labels and layers in this model will explain the results, let me know if it’s not clear.
@dalelear Dale, an example of where old elmo does way better than new elmo…
Elmo2.3dm (46.8 KB)
Proof that things were better in the olden days…
hi @Gijs can you add elmo api to c# RhinoCommon please ?
@Rh-3d-p there is currently Curve.RebuildElmo() which is calling the python version. The c++ version will undoubtedly be callable from RhinoCommon once we start working on a dialog for it.
I would advise not to use that function. It is temporary and will be renamed/removed
@mcvltd fyi: I made a new YT with the file you sent, comparing different levels of smoothing here:
RH-85516 Elmo vs ElmoPy 2
@dalelear I will try to get you some concrete examples this week. The use case to separate equalize from smoothing is targets for FlowSrf.
When mapping from a planar base to a target with inconsistent CV/knot spacing, I’ll manually create a cleaner surface over a desired area. I’m trying to get a ‘pretty polygon’ domain space while holding as much tolerance as I can. Smoothing is very much unwanted.
Creating good flow targets is a high-priority, daily pain point for a lot of us.
