Closed kroozo closed 10 months ago
Hi, @kroozo!
Thank you for your comments! You can split or join issues as you see fit, this is just a hobby project, not a job, no need to be formal.
About your points:
Un-needed lines. I do my modeling in Blender. There is an option in Blender named "Dissolve edges" that will make the edge disappear for the purposes of modelling and exporting. That said, since Papercraft 2.1 there is an option "Document properties / Model / Folds / Hidden fold angle" that you can set to hide edges less than a given angle. You can still split them, but if they are joint, then they will be invisible. That is a global option, you cannot apply that to single edges yet.
Printable edge IDs. This has been requested before, and I think that it has to be done. I hesitated before because I didn't want to meddle with text, overlaps, fonts, styles, sizes, etc. Do you think it would be useful to show them on the preview? Or would it be enough just to print them on the PDF?
Fold in the SVG. But this is already done, I think. The lines are in the SVG in separated layers, so that you can print one layer and use the other two for your cutting machine (or something like that, I don't have a cutting machine). The tricky thing is that these layers are hidden by default, maybe that's why you didn't notice those? Or would you like something different?
Removing individual flaps. Ah, when I don't like a flap, I leave it there and then when cutting I just cut it off. I guess that may be inconvenient if you have a cutting machine. I guess we could have a new mechanism when in "Tab mode" that hides it, maybe by holding the "shift" key? The "shift" key already does something special in "Face mode" and in "Edge mode", but not in "Tab mode".
Removing/Hiding faces. Again, from Blender that is trivial. But having the unwanted faces all together with all the unwanted folds, and moving them out of the paper seems like a good enough solution. They are still shown in the 3D model, however. The problem with actually hiding them is: if you change your mind how do you get them back?
Some of these things could be solved by adding a menu to edit the "edge properties" separated for each edge, but I'm hesitant to add those. Currently all options are global, so "what you see is what there is" (WYSIWTI?), there is no hidden information anywhere. Adding per-edge options could mess that model. Imagine that you change your global tab-width and suddenly some tabs will not update because there is some option somewhere that overrides it. I guess that we could design a good UI around edge/face options, but I'm not sure how... Using color codes may not play nice with background textures.
About helping with testing that will be great. Can you tell me what Operating System you are using? Also, are you able to build the version yourself or would you need testing builds (no problem either way)?
I think I will prioritize items 2 and 4... stay tuned!
Thank you for your comments! You can split or join issues as you see fit, this is just a hobby project, not a job, no need to be formal.
Yep, exactly why it should be how its comfortable for you ;)
- Un-needed lines. I do my modeling in Blender. There is an option in Blender named "Dissolve edges" that will make the edge disappear for the purposes of modelling and exporting. That said, since Papercraft 2.1 there is an option "Document properties / Model / Folds / Hidden fold angle" that you can set to hide edges less than a given angle. You can still split them, but if they are joint, then they will be invisible. That is a global option, you cannot apply that to single edges yet.
Ah, sorry, I must be blind, and I even read through docs. This helps a lot. I don't really get the number through. I can see that a perfectly flat surface is 0, and others seem to be the external angle of the fold (to the line). Is this calculated by 180-internal angle?
And yes, single edge application would still be welcome, but it's much less of an issue.
- Printable edge IDs. This has been requested before, and I think that it has to be done. I hesitated before because I didn't want to meddle with text, overlaps, fonts, styles, sizes, etc.
I understand that wholeheartedly. :)
Do you think it would be useful to show them on the preview? Or would it be enough just to print them on the PDF?
My first instinct would be that they just clutter the preview. If you plan to make the font customizable it might make sense, but then you'd need a knob somewhere to hide them. If this was work, I'd say the MVP is a preset font, and not visible on the preview.
They are however needed on the png and svg output as well, on a separate layer on the svg.
But now I just realized that printing registration marks would also help, otherwise you need to plot with a pen :)
- Fold in the SVG. But this is already done, I think. The lines are in the SVG in separated layers, so that you can print one layer and use the other two for your cutting machine (or something like that, I don't have a cutting machine). The tricky thing is that these layers are hidden by default, maybe that's why you didn't notice those? Or would you like something different?
Yes, this is good, and that is why I said its easy to do post processing. Basically what I was looking for is customizing these lines to make them dashed. Basically after I set the dash pattern in inkscape, this
<path style="fill:none;stroke:#ff0000;stroke-width:1;stroke-linecap:butt;stroke-linejoin:miter" id="foldm__3" d="
...
" />
becomes this:
<path style="fill:none;stroke:#ff0000;stroke-width:1;stroke-linecap:butt;stroke-linejoin:miter;stroke-dasharray:6,3;stroke-dashoffset:0" id="foldm__3"
d="
...
" />
This might be useful if people don't have means to score (some machines seem to advertise this separately, through god knows why would it be any different from cutting with a low blade setting), or if you prefer to actually perforate instead of scoring. I found that for thicker paper this gives easier, cleaner, straighter folds, especially for mountain folds, although admittedly on the expense of breaking through the visible surface.
- Removing individual flaps. Ah, when I don't like a flap, I leave it there and then when cutting I just cut it off. I guess that may be inconvenient if you have a cutting machine. I guess we could have a new mechanism when in "Tab mode" that hides it, maybe by holding the "shift" key? The "shift" key already does something special in "Face mode" and in "Edge mode", but not in "Tab mode".
That sounds good. Or single click could just cycle swap flap -> remove flap -> flap on original. But I like shift better, this is rare, and you would have to add a timeframe after which the cycle reset, and/or any other action should reset it, so that you're never in the situation where you'd except the flap to be swapped, and it is instead removed.
As long as "modifier + click" actions are not that complicated (ie, they fit in the bottom line explanation) you don't need anything fancy. I could imagine a context sensitive right click command menu instead, but I don't think it complex enough yet to need that.
- Removing/Hiding faces. Again, from Blender that is trivial. But having the unwanted faces all together with all the unwanted folds, and moving them out of the paper seems like a good enough solution. They are still shown in the 3D model, however. Yes, that works, that is why this is pretty down the list.
The problem with actually hiding them is: if you change your mind how do you get them back?
Either there's a toggle to show/hide let's call them "disabled" faces, or they could be rendered faded/transparent whatever. I think the toggle would work, it seems like a separate workflow step when you want to deal with it.
Some of these things could be solved by adding a menu to edit the "edge properties" separated for each edge, but I'm hesitant to add those. Currently all options are global, so "what you see is what there is" (WYSIWTI?), there is no hidden information anywhere. Adding per-edge options could mess that model. Imagine that you change your global tab-width and suddenly some tabs will not update because there is some option somewhere that overrides it. I guess that we could design a good UI around edge/face options, but I'm not sure how... Using color codes may not play nice with background textures.
Ah, yes, this is a very good point, and a lot of tools do make a terrible job of letting you chase down customizations. I think it must be something you don't do "by mistake", so yes, probably a context menu, and one that has a "reset to default" option. For finding those that are changed, I can imagine adding emphasis by highlighting them in bolder, some bright color. If this is a sort of overlay view that you can toggle, then you can even fade items that are default, and remove textures when rendering.
I could also imagine some floating icons that kind of transparently indicate these, but that might become cluttered.
And yes, this sounds like a lot of work and extra complexity and maybe better left to the modelling part. I think my brain tries to pull things here to be able to do updates in a single tool.
About helping with testing that will be great. Can you tell me what Operating System you are using? Also, are you able to build the version yourself or would you need testing builds (no problem either way)?
I'm on linux, specifically Fedora 38. I guess rustc or cargo or whatever is in the toolchain can't be worse than autotools, so I think I'll manage with a branch :)
I think I will prioritize items 2 and 4... stay tuned!
Great, thanks!
I'm on linux, specifically Fedora 38. I guess rustc or cargo or whatever is in the toolchain can't be worse than autotools, so I think I'll manage with a branch :)
Of course there is some chasing around C devel packages, but I've just tested 6107a3f and it seems to work great!
That was some quick test!
Let me think of point 2 now, that will take quite some more time...
Hi @kroozo!
I have just pushed a commit that implements the "Print edge ID" feature. It is disabled by default, but can be enabled from "Document properties / Page layout / Edge id font size".
For now, it only prints the ids in the printable (SVG, PDF or PNG) file, no feedback in the GUI.
I've reworked the SVG output in particular, so that the text is in its own layer now, so you can move the ids around if you don't like the default positioning.
Can you test it and tell me what you think?
Hi,
I have done some testing, it looks pretty good already. Looks, and aligns good, the separate layer in the svg is pretty good.
There's one important thing: I have assumed the IDs to be printed inside, as that's what I've always seen, and because I'd expect them to be there when I'm gluing, not on the scrap paper. Of course now that I think about it I get that if there's texture, you would not want that to be printed on top, and I assume there are people who do not want anything printed outside, hence the out and in segment options on folds, but I still think that this should at least be a setting. For me, it's much easier if its on the face, and I don't care, I'll paint it anyway, I can't glue without getting some grease on the model inevitably :)
There are some others, more on the idea/food for thought side.
Great work!
I have assumed the IDs to be printed inside, as that's what I've always seen [...] if there's texture [...]
- Yes, the numbers will ruin a printed texture. In my workflow I prefer to have them outside the model, and in case they overlap other pieces they should go below. But if you are going to paint it, it makes much more sense to print them inside. Let's add an option for that.
About your other points:
I've pushed a few commits that implement points 0, 2, 3, part of 5, and 6, and fixed a few bugs. Can you check it and tell me what you think? I really appreciate the feedback!
Hi,
Took a look.
About the dots, yes it looked a bit weird at first, but I think it is growing on me. It works both as an orientation indicator and as a separator:
Also it can work as a sign of identity, you see a model with dots and you know what tool they used :yum: .
About the stable IDs, it is not critical, but frequently when cutting models I mess a few pieces. Then I go back to Papercraft, move all the failing pieces to one page, fix some hard cuts/joins if needed and reprint just that page. Having the same IDs here is a plus for me. Also I'm thinking that those IDs will be useful if/when I implement the "edge properties" tool, to keep track of what the user is doing.
So, my mind took a step back somewhere on thinking on 5, and I started asking the "why" questions. I think it boils down to "Which is the next piece, and where do I align it". In this sense, a) I don't care for the actual IDs at all, they are just pairs I'm trying to find. b) a lot of them is insignificant, you'll look the the two ends of a long edge, pick one, and start gluing the flaps on the piece one by one till the end. You don't care about IDs in the middle.
So I thought, what if we indicate what is significant. My rough idea is:
Here is a hastily drawn ugly example of a diamond, with red arrows for the start and blue for the end.
Basically you look for the next piece, you read the number, pick that one up from the pile, you align the start mark, and you know what to do.
As an added bonus, if the user numbers the faces, you can indicate intended assembly order.
Those arrows are fancy! In SVG it would be relatively easy, but what about a PDF/PNG? I would need to draw the arrows myself, and that would require some thought. If you have long strips of edges joining the same two pieces that is nice, but if the edges switch pieces a lot, it could be a mess of arrows.
I had thought about giving pieces an id too, and then tagging the flaps with "pieceid-flapid". So in your diamond, the "22" becomes "1-22." in piece 4, and "4-22." in piece 1. One drawback is that the tags are different on each side of the cut. Maybe naming the pieces with letters would be more pleasant: in piece A: "B-22.", and in piece B "A-22.". Another drawback is that piece names will not be stable, because each time you join/split pieces you will have to recompute them somehow.
I thought also of drawing spline lines connecting the sides of a cut, going below the pieces... but what if they are on different pages? I thought of the lines going out of one page and into the other, depending on how you have the pages layout in the GUI. But then, for big models it might look like a crazy mess of lines.
Those arrows are fancy! In SVG it would be relatively easy, but what about a PDF/PNG? I would need to draw the arrows myself, and that would require some thought
Oh, those are just for demonstration, this was easy with the annotation tool in gwenview. I definitely would go for a text char in the label. There's quite a lot of utf arrows, and then it's just a good font that has them, but you could even just go with ">" and "<". So like 123> [edges here] <123
. But since really its just the position the marker, you could use the same char, even the dot that is already there like 123. [edges here] .123
. And you can also choose to mark the outside instead of the inside, for eg. with a pipe: |123 [edges here] 123|
.
If you have long strips of edges joining the same two pieces that is nice, but if the edges switch pieces a lot, it could be a mess of arrows.
I don't think it will be too bad (I tried to do the diamond somewhat messy), but I have actually been overthinking it: I pushed them to the corner to to push to the actual start (and when drawing and zooming they look farter away than in reality), but actually, they could be at the center, right where the edge ID is currently, in reality having "123>" on an edge is just as good as if it was in the corner. And, for the single edge connections you don't need two, like in my example, you could just do ">123<", ".123.", or similar, or just omit the marks alltogether. So it's the same amount of labels, a bit longer.
I had thought about giving pieces an id too, and then tagging the flaps with "pieceid-flapid". So in your diamond, the "22" becomes "1-22." in piece 4, and "4-22." in piece 1.
I think that works instead of the marks, too. It's like the dots a bit: most of the time, it's just noise, and it misses a clear mark of direction, but on the pro side the sideid can be stable, that helps followups when fixing thing.
One drawback is that the tags are different on each side of the cut.
I have been thinking of that too, but I think the process goes that "what comes next, okay, I will need piece 4, i pick that up, and find the edge I need to start by the faceid backreference on that. But yes, if the edgeid is in there too, then that helps identify the edge.
As an alternative you could mark them with both face IDs, so if you connect face 1 to 4, then it becomes 1-4 on both sides (well, "1-4>"). (Or, you could go 1-4 and 4-1, the actual pieces always being on front, and then you wont have to find a place for the face id, if you print outside, ie, you don't want to print on the face)
I can imagine a few odd scenarios where you connect 2 pieces with two separate segments, but that should give itself quite straightforward during assembly.
Maybe naming the pieces with letters would be more pleasant: in piece A: "B-22.", and in piece B "A-22.".
I was thinking about that, but you'll hit AA, AB pretty soon.
Another drawback is that piece names will not be stable, because each time you join/split pieces you will have to recompute them somehow.
Yes, I had that in mind as well, it sounds a bit tricky. If it's automatic, I think you can maybe sort by size (as in, number of faces), with a preference to keep the old ID if there are equal sizes. That should not mess with the IDs of already existing islands too much when working with them. If there is user control... that's trickier.
One other thing I'm not sure about is self connecting pieces.
I thought also of drawing spline lines connecting the sides of a cut, going below the pieces... but what if they are on different pages? I thought of the lines going out of one page and into the other, depending on how you have the pages layout in the GUI. But then, for big models it might look like a crazy mess of lines.
Ah, that sounds fancy, not sure how to do that nicely.
I think the priority here is not to make it too complicated. Users seldom read the documentation, and imagine those models that are printed and sold in a street market, or in Etsy or wherever... the end user will have no idea what all those little wiggles mean.
That said, I pushed a couple of experimental branches:
island_id
: The pieces are named with letters, and the edge ids are prefixed with the other piece name.edge_id_range
: Edge strips that glue to the same piece are enclosed in angle brackets <>.If you have time, could you check them and tell me what you think?
I think the priority here is not to make it too complicated. Users seldom read the documentation, and imagine those models that are printed and sold in a street market, or in Etsy or wherever... the end user will have no idea what all those little wiggles mean.
Yes, I was actually aiming to come up with something less complicated from a users perspective. But I give you that understanding just IDs is easier.
I played a little bit, thought it would be good to look at a more real world example, so I grabbed a chicken: https://poly.pizza/m/1YE8U35HXsI, and assembled some islands, to see how the output feels.
The edge_id_range does not seem to add much help. It helps identifying that something starts here, but search is still needle in a haystack. And yes, it does look cryptic.
The island_id is much much better. It seems like an immerse help to identify what to look for. It will also be quite straightforward to find the info that the other denotes with brackets. The only thing that might not be instantly obvious is that A-123 and B-123 go together, but once you saw a single example (and you will, at an obvious piece you start with) it will be straightforward. I think this is a good way to go.
Some observations on details:
Working on a complex model was a pretty fluid experience, I really like how once I caught up a start point I could literally get something meaningful done in maybe 10 minutes. I ended up mostly working on the right side, pulling up the pieces one by one to form meaningful islands. I did find myself sweeping around the edges of island quite a lot, to see if there are / where are new pieces, not edges to already existing islands. It may be helpful to be able to briefly show all connections of an island.
I agree that the edge-id-range is not very good. I asked some people around and they had some difficulty grasping the concept and then the utility of it. The "A-123" was much easier to get.
About your further points:
Also I sorted the piece IDs by number of faces (after tessellation), so the piece with the most faces will be the "A" and that with fewest will be the "ZZ". This makes it easier to navigate the model, but also means that longer IDs are in potentially smaller pieces. It could be changed to "pieces by area" or "pieces by flat-faces" or "by page", but I don't think it matters too much.
Here are a couple of picture from my Pikachu model, with the edge-ids inside (note how the "A" goes outside of my extremely concave flat-face):
And with the edge-ids outside:
I'm quite happy with the looks of it :sunglasses:.
I did find myself sweeping around the edges of island quite a lot, to see if there are / where are new pieces, not edges to already existing islands. It may be helpful to be able to briefly show all connections of an island. That can be a useful tool, maybe holding "Alt"? But I don't know how easy it would be. Would you mind opening a separate issue for this?
Remove the dash. I think some separator is needed. If I see "A123" I will tend to look for another edge labelled the same "A123", but "X123" will look to different. Also the "011" and the "I10" would look kind of similar. I think a colon looks nice and is shorter than a dash: "A:123". With this I think the ending dot is no longer needed, the letter and colon mark the way. There is still some theoretical partial ambiguity but I think they are not worth it ("I:1" upside down is still "I:1"!).
You are right, I've clearly have not given this enough thought. And the colon is very good choice. Shorter, and actually conveys the meaning better, at least to me. :+1:
Mess in small tabs. You are right, if the id inside a flap is next to the fold line instead of next to the cut line, there is more room. So done! That helps a bit with the mess, particularly with triangular tabs. And they will be all parallel. I could move them inside the model itself, but that could make things worse, depending on the model. This has the nice side-effect that when the ids are outside, in a triangular flap, they are now parallel, too.
Looks pretty good. I still did find a few places cramped, but its gonna be much less frequent. From what I seen, on thing that might be worth trying is rotating the label 90 degrees if it is longer than the edge (Face probably have to be that big to fit the label in one direction, and even if not, it's probably better to overlap with something inside)
Also, maybe 1-2 extra pixel padding from the line would help readability, especially once you folded the flap.
Position of the piece label. Indeed, I was using the center of the bounding box when inside, and the top of the bounding box when outside. Not very nice. I have changed to: When outside, just at the top of the highest vertex. When inside, in the center of mass of the biggest flat-face (flat-face are the faces before tessellation). Naturally, the biggest flat-face may also be concave, but it should be much less noticeable.
Seems perfect.
Also I sorted the piece IDs by number of faces (after tessellation), so the piece with the most faces will be the "A" and that with fewest will be the "ZZ". This makes it easier to navigate the model, but also means that longer IDs are in potentially smaller pieces. It could be changed to "pieces by area" or "pieces by flat-faces" or "by page", but I don't think it matters too much.
Not really, not with the edge IDs being separate things. The by-page (and maybe some xy order on that) gives some ordering possibility in the hand of the user (although very crude), and most of the times you'll probably put thing that come after each other somewhere near.
I'm quite happy with the looks of it 😎.
Cool indeed. :sunglasses:
That can be a useful tool, maybe holding "Alt"? But I don't know how easy it would be. Would you mind opening a separate issue for this?
Sure, opened #8 .
maybe 1-2 extra pixel padding from the line would help readability, especially once you folded the flap. Not pixels, everything is measured in millimeters. The separation from the line is proportional to the font size, that's probably why your smaller font got all cramped. Anyway I think you are right, it is too near, I've added a bit of extra separation.
I think this issue is mostly done and can be closed, do you agree?
Anyway I think you are right, it is too near, I've added a bit of extra separation.
Looks better!
I think this issue is mostly done and can be closed, do you agree?
I do. There might be a few things in here, that are interesting, but this has been a rather long (but quite fun) thread with a lot going on in it, I think we're better of just opening another issue if something resurfaces during usage.
Thanks for the effort, you've made some awesome stuff here :)
Hi,
Pretty neat project. Been doing some papercraft for a while, and the time came to design some lightweight stuff myself -mostly for the kiddo, so just some very simple things - so I've been looking at options, this one beats pepakura by miles in UX.
I do have some ideas, I'll list them if you don't mind (I did not want to dump issues one by one, but can separate them if you prefer). These are in order of what in my importance order.
Unfortunately I am illiterate in rust (can probably read it), but I'm happy to help with testing if you consider any of these.