UnrollSrf is a very handy command but the labelled edges only serve as an on-screen legend and don’t really help with output for production, unless you put in a lot of legwork.
I’m working with a fabricator who wants sheet metal water jet cut and welded in a particular configuration.
He works with .dxf so the dots aren’t much use, especially when converting them to text.
When choosing different ConvertDots options for alignment it returns the same output?
Hi Andy - So the labels in UnrollSrf would optionally be text and not dots, and oriented according to the edge associated with them, do I have that right?
My guess of the moment is that would not happen for V6, but as so often, it might be possible to make some kind of scripted thing to process the dots after the fact.
Yeah, that’s about it. If you consider what the command is trying to achieve, basically labelling edges for another process. Most probably for reassembly after printing something on paper or laser cutting. It falls short somewhat as the information resides outside of each face that has been unrolled - all the codes would be missing from the part after it’s cut out without a lot of extra jiggery pokery.
It’s not so much the text which is important so much as where the dots are located. They don’t necessarily have to be orientated to match the edge but rather located centrally and inbound of each edge.
Converting the dots afterwards isn’t such a chore.
Hi Andy - I see, so the minimum, for you, would be to make sure the dots are inside the face that has the edge it is marking, right, so that when converted to text it’s on the face? Here’s my thought of the moment - I can see where in some cases this could lead to some ambiguity as to what edge belongs to what label and vice versa - if the dot is far enough inboard (remember it has no actual dimension) to get the converted text fully inboard of the surface edges - problematic in itself - then it might be farther from its edge than another edge. If I am not misunderstanding things… See what I mean? So there would be weird cases, and/or a lot of user input needed. I think it might make more sense to come up with some kind of post-process - feel free to push back if I am not grokking your idea but that is what it looks like to me…
I understand what you’re saying, I think, but I don’t grasp the scripting side of it so maybe my understanding is a little too linear. Apologies if it’s not so straight forward.
If you take a cube, for example. Each edge is labelled and each extracted face has a text dot with a corresponding number. The dot is located on the edge of the planar face. The request would mean that the dot is brought inboard of that edge, perpendicular by a set distance. That would mean that when a shape was printed and then cut out it would still have the dot on the part you’d cut out… Not just one half of it along the outer edge.
Converting it to text isn’t that much of a problem as the convert dot command takes care of that.
The convert dot H and V alignment doesn’t move things in a group very well. Rather than center or top it could be inboard or outboard?
I was thinking a combination of those two command would create something more user friendly. Outputting the dots/text to another layer would make it easier to assign something to an etching layer rather than a full cut etc.
As with most things I come across something during a bespoke project which I might not use again for a while but feel it could be refined a little to help in the future. It’s not a day to day command in this instance.
Hi Andy -
Yeah - that is fine on a cube, but it is not hard to imagine cases where the exact distance inboard becomes critical for correctly understanding the result - say on a long and very skinny rectangle - that is the stopper for me at the moment…
How does UnrollSrf mark the edges and knows which edge is which when unrolled?
Can a data be attached to a surface edge in R6, like attribute data can be attached to an object?
So it’s preserved when unrolled and can be pulled. This way we can “program” edge conditions on the geometry right in the model.
I’m not sure what the difference would be? An edge is an edge… If it has 12 edges or 128 edges it would still be the same outcome, no?
So long as the command works as it does now the other option would be to move the dot closer to the middle of the part, keeping it central to each edge but them moved inward by a factor. Inward being inside of the edge and perpendicular.
Well, what I’m thinking is that there could too easily be cases where backing off some distance from one edge will bring the dot closer to one or more other edges and cause confusion.
Yeah I get that but if the edge is 100mm long and the offset is 20mm with a text dot it shouldn’t matter when zooming in? it’s just a case of converting the text to the right height when done?
I think in some instances it may foul but nine times out of ten it would be OK?
Better that than having to do them all by hand… I’d rather be vigilant and only have to make one manual change.
Nine times out of ten = jobs/projects not each time I ran the command. If you consider it purely for CNC either wood, metal or plastic sheet materials it’s unlikely you’re going to be working at such scales where small text overshoots and it becomes confusing, unless you’re a model maker and making something, say for an architectural model or a tiny ship hull.
I’d think that anything on an 8x4’ sheet wouldn’t have that issue?
HI Andy - here’s what I see as the possible problem - maybe I am just missing part or a step of the scenario you have in mind -
I unroll a narrow strip of material - a dot is offset from the edges so that on the long sides, each dot’s location is closer, in actual 3d distance, to the opposite edge than it is to the edge it is meant to be labeling. Converting a dot to text of any size will use that location - how will I know that the edges are incorrectly labeled? I think that situation cannot be allowed to occur using a built-in Rhino process that all users are likely to encounter. Does that make sense?
I see an implicit option where the text bottom is always towards the labelled edge. Or an explicit option where an additional line comes perpendicular from the edge like a promt type leader with the label adhered like a flag…
On my phone so no fancy artwork…
Edit : if the labels would start a little further (eg r
Text height ) from the mid of the edge they would not interfere on most thin strips
I guess you’d use the command as it is and not offset the dots in that instance?
If I have a long thin strip like you’re suggesting I don’t think there would be much use for it for CNC etc. If you consider it as a production tool/command and work within the parameters of standard CNC machine or say a laser cut part - anything that would struggle on screen would probably struggle in reality.
Using a 6mm cutter on MDF or ply for would need one form of demarcation and using the width of a laser on a small piece of acrylic would need another. The text could be scaled accordingly as an after thought with the convert dot command.
If the part was 10mm wide the offset could be 2mm and the text could be 1mm tall. I’d still be able to print that out and knife it out of card or paper. I’d have to change the text size.
At this point in time I’m really only interested in getting the text dot offset by a value. Anything after that is a bonus.
But, you see how it gets complicated - you’d need to first, label with text not dots, and then ask for size, and then, presumably a distance, and a font, and figure out the orientation, which might help in the scenario I mentioned but might still also result in incorrect-appearing labels… so my feeling is, at the moment, and the reason I’m resistant to a change in UnrollSrf, is that I’m leery of introducing all this complication into the Rhino command and end up with an invitation to confusion. I’d prefer to make it a post process.
Yes I agree 100% this should be post processing.
And best with an "unofficial " script or plug in. It’s no trivial task to create such annotations with an acceptable failure rate.
