I have found that this only affects files that are not parts of a "part". With the new split to object and split to part options, a file with two pieces split into objects will both always be on the ground. But with a file that is split into a part, both items will stay where they are and can be moved in the z direction. Would it be possible to at least allow us to add other files to a group AKA part?

I would suggest a two part fix

1. Adding a "group to part" UI icon next to the two splits.
2. for individual objects, graying out the Z position box and adding hover text that says that its only available for grouped parts.

With this also allowing users to group/ungroup parts by dragging them in the sidebar into/out of parts would be 👌

EXOgreen ... sounds complicated.
Cannot we just take a part and lift or lower it to our desired Z position and fine without any cut/split/group/append/modify/... ?
It has been months that I moved from Cura to Slic3r PE (still happy with slic3r PE :-) ) but I think I remember that in cura you just took the part and lifted it up and that was it.

I would disagree, I have a model that can/should be stacked on top of each other. But they are individual files. If I bring them all into Slic3r, I cannot stack them, and cannot add them together as one part so they all are affected by one change, ex rotation or scale.

@bubnikv There are many cases when moving the part in Z direction really makes a lot of sense.
See expected result in my first post.

Try to print a part that has one area of its underside touching the build plate and another area of its underside 0.5mm higher in Z direction.
You will get better results if you lift it up so that support is everywhere and not only 0.5mm below that higher area.
0.5mm is too less height for interface layers, etc... it will be really bad result without lifting it up.
.... just as a not so usual example ;-)

But to resume a failed print is really easy with lifting the part up.

I cannot find a reason why it should be forbidden to move a part up or down.
With the "lay flat" icon you can drop it down on the bed again, if necessary.

I would need to lower the part below the bed (like with not-so-comfortable cut function) so that lower part is not printed.

What is not-so-comfortable on the cut function?

But to resume a failed print is really easy with lifting the part up.

I don't understand how this is supposed to help to resume a failed print.

I cannot find a reason why it should be forbidden to move a part up or down.

Any functionality, which is not needed, will stay in somebody's way.

Try to print a part that has one area of its underside touching the build plate and another area of its underside 0.5mm higher in Z direction.
You will get better results if you lift it up so that support is everywhere and not only 0.5mm below that higher area.

This is easily achieved by enabling the raft.

@EXOgreen You can stack objects in Slic3r by right clicking on the object in the 3D view or at the object list, and selecting "Add Part -> Load ...". You can then manipulate the parts in Z as you wish.

Can the Z axis be greyed out for files not in a part? This should remove some of the confusion.

Also can we add this functionality of combining files as parts in the sidebar for files already loaded in Slic3r. This is what's happening with right click > load, but not for existing parts. So if someone has loaded two file's and made changes they can be combined into a part, essentially grouping them.

What is not-so-comfortable on the cut function?

It works but is not as intuitive as just lowering the part below the Z = 0 plane.

But to resume a failed print is really easy with lifting the part up.

I don't understand how this is supposed to help to resume a failed print.

Find out the height of the failure (caliper, log, ... ) then cut the part at that height in the slicer.
Raise the part to that height in slicer.
Export gcode, print --> Printer will continue at the layer where the failure happened.

I cannot find a reason why it should be forbidden to move a part up or down.

Any functionality, which is not needed, will stay in somebody's way.

It is needed ;-) see above.

Try to print a part that has one area of its underside touching the build plate and another area of its underside 0.5mm higher in Z direction.
You will get better results if you lift it up so that support is everywhere and not only 0.5mm below that higher area.

This is easily achieved by enabling the raft.

Maybe this was not my best example without a drawing.
Have you ever used cura? It is very intuitive to just take a part in 3D space and rotate it in every direction and move it in every direction. Even Z ;-)

While I agree with being able to lift a part in the Z axis can be used for this, I'd rather parts stick to the ground. Working for a university having the ability for parts to float is asking for trouble. To complete a failed print, I have just been opening the gcode file and deleting everything between the first layer and the layer that the print stopped at, by using find to find the comment Slic3r leaves at layer changes. It works especially well when you have a gcode viewer and can even delete lines up to where the print actually stopped and not just the layer.

It is confusing for me that a part is treated differently than a modifier at moving.

When I have a part and a modifier, I can lift the modifier.
Then I change the modifier to a part... It is lifted.
I change the lower part to a modifier, then both parts are moved.... That is really strange behavior.

If parts and modifiers could be positioned freely it would be feeling just normally and intuitive.
Changing type from part to modifier and back should not move the part.

If you need a part touching the build plate you have the perfectly working new function 'lay flat '.

I have also commented on another issue thread. Stacking parts to increase productivity when producing a large number of smaller parts is an important feature. The parts are stacked with support material turned on between the layers. Other slicers have this capability. The attached screen grab is from Simplify3D.

Another good reason to have the abiltiy to move an object above the build plate so no part is resting, is for miniature printing. You can often get a much better angle to print it at by not having it lay flat, and instead entirely rest on supports. The inability to manipulate models in the Z direction is about the only thing keeping me using simplify3D or Cura over Slic3r PE.

You can often get a much better angle to print it at by not having it lay flat, and instead entirely rest on supports.

Just enable the raft.

@bubnikv Then why not simply remove the Z Arrow and text box, since they not only do nothing, they are extremely confusing, as witnessed by the presence of this thread.

That said, I would rather have the option to move things in the Z-axis. People make clever plans when they have options, and the nature of this community is those kinds of people. Perhaps just include a visual indicator or warning if a part is not flat on the bed?

Using a torus (donut) shape with 3D printing won't work properly if you can't raise the model off the build plate - the edge that touches the build plate gets flattened - so it's VITAL that users can lift their models off the build plate!!

More user choice is ALWAYS good. Especially if it's disabled by default and if anyone wants to use it, they simply go to the Expert settings.

Using a torus (donut) shape with 3D printing won't work properly if you can't raise the model off the build plate - the edge that touches the build plate gets flattened - so it's VITAL that users can lift their models off the build plate!!

How are you printing the object then? On raft? Without raft but with supports?

I would also like this feature. For instance, I'm currently trying to stack 4mm thick fan guards so I'm not having to clear the build plate every 1.5 hours. Unfortunately, I'm not able to get a small "raft" to print between the parts. I've tried support enforcers (using 'load' to load another instance of the object marked as a support enforcer) and support blockers (by modeling the inverse of the print and extruding it very high, through the full stack) both. I've also tried just a "slab" between the parts as a support enforcer. No matter what, the slicer seems to want to build supports for supports, all the way down to the build plate, even when nothing is above the area.

with a support blocker

I too, wish that I could raise and lower objects. My initial use case is manually stacking items, often just as a preview of what things would look like, without having to open STLs in TinderCAD or similar. Simplify3D has this feature.

As others have mentioned, it could cause issues for beginners, but we do have simple, advanced, and export modes now. It could be a preference that only shows up for other than simple mode.

I also want the ability to lift in z-axis. I often ‘kitbash’ where I add two files together in slicer. Imagine a had a model of a D&D character and another model of sun glasses, I can add the sun glasses, scale and move where I want. The object would merge into a single object to be printed.

Another common thing is for me to have a flat textured ‘tile’ for D&D. I want to add a wall so I want to put it ‘on top’ of the floor tile to make one piece.

I would also join the "why this useful feature not available" chain.
Why? Is it hard to implement in the code?
What if I just want to generate gcode for such a model, which is "flying" in the air?
Why do you constrain the ability to move the part in 3D space anywhere the user wants?
Craftware, cura, S3D (just the ones I use) all has this very simple function - only Prusa thinks it is not useful? :D How is that?
After nine month and PrusaSlicer 2.1 still lacks this very basic feature - simply funny :)

Used google to try and understand why this didn't work and found this thread. I also agree this is a useful feature and it is counter-intuitive for it to appear possible but then not work for no apparent reason.

I think the reasoning as to why it shouldn't be included is deeply flawed, but if it is in fact the direction that the authors want to go, then don't let me try to do it?

I agree with the majority of users! Please allow the Z to be moved as everyone would like.
This "automatic" z placing of models is completely unusefull as my opinion.

I've been struggling with trying to figure this out for 20 minutes now. It makes no sense. I have two objects, one that should sit on top of the other. The base object is effectively a raft with a custom shape and the top object is a more complex design to be printed on top of the base object. It has a bunch of separate pieces so splitting is would be cumbersome (and non-intuitive).

Yes, I could bring both objects into another 3D software and combine them but that should be an extra uneccessary step. I also want to be able to easily use the base with different top object designed and just swap them out. Just let me move the thing up please!

Kulberda, place your base object normally, then right click on it and 'add part', select your model that you want to place on top. You should now be able to move the 'top' part around freely including into the air on top of it. By adding it as part of the original model Prusa Slicer groups them as a logical entity and as long as some part of the logical group touches the build plate its requirements are met.

@traderhut

What I find interesting about this project, as compared, say to nearly any other, is that simple changes are requested, that would take a very short time to implement

What I find interesting is how many people with no knowledge of the codebase know exactly what is simple and what is not.

Here we get "I don't wanna!"

No, if you'd bother to read the thread before writing your rant, you'd see that it is in fact not what you get (e.g. #1513 (comment)). It would be more constructive to react to what the other part actually says, not what you put into their mouth.

As a Software Architect of 4 decades of experience, I can tell you this wouldn't cut it in a professional environment. You would get requests from customers, they would go through review and be presented as things that the programmers need to implement.

Did you never reject a feature request in those 4 decades? What software you worked on and how many people used it? Isn't the main difference in the fact that the process is usually not public?

I would like a feature to be able to snap one part to another one

That's another feature request that we are aware of and considering. But I'm surprised that as a software architect with four decades of experience you only see the "I would like a feature" part.

The point of writing software is to make it as easy as possible for users to do exactly what THEY want to do.

They? There is quite of lot of PS users and each wants something else. But I'm just repeating what I have already written in the above post.

C++ has been pretty dead except for embedded programming
I stopped using it in 1995
If I had the hours to spend on it, I'd think about a conversion to C#
C# would compile in seconds
it would be good to update the design
don't bother trying to argue, and maybe the best solution is to spin off another Source Repo

To be honest, if you are seriously suggesting to rewrite everything into C# to cut down on compilation times, I'm struggling to believe your claims about being a software architect. Anyway, we are not porting PrusaSlicer to C# (there are reasons, imagine them as "we don't wanna" if you like). If you think it gives an advantage over the competition and it is a hole in the market, I wish you luck in filling it.

Regarding your last paragraph. The shocking revelation that modern C++ compilers optimize well is probably not surprising for people using C++ even after 1995. We are lucky that developers of compilers spend so much time on a language that is "pretty dead" for several decades. They also rolled some "minor" updates since then. But that is really off-topic.

@paynterf

Please read my responses in this thread of what are the issues with enabling lifting the objects up.

Compilation on Windows could not be much simpler, just run build_win.bat.

I read (most) of the thread, I did miss the above comment... I think I read 2017-2019 and skipped to late 2021/2022.. Didn't read the entire 5 years worth of the thread.

In reference to it being hard to implement - I had not see any of the comments (I read pages of them at the start, and read the ones at the end) that said, that it would be hard, and it does seem like it shouldn't be that hard - I did look through the source code briefly after making this post briefly, didn't have much time to look at it though and haven't found where it would be changed. And yeah, it is very possible that the design makes it challenging to update. (but it sure seems like one would have to add nn to all the z coordinates for all the points in that mesh (worst case) (Best case, the code already is designed with an object that has an offset.

It works if you create a stl file with at least one triangle at z=0, and a gap, and then the rest of it at z=whatever you want, so the approach of updating all the points would work as a brute force solution (assuming it doesn't have a design of the object having a z offset that already works), I did see something about doing an 'add part' as a solution

As for did I ever reject a change, sure, if it does in fact take too much effort, the don't wanna comments were 1. assuming that it was a simple change, which it appeared to be - the arguments I was hearing were not about it being hard, but about it not being a good thing to add. (Again, missed the post last October), And, to be fair, als thinking about the 'MessageBox()' call that would be required in order to do the other change - the popup asking if you want to reset settings, in any reasonable design, there would be a point where those settings are being loaded from the file, and before that is done, you would simply need an 'if' that checks the return value of a messagebox (or, other UI dialog, if you don't want to use a MessageBox API), and then don't load the values. (Ideally, of course, the best solution would be to show the values that are being changed, which there is already UI for, and ask if one wants to update it, but that is off this topic)

In reference to C++ being largely dead, OK, that was an overstatement, it has its uses (which I did say), doing Windows Apps isn't really one of them, but the app is already written, and it is a LOT of work to convert it... The major change to C# vs C++ comes in readability, and speed of adding changes. However, I agree that my statement was more out of frustration than anything... And also, what language to use is always a 'holy war' among developers.. Often for those who don't know a lot of languages (I know over 30 at this point) - which gives me a bit of a different perspective. There are advantages of C++, Often Speed is quoted as the top one (which is often wrong, as I proved once during a language selection board with 12 people, who started out 10 vs 2 wanting managed C++, and ended up 12 to 0 on C# when it was done... Guess who was one of the people suggesting C#? - All of the reasons to use C++ got shot down during the discussion, including test benchmarks that were written about various things that were 'slow' in C#... ) but no, clearly, it wouldn't be worth converting it to C#, there is too much code to make it worth the conversion... And for what it's worth, I stand corrected on the comment about conversion/C++

In reference to 'it is easy to compile, just run this batch file' - I posted a message about it not compiling when I did that, and someone responded with 'here is the script that I use to compile' and that script worked fantastic, and I got a good compile. No, every attempt at running the build_win.bat failed.

On top of that, the 'master' branch had a compile error, so I had to roll back to a previous commit in order to get it to build once I had a working script.

Once I had the script, and ran it, I was able to go into VS2019 and build it and that worked. The original script (build_win.bat) create a folder in the ..\ directory (the _deps folder) which was unexpected, I didn't expect it to leave the folder that the repo was fetched into, the new script doesn't do that, which I like a lot better. From what I can tell, the new script should replace the build_win.bat, but I'll leave that to the devs. (Who said they didn't expect people to run their script, they were using it as an example..)

Also, I understand that there can be code that behaves weirdly due to assumptions that programmers make about objects. Who knows, maybe that is why in the test that I printed the infill didn't connect to the outside of the object? Because something was floating above it? Could be.

(But that is another bug report that I've not yet filed...)

If allowing Z-axis moves is too difficult, then please at least make it obvious that moving in +Z is not possible, by graying out the Z-axis value and/or removing the visual Z-axis indicator from the plater view. If you indicate something is possible, but it really isn't, then you get a lot of angry users, as indicated by this thread.

If there is a new 'script for compilation for windows' available, that would be good news - I tried compiling with VS2022 and got nowhere; after several tries I gave up.

I don't think the code is updated for 2022 yet, it compiles with VS 2019, and the other / new script also referenced 2019 directly

@paynterf

Please read my responses in this thread of what are the issues with enabling lifting the objects up.

Compilation on Windows could not be much simpler, just run build_win.bat.

So much for that explanation. Apparently none of the devs are running anything past VS2019. If you expect us to believe what you write, you should be expected to believe what we write. I reported that I was unable to compile on my Win10 PC running VS2022, and you apparently didn't bother to read it. So, why should I believe you when you say "couldn't be simpler - just run build_win.bat"?

@traderhut Just shortly. We have just created a manual page that summarizes everything that people don't have time to look for in this thread. It describes why "we don't wanna" "comment out code that forces the Z" and describes current workarounds. I believe that it will help in explaining the situation. You may not agree with everything, but maybe it will help to keep the discussion on topic and not run in circles.

C++ vs C# would definitely be an interesting and fruitful discussion, but it should not be done here. It is off-topic and irrelevant, PrusaSlicer is and will stay in C++.

The build script issues shall also be discussed elsewhere. I doubt that the issue reported in #8112 is caused by build_win.bat itself, but I don't have time to look into it now.

For what it's worth, the batch file that worked for me, and didn't create a ..\PrusaSlicer_dep folder! is attached, however, there is a line of code -G .. that clearly is saying Visual Studio 16 2019, which I assume at the least, would have to be 17 2022 (guessing here),

Also, it is critical that this be in a folder: c:\dev to work

mkdir \Dev
cd \dev
(copy the file here)
prusaSlicer_noob_build.bat

And it will build the project, or at least, it did for me... and the deps folder will be in the build\deps instead of ..\ where you would least expect it and you end up with a nice PrusaSlicer_Release folder that you can run it out of...

---- OK, uploading a bat file isn't supported, so I'm going to just paste it after this line

@echo off

REM ECHO I'm going to CLONE the PrusaSlicer repository - ready?
REM ECHO Best, if you're curently in c:\dev (or similar short path)
REM ECHO Also make sure you got at least 15 GB of free disk space available
REM ECHO.
REM ECHO Press CTRL+BREAK if you want to cancel.
REM PAUSE
REM ECHO Are you sure??? Shall I continue?
REM PAUSE

git clone https://github.com/prusa3d/PrusaSlicer.git --recursive

cd PrusaSlicer
SET "thisPATH=%CD%"
echo Building in %thisPATH%

cd deps
mkdir build
cd build

cmake .. -G "Visual Studio 16 2019" -DDESTDIR="%thisPATH%"

REM This will take a loooong time! Go get some coffee...
msbuild /m ALL_BUILD.vcxproj

cd "%thisPATH%"
mkdir build
cd build
cmake .. -G "Visual Studio 16 2019" -DCMAKE_PREFIX_PATH="%thisPATH%\usr\local" -Wno-dev -Wno-error=deprecated

msbuild -ds -nologo PrusaSlicer.sln -t:rebuild -m -p:Configuration=Release -verbosity:normal

(Messages crossed, script provided to help the person who couldn't get it to build, agreed- it is off topic for this thread)

I would like to add my grain of salt to this discussion.

Example task which needs Z-move upwards

I was trying to print a part which is made of a large block with some tiny regions which needs to be hell accurate (0,05 layer height). I did prepare a model made of some separate, closed volumes representing a main block and those regions and then exported it as a single STL file. I did import it to slicer.

Up to that moment everything went ok.

Then I split it to PARTS.

And here is the problem. You can't assign different layer heights to different PARTS of the same OBJECT. The reason behind it is reasonable and the same as for a lack of "mesh layer height modifier". I do understand that.

I thought then: fine, no problem, I can use height range modifier on separate OBJECTS to make them print with different layer height. It is enough to have those objects in right places, right?

Thinking like that I did split it to OBJECTS and then and all the parts representing those small accurate regions dropped to the bed.

Fine, I can lift them up....

It looks that I can't, they always kept dropping down even tough I was allowed to move them up. It was hell confusing, so I looked and looked and could not find any option to disable it, even tough there is an icon in right down corner close to "Z" coordinate of an object telling to drop it or, I supposed, to not drop it.

So I had to find a way to "cheat" the program.

Cheating and working around the limitations

The work around was to add a 0,1mm diameter "support sticks" to the meshes representing regions I need to be accurate. Those sticks do start at zero and are up to the detailed region so the detailed regions do have a proper height. The 0,1 diameter is not printable so I thought I would be now at home because object will be "supported" at right height and with disabled auto-centering it will stay at correct location.

Except the error "There is no extrusion at zero layer" which prevented code generation.

So I had to add at the zero level a one layer thick tiny blob to print.

Fine, no problem with that.

Now I can generate G-Code and up to now it looks right.

Of course there are problems with supports and some collisions at a build plate, but my model is not using any supports and I did took care to make them in right size and at a right place.

I did not print this part yet, but from results on screen I can't see any fault in it. I suspect, that the those regions may not "stick together" to main block very well, but I will give it a try.

I suppose this is a legitimate reason why Z-move upwards in the air and disabling auto-drop on a bed should be allowed.

Enhancement request

Please re-consider to let an expert-mode to have options:

• "Configuration->Preferences->Disable Auto drop on bed" and
• "Configuration->Preferences->Allow free Z movement of objects"

and have added from Super Slicer expert mode:

• "Print Settings -> ....-> Allow empty layers"

Keep up good work, this is a superior software anyway.

Version: 2.4.1+win64
Build: PrusaSlicer-2.4.1+win64-202203101054

Can someone PLEASE fix this stupid problem already? Sheesh!

I posted here on this thread awhile ago and haven't tried it again since but probably still works:

First time contributing here, created an account for this article; this may have already been stated but wanted to post my workaround as well. I recently upgraded to an MMU2S with my MK3S. I am printing some truck tires for my nephew that have separate tires and rims. I was trying to lift Z up to put the rims higher than the tires, that way the MMU didn't have to do several hundred color changes during the print, it would just do the tires up to a certain layer and then switch filaments one time and then do the rims on higher layers. I thought it would be easy to lift the rim up and slice it with supports, but it wasn't straight forward.
The workaround was

Import STL's normally, not combined
right click the rims/part you need higher; click add part; click add cylinder
modify cylinder to an extremely small size with scale
place cylinder next to object, or anywhere you want really, close to the bed
drag cylinder up in scale making it longer without making it wider, once the cylinder contacts the bed, it will start lifting the rest of the parts/the part up into the air.
Slice with supports enabled.
Hope this randomly helps someone, because now that I've figured this out I may be combining a lot of single color prints more in the future to crank stuff out while I'm at work._

what is the status on this issue?

My issue is that with Arachne I cannot use "perimeters loop" feature, I like to use it for first layer with very fine details in XY (<1mm extrusions)

The options to solve this would be:
A) 'fix' (?) Arachne to be able to use "perimeters loop" (as a height range modifier)
B) add "Arachne perimeter generator" / "no Arachne perimeter generator" to "height range modifier" options
C) cut the part at the deisred height, stack them at same XY at desired height with the desired options from @TomaszSzt

BUT @estrangedwrenches method does NOT work for this application

best regards,

thank you for your amazing work

After so many years, this is still a problem. Why can't we just stack objects on top of each other ffs. So infuriating...

I just posted a draft pull request #11452 that makes everything float. You can still put an object on the bed by clicking the "Drop to bed" button for the object

It may need PR #11299 that makes exceptions about an object with no extrusions on layer 0 into a warning.

I've read this thread, and I am amazed that the inability to move an object it the Z axis is being (a) defended on theoretical grounds and (b) defended as "too hard" to implement.

Let's dispense with (b) first - it is ALREADY implemented -in the sense you CAN move the object in the Z plane, and it renders as such - but when you release the mouse it "snaps" back to ground. so no code is required to allow the move - just need the the ability to toggle that snap feature - perhaps some coding is required on the slicing soide - but I'm skeptical. We just need a "keep the nanny out of it" feature. kind of like when you have snap to grid on a drawing program, there is usually a way to override it temporarily (shift key or whatever).

More surprising to me is the "theoretical basis"argument, which is bunk. Many in this thread have already de-bunked it with examples, but here is mine (a real part for a model airplane):

The assembly consists of the hub, ring, and qty 3 arms. So there are 3 STL's, but I need three of Arm.stl. When I import the 3 STL's as parts of an assembly, everything is positioned correctly. But when I import the Arm.stl again as shown, I cannot raise it up into position.

Obviously, this would need supports regardless of orientation, but why won't PS allow me to position and slice it so supports can be generated?

The easy go-to workaround is to group objects in PrusaSlicer by using "add part" and then loading all the sub-parts of a print. This way you can stack stuff and adjust z-height as you wish.