I ran into a surface that when unrolled was 33% smaller!:Bad_Unroll.3dm (35.5 KB)
Area is 172228.5814 sq millimeters (33.33 % ) smaller after unrolling
It is disturbing to find that Unrollsrf apparently still does not have the checks in place to ensure the result is within a certain tolerance. PLEASE make sure commands like this have proper meta checks and warn us users about it when things seems way off target.
I do not expect Unrollsrf to be 100% failproof as I guess that is not a realistic goal, nor do I want Unrollsrf to just fail in these type of situations. What I do expect is that a deviation of 33% in area is something the command will throw an alert on. Simply writing it to the commandline and expect us to catch it is too easy. Unrolling surfaces is a crucial part of my workflow and I need it to be reliable such that these obvious deviations are caught by Rhino.
Apart form the above I wonder how a planar surface input in Unrollsrf can come out this way. It seems to me too much of a mathematical approach is taken when a planar surfaces should be in basis just be laid flat on the XYplane and maybe slightly adjusted to fit adjacent edges when needed.
Maybe if a surface is planar within tolerance, rhino might just use the normal and orient from there to the z-axis. This way there is no calculation needed which could fail.
Hi Willem- but⌠doesnât that count as a check? It did warn you, and you saw the warning - that is what the area report is for. Do you mean you want a message box or something more âin your faceâ if the % difference is over a certain amount? How much?
Do you agree this unroll is way off target?
Does the developer agree?
If so it should have been caught.
I would indeed like a more in my face warning if Unroll is of by more than xx%.
There is a check already if a surface is unrollable in the first place, so there should also be a check if the result falls in tolerance. This result is obviously incorrect and Rhino should do something with it. Itâs not as easy as waving it off by a command line message.
May I suggest not just checking area, but corresppnding edge lengths as well. I know itâs not easy to determine a threshold, but there is one in place for checking âunrollabilityâ already, so some numbers for result checking should be âfindableâ. How about starting with 1%? Or another number coupled by or based on the initial threshold for unrollability.
Note that unrollsrf is a production critical tool not to think lightly of (IMO that is. )
Hi Willem- itâs just that⌠the âsystemâ appears to have worked perfectly in this case - the result was bad, and it was caught. Why then the alarm, I guess is my question.
We disagree that it was caught: the only reason I myself caught it was due to the oddly curved edges catching my eye. If the shape would have been more triangular I could have easily missed it.
Let alone when it would have been an automated batch of unrolls! IMO tools in Rhino should try to produce good results and obviously-incorrect results should raise a flag signaling the user. A regular commandline feed is for informing about non critical information.
Even a boolean that used double tolerance raises a dialog, might I then be informed likewise when a 33% deviation in Unroll occurs?
Ah, ok, so you did not see the command line feedback as the signal that there was a problem - I gathered from your post that this is what had caught your eye, which seemed according to plan.
Sorry for the confusion, indeed the initial cause of concern was the curved edges in the result.
To be honest even if it would have been the command line that caught me, I think it is alarming a 33% deviation being passed as any other deviation.
I absolutely agree, and I will even go so far as to say that the command line should never be used for any warning what so ever. It is not a place where (all the) people look. If it is a warning then STOP the user from what he is using. The importance here is that the user costs XXX dollars pr hour, the fault can cost many hours, even cause trouble down the production line, so I would say that as a rule of thumb for V6 is to rewrite all commands so all warnings pop up in your face. It is like the discussion we had regarding shelling, if it so much better now when it pops up a warning.
Although I keep my eye glued to the command line when unrolling for exactly the reasons Pascal raised, I still think this should pop up as a warning.
The same goes for other warnings of failure. In a busy work flow on a deadline it would be too easy for one odd failure to slip through to become an expensive production mistake.
I think that some has to be considered when users script those commands and deliberately suppress command line feedback. UnrollSrf (as a regular command) has been used in many scripts and a message box would probably render those scripts useless.
On the other side, i would appreciate for the scriptable versions of UnrollSurface in vbScript and Python to be able to return the deviation which usually goes to the commandline so it is still possible to halt on a user definable deviation or just ignore it.
Error cases like the one posted by Willem need to be fixed instead of reporting the deviation. If the part is planar within user tolerance there is no deviation, the part could by layed out flat.
Just a quick idea: Flash the unrolled surface to indicate a warning. That way no message box is needed.
In either case, I cannot understand how this is not a bug. If UnrollSrf cannot deal with coinciding control points, then it should say so instead of creating a random surface.
but that is a different problem, I say, than what to do when, inevitably, the result is not as expected. Flashing the suspect output might help, but I suspect it is not enough- possibly selecting suspect results would be a good idea, to go along with a command line report, but I am getting the idea here that the potential cost of letting something like this go by at all is too high and the users in this thread would prefer to be interruptedâŚ
