Open m-Th opened 7 years ago
A very necessary improvement here would be Infill properties: Density, Pattern, Top/Bottom Pattern.
This would allow us much greater flexibility in defining the strength vs material economy / speed for the different parts of our objects.
I know that this is only on the Z axis but allowing such adjustments everywhere on the object would complicate the things a lot.
Simplify3D implemented this in their last version (!). See here https://www.simplify3d.com/software/release-notes/version-4-0-0/ .
Look for "Variable Print Settings" (their 1st feature to advertise!) and "Seamless Process Transitions"
While I was reading the release notes, I thought "oh fine, they can now do what Slic3r already was able to..". Is the modifier mesh feature with generic box mesh not able to do what you want?
OK the temperature and fan speeds might be a tricky one. While you are defining them per layer height, this is only possible for single material printers. With multi material, it will get complicated or confusing, as you have to define the extruder also in this step. Maybe we don't need a new feature, but a better (more easy) way to handle modifier meshes?
Modifier meshes... yes, perhaps a better approach but the GUI must be revamped in order to:
Basically the user needs the main 3D editing engine for these modifiers.
Which is better for you?
A.) To integrate these modifiers in the main GUI - for example here:
Where with having a right-click menu and/or a local toolbar one can add modifiers and such. (all the tooling from that window)
B.) To replicate the engine inside of Details window
Imho from all points of view (user and dev - it reduces the code duplication) the solution from point A.) is better.
In fact I think I have a proposal in my mind how this modifier meshes could be handled in a better and more visible way. While they are not important for beginners, I think about them as extremly powerful tools when it comes to complicated or large prints. This is unused potential which could be shown to the users!
Therefore I would propose to make modifier meshes more usable first, and then build other features based on this one.
I will create some pictures how it could be and what could be useful to use them. Maybe somebody likes it ;)
Modifier mesh usability proposal.pdf (Outdated)
Feel free to comment. Note: Pause (M600 feature) is not mentioned because I see no easy way to put it in a reasonable gcode section over GUI. Setting M600 is always a delicate thing of analyzing gcode movements to see where it will fit best in terms of blobs and line voids it may create.
This would be a huge change anyway - but maybe something like that will find it's way into one of the next mayor releases?
Version 2: Modifier mesh usability proposal.pdf
Looks very promising (ok, perhaps I am biased because it was my idea 👍 :-) ).
Some notes: (in no particular order)
Modifier meshes should have the same colors for selected / unselected. The only thing which differentiates them from a normal object is transparency.
„Hold down m,s,r to move/rotate/scale mesh.” Not needed imho. The meshes must be manipulated like any other object. Just that the user cannot select them by clicking directly (or (s)he should?) because it selects the whole object.
In order to select a mesh, the user should click on the appropriate mesh in the object/mesh tree, or by using a modifier key (usually CTRL like in CorelDraw and Visio). It is the standard behavior in group management: click - selects the group. Ctrl+Click or Click in the Object Tree - selects the desired member of the group.
This is more intuitive (anyway by clicking there we can select an stl) and, also, you will use the same code to manipulate any 3D object in space.
The Part Settings should be indeed at the bottom of the Object List, after the [Load Part...] & co. buttons. You keep the same engine from the old Details window.
Very good addition with Modifiers: x,y,z for a box, r & for a cylinder... but hey! Any stl is in fact a box, isn't it? Expose the same code for any other stl loaded. Many times we need the object to be exactly of certain dimensions (eg 12x34 mm) and not of a certain scale (eg. 56% from the original - this is rather meaningless).
Oh! Now I see that you posted another proposal... I will comment back tomorrow on this one... nice things inside. :)
Oh! Now I see that you posted another proposal... I will comment back tomorrow on this one... nice things inside. :)
It's only a small update, nothing realy new - so your statements should be still applicable.
Looks very promising (ok, perhaps I am biased because it was my idea 👍 :-) ).
Maybe :smile: But keep in mind I basicaly invented nothing new - it's all already inside Slic3r. It's nearly only rearrangement. Of course there will be a lot that can be built up on these options then visible to the user.
Modifier meshes should have the same colors for selected / unselected. The only thing which differentiates them from a normal object is transparency.
I'm not sure if I understand this one - if you are saying for example yellow is an unselected mesh / modifier mesh and orange is a selected one, I agree. If a selected modifier is still (transparent) yellow, then not ;)
„Hold down m,s,r to move/rotate/scale mesh.” Not needed imho. The meshes must be manipulated like any other object. Just that the user cannot select them by clicking directly (or (s)he should?) because it selects the whole object.
I agree for scaling / rotating. The basic thought behind this was movement of a mesh in z direction. At the moment, this can't be done to an object as it wouldn't be usefull. A part has to be lined up with the print bed at all times. A mesh might also float somewhere in the air. Therefore we need at least some way to move it up and down. While this can be done inside the settings window, a coarse free movement might be nice.
In order to select a mesh, the user should click on the appropriate mesh in the object/mesh tree, or by using a modifier key (usually CTRL like in CorelDraw and Visio). It is the standard behavior in group management: click - selects the group. Ctrl+Click or Click in the Object Tree - selects the desired member of the group.
:+1:
The Part Settings should be indeed at the bottom of the Object List, after the [Load Part...] & co. buttons.
You mean an exposed "Object Settings" box at the bottom? We already have a Settings button in the top row next to Layer editing, I think we can reuse this depending on the object/part/modifer mesh selection.
Very good addition with Modifiers: x,y,z for a box, r & for a cylinder... but hey! Any stl is in fact a box, isn't it? Expose the same code for any other stl loaded. Many times we need the object to be exactly of certain dimensions (eg 12x34 mm) and not of a certain scale (eg. 56% from the original - this is rather meaningless).
An stl is a list of triangles in first place. Beside this, we already have the scale to size option, isn't that what you want? If you want to have also the possibility to scale the whole object to a width, I'm not sure how to define "width". An stl can be placed inside a box (I think that's what you mean with an stl is a box), but how should this box be orientated? Do you want the "length" to be along the longest axis across the print in XY plane? Or should length and width be along X and Y axis? Fot this scaling option, a look into other slicers might be necessary. I never used this option in any slicer, usualy only the maximum size was relevant for me and that's what's already inside Slic3r.
I basicaly invented nothing new - it's all already inside Slic3r. It's nearly only rearrangement. Of course there will be a lot that can be built up on these options then visible to the user.
Yes :) - That's why this feature looks so nice. It is a low hanging fruit.
if you are saying for example yellow is an unselected mesh / modifier mesh and orange is a selected one, I agree.
As it is easier for you (for devs). Of course, having the meshes with a degree of transparency is mandatory. The user must know immediately that he has to deal with a mesh / a non-printable object.
I agree for scaling / rotating. The basic thought behind this was movement of a mesh in z direction. At the moment, this can't be done to an object as it wouldn't be usefull. A part has to be lined up with the print bed at all times. A mesh might also float somewhere in the air. Therefore we need at least some way to move it up and down. While this can be done inside the settings window, a coarse free movement might be nice
I would propose Shift. Shift+Drag „raises” the mesh „into air” (ok, it moves on the Z axis). Shift key is a standard modifier for movements in various 3D programs (Blender, Rhino etc.).
You mean an exposed "Object Settings" box at the bottom? We already have a Settings button in the top row next to Layer editing, I think we can reuse this depending on the object/part/modifer mesh selection.
Ah, yes. No problem for me. So we will leave there only the settings/modifiers/properties. In fact the button is already named „Settings”, no?
Speaking about Settings, in the list of settings...
...we need to add some „new” things: - in fact it is the topic at hand:
....yeah, I read what you wrote WRT Pause. I think that you must follow the same rules which are imposed by filament changing due of multi-material.
...but let me turn to your message:
An stl is a list of triangles in first place.
Yes, but I (the users) don't know/care about this. We see a volume. A (3D) „thing”.
Beside this, we already have the scale to size option, isn't that what you want? If you want to have also the possibility to scale the whole object to a width,[...]
Scale to a width. (Height/depth). In fact it is the same code with „Scale to Size”... (Width and Height does not have any real significance in 3D space) BUT:
The „Location”, „Rotation” and „Scale” groups of edit fields are, of course, based on values of the bounding box surrounding the object.
Btw, you have a bug in the Scale to Size dialogue: UNFORTUNATELY we do NOT have a Heatbed like the one described in the caption of window: :-)
NOTE: I can live with these dialogs if you fix the captions: Change „Scale along X” in „Scale along X (dimensions in mm)” and, of course, fix also the window's caption in order to show the correct values.
The scaling dialog was easy to fix: https://github.com/prusa3d/Slic3r/commit/933d5b261aa97d4ab530bcdefbe726526c7c118c
On Tue, Aug 1, 2017 at 1:10 PM, m-Th notifications@github.com wrote:
I basicaly invented nothing new - it's all already inside Slic3r. It's nearly only rearrangement. Of course there will be a lot that can be built up on these options then visible to the user.
Yes :) - That's why this feature looks so nice. It is a low hanging fruit.
if you are saying for example yellow is an unselected mesh / modifier mesh and orange is a selected one, I agree.
As it is easier for you (for devs). Of course, having the meshes with a degree of transparency is mandatory. The user must know immediately that he has to deal with a mesh / a non-printable object.
I agree for scaling / rotating. The basic thought behind this was movement of a mesh in z direction. At the moment, this can't be done to an object as it wouldn't be usefull. A part has to be lined up with the print bed at all times. A mesh might also float somewhere in the air. Therefore we need at least some way to move it up and down. While this can be done inside the settings window, a coarse free movement might be nice
I would propose Shift. Shift+Drag „raises” the mesh „into air” (ok, it moves on the Z axis). Shift key is a standard modifier for movements in various 3D programs (Blender, Rhino etc.).
You mean an exposed "Object Settings" box at the bottom? We already have a Settings button in the top row next to Layer editing, I think we can reuse this depending on the object/part/modifer mesh selection.
Ah, yes. No problem for me. So we will leave there only the settings/modifiers/properties. In fact the button is already named „Settings”, no?
Speaking about Settings, in the list of settings...
[image: image] https://user-images.githubusercontent.com/13384655/28821780-77e44878-76bf-11e7-9f9d-b58198dce458.png
...we need to add some „new” things: - in fact it is the topic at hand:
- Nozzle Temp
- Bed Temp
- Fan min
- Fan max
- Pause
....yeah, I read what you wrote WRT Pause. I think that you must follow the same rules which are imposed by filament changing due of multi-material.
...but let me turn to your message:
An stl is a list of triangles in first place.
Yes, but I (the users) don't know/care about this. We see a volume. A (3D) „thing”.
Beside this, we already have the scale to size option, isn't that what you want? If you want to have also the possibility to scale the whole object to a width,[...]
Scale to a width. (Height/depth). In fact it is the same code with „Scale to Size”... (Width and Height does not have any real significance in 3D space) BUT:
- Have all the info centralized and editable. See here (from Blender) and example with the famous Suzanne:
[image: image] https://user-images.githubusercontent.com/13384655/28822164-e4845dbe-76c0-11e7-864f-1518281970c5.png
The „Location”, „Rotation” and „Scale” groups of edit fields are, of course, based on values of the bounding box surrounding the object.
Btw, you have a bug in the Scale to Size dialogue: UNFORTUNATELY we do NOT have a Heatbed like the one described in the caption of window: :-)
[image: image] https://user-images.githubusercontent.com/13384655/28822736-17c55ba4-76c3-11e7-9870-7bf4c76bb568.png
NOTE: I can live with these dialogs if you fix the captions: Change „Scale along X” in „Scale along X (dimensions in mm)” and, of course, fix also the window's caption in order to show the correct values.
- This exact scaling engine should (obviously) work on meshes. In fact, an pane with exact values of location, rotation and perhaps scaling becomes much more important when we deal with modifiers.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/prusa3d/Slic3r/issues/378#issuecomment-319340995, or mute the thread https://github.com/notifications/unsubscribe-auth/AFj5I4Y29iI9h81vJeXO366v1jaMuzuNks5sTwfCgaJpZM4OGSxy .
@bubnikv : Thanks! ...however the big problem is elsewhere. Waiting... :)
Also, to make the things clearer perhaps you can change „Scale along X” in „Scale along X (in mm)” to make it more user friendly.
(This comment is probably aimed more at the initial request for more variables per layer range.)
I'm using this feature for the first time, and before I found the dialog to assign layer height overrides, I was looking for something like the layer range sliders in the print preview, with the ability to set the Print Settings (and possibly Filament) for the selected layer range. In my scenario, I wanted an initial, thinly sliced region to use more solid infill layers on the top and bottom, but wanted fewer infill layers in the range using thicker layers. This is a simple scenario; single extruder, no filament swapping, just a desire to apply all aspects of a Print Setting to the layer range.
It seems like assigning settings to layer ranges, the same way we now assign them to the entire job, would allow for more detailed customization during layer editing, using existing, recognizable configuration structures.
This is a simple scenario; single extruder, no filament swapping, just a desire to apply all aspects of a Print Setting to the layer range.
Yes, but we need to cover the MM variant also.
It seems like assigning settings to layer ranges, the same way we now assign them to the entire job, would allow for more detailed customization during layer editing, using existing, recognizable configuration structures.
Sure. However having a modifier mesh in simpler words a "3D Zone/Area" - in which the settings will be different will give us a more intuitive way to do this without being tied to Z axis. See the discussion above. The document posted by @Sebastianv650 is a good overview/intro on topic.
I think we have implemented a lot from what was requested in this issue. You will be surprised after you install the upcoming Slic3r PE 1.42 alpha.
I suppose an easy way to have per layer temperature/cooling control is to add Before/After Layer Change custom Gcode under Filament settings profiles . Using placeholders is easy enough to have different settings for per layer cooling/ temperatures for a material without having to have duplicates of printer profiles for each material and nozzle.
I think, it would be viable to use an object property/settings if still available on 1.42 just like on 1.41 to 'load generic' that enables us to place and prevent supports over certain area. So if we use this 'generic' or 'modifier' part, we should override certain settings over the profiles
It would be great if the new layer editing tool in 2.1.0A1 included temperature changes as an option.
Agreed that this would be great esp. with the changes to 2.2 builds. I love that I can add a comment on the pause - we should be able to add the comment on the color change, as I can't see the model (colored as it is now! THANKS!!!) on the mk3 display. Can you allow a message to display on color change, too, so I can see what color the next layer was intended to be? In slicer it's great, but I have to then put the colors on a post-it and check them off as I complete them on the actual print. Having this show on the screen (like with the pause comment text) would be amazing! :)
Thanks for all the great development, folks! This really is another great reason I got into Prusa's when I joined in 3d printing. Thank you!!
Box
Slic3r Prusa Edition Version: 1.35.4-prusa3d-win64 Build: Slic3r-1.35.4-prusa3d-win64-full-201706151614 Operating System: MSWin32 System Architecture: MSWin32-x64-multi-thread Windows Version: Microsoft Windows [Version 6.1.7601]
Behavior
Yes, we have variable layer height and this is good. However we need more variables per layer besides the height:
Proposed implementation:
We need a simple GUI like the one below in which the values for the 1st layer and 2nd layer are filled automatically from Filament Settings (Pause is always false).
By convention, we say that a layer without a Value in a Property will NOT generate the specific G-Code hence the value from the previous layer will remain in effect. (Values added for illustration only - Pause should be unchecked by default) Ok, you know that the Property-Value table should be left aligned to the Layers pane, isn't it? :)
Possible improvements:
Having + and - signs in front of values means that they are relative values to the previous layer.