Only shift objects in Z if min z is below zero. If Z is above zero leave alone #1063
Conversation
|
|
|
This would break current behavior and create huge confusion for users... Every object has to touch bed or support material (= raft), so it sounds very illogical and counterintuitive to try printing an object in mid-air with a FDM/FFF printer. If you want to handle multiple volumes inside a single object, use a multi-volume input format such as AMF. object != volume |
|
Current behaviour is illogical. regardless of how much confusion you are worried it might cause it is wrong behaviour. Automatically moving an object is wrong import should import in place. you could have a checkbox option to auto center and drop if you feel it's required. since support exists, there is no reason an object cannot be printed in space... but since you insist on dropping objects to the print bed, even if I place it above the print bed in repetier host, as soon as I slice it, you automatically drop it to zero. Splitting an object and Dropping to bed are two separate functions and should be separated - no question. I have always completely resented that slic3r drops objects to zero... ALWAYS. you are presuming that the operator had no idea what they were doing when they designed the object, and that is also not "logical" On top of all that, the idea that a multi-volume OBJ or STL is intended as a collection of objects that should be dropped to the bed is erroneous and a bad assumption. AMF is not supported by major CAD software. SPLIT and DROP should not be done together But if you insist current behavior is sacred and cannot be changed - then we have to add an "import without drop" and "split without drop" button - doesn't that seem more awkward? (or IMPORT IN PLACE, and SPLIT IN PLACE) |
|
Can you describe one actual usage case? |
|
I showed you in the image above a multi-volume object should split into multiple objects in place. e.g. I build a part with a manual support structure (a cradle if you will) Another usage case I use all the time and have to do a dumb hack to get it to work is for making taller support (not rafts) so that it's easier to remove... so I build a small block at zero so that slic3r can't forcibly drop my parts. of course, then I have an extra block of material, but meh... it sorta works. OK here's another case... ANY of the parts where there are gears etc that are impossible to assemble, but must be printed in-place to work. IF you can split them in place without dropping to ground, then you don't have to worry about the erroneous behavior slicer has where it merges the volumes of a single object, because once you split the object the volumes are each their own part. Question - if I were somehow able to convert my obj into amf - assuming that there is a conversion tool that would separate the volumes into their own parts without moving them... would slic3r not move all objects to ground anyway? I have no problem with having a default option to move objects to the print bed, as long as I can override the behavior. however, in the current state there is no way to avoid slic3r making this wrong assumption. ALL parts I print are where they are intended to be, and I absolutely do not want slic3r thinking for me. honestly, I resent the automatic centering. If I want to place 4 separate objects at the corners of my print bed, why does slic3r think it knows better? and it's not like I can precisely manually edit the position per object, so...it's frustrating. - imagine I want to print 4 cubes at the corners... and I want them aligned with each other. OK I can build a single STL with all 4 in the same object. but I shouldn't have to. The fact is I have to work around this behavior - so to answer your question - this is not a theoretical need/request... I guess the bottom right example isn't a good object to illustrate a case for wanting to print a floating object. |
|
Let's analyze your proposed usage cases. build a part with a manual support structure - that's about a possible feature that is not implemented nor designed yet. In any case, a volume providing a hint for manual support structure as you proposed is semantically not an object and will need its special treatment. Anyway, we're talking about vaporware as all this is just an idea and not available. build a part with 2 types of extrusion (polypropylene/PLA) - you said it right: it's one object, having two internal volumes. Not two objects. Anyway, your usage case is already served by the procedure described in https://github.com/alexrj/Slic3r/wiki/Multiple-extruders so no need to make any changes. a dumb hack to get it to work is for making taller support (not rafts) - raft is generated by the same exact code as support material, so I don't see any difference. Just set the raft layers option to your desired number and the object will be raised from the build plate, with support material below it. don't worry about the erroneous behavior slicer has where it merges the volumes of a single object - are you talking about #1056? That's just a bug. Fixing it is the solution, not adding one more option. |
|
The procedure outlined is awkward and requires unnecessary steps. I don't see why it's more intuitive to automatically drop parts to ZERO than it would be to have a button "Drop" like how Repetier Host has. The plater function in RH is acutally pretty close to ideal in terms of interacting with the objects. you can move/rotate/scale them, and if you want them above the print bed, you can. No assumptions about what's "correct" If you don't move the objects on import/split/etc... then you can make your multi-material files within the normal way a user interacts with slic3r, instead of making the user go through some strange intermediate file creation step. If you really wanted to be intuitive a "combine stls" mode in plater, then you can make multi-material print-plates on the fly. After you finish the "combine stls" mode, if you must drop the entire plate (not each part) to the print bed, so be it. The advantages here are Export STL/OBJ/AMF - exports the multi-material file now So there's less weirdness for the user to deal with - it's just the next logical step for the user to create their multi-material files. the extra menu item in File went entirely un-noticed by me as there is not even a hint in the rest of the software that this might be there. In fact, I rarely use the menu at all - why would I, programs that have an interface like you have made, rarely have anything but replication of features in the menu, and should never hide important common functions up there. If you don't want to do any of the above... maybe just make a "make AMF" drop target
As for not moving the parts to zero, if you remain unconvinced, and if no one else seems to feel the same as me, I will just have to maintain my own version that doesn't drop parts to print bed - because I really prefer it to not do that... and I don't like having to make AMF (yet another file to clean up later) |
|
A multi-material object is quite different from multiple adjacent objects with different materials. You still seem to have some confusion about what "object" and "object volumes" mean in this context. An object can have multiple volumes, but still be a single object. That said, the GUI for multi-material printing can be improved, and it will of course. |
|
Not confused at all - I get it. but... however you want to call it - why can't I import multiple OBJECTS into place and assign them their own material? and by that token, why can't I split a multi-volume object into separate objects in-place and then be able to assign each one their own material or settins etc. IOW - why is the multi-material idea for you only limited to "within a single object" as opposed to, as you said, multiple adjacent objects? Why can't I print the same CUBE in each material next to each other if I want? One thing though - if you split in-place - I guess you'd then want to have a re-combine button... in case you had like a dozen or a hundred little bits that needed to be put back together so they, all at once, could be assigned one material setting. In that case, your methodology of having 1 stl for each material works better. the pathway to a multi-material object is worse than clunky... and what if you have 2 files you want the same materail, I don't even think that works. support 1.stl now what? if you didn't insist on dropping objects on import, you could have a drop-targe for each material type. Yes, I took a leap in that I was assuming you were going to make it possible to set each OBJECT's material and/or print settings, on the object line. But that's not how it is. Even if you double click the object, you should be able to set single objects material and print settings for each. anyway... like I said - I'll just keep doing what I'm doing as it solves my problem. until someone else can justify this better than I can. |
|
by "visually in plater" I merely mean, how the user percieves them as things to interact with. |
|
I agree that slic3r shouldn't move things when coming from repetier host or another external placer. |
|
oops... |
…et's assume that's on purpose.
Slic3r, moves all newly imported objects, and new objects created by split, so that their bounding box minimum Z is at 0.
Obviously we don't want points below 0, so we should continue to move objects up to 0 on import.
However, if the object is above 0 already, we should probably handle separately, the moving of the object so extents[Z][MIN]=0. e.g. using a new BUTTON called "Drop"
For objects with multiple separate volumes, we may want to split them in-place.
slic3r current splits them, finds the bounding box and moves each objects so that etents[Z][MIN] = 0.
When splitting a multi-part object we may actually want to maintain their position. For example, if we wanted to specify different materials like - abs for a hing, and pla for the two halves of a box. or a manual support region and the object.
I'm sure there are other cases as well.
the only drawback to my implementation here is that 1) it's not the true bounding box returned unless the object is below 0. and if you did want to drop all objects so min Z is 0, I haven't provided a way to do so (limits of my perl skill)
This is less of an immediate pull request, as - help, I'm trying to do something useful to Slic3r, but am stuck. :)
let me know - I now know most of the places the align_to_origin and move are used, and more or less know what's happening, but not how to modify... very much. :)