Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Changing scale factors through "Object manipulation" sidebar doesn't always work #2510

Closed
wavexx opened this issue Jun 13, 2019 · 6 comments

Comments

@wavexx
Copy link
Contributor

commented Jun 13, 2019

Version

Current version from master: 821ca0e

Operating system type + version

Linux (Debian unstable) / X11

Behavior

I wasn't able to get a reproducible scenario for this, so I apologize for the incompleteness.

  • Drop some objects on the build-plate
  • Do some [magic stuff]
  • Select an object on the build plate
  • Select one of the "scale factors" in the "Object manipulation" sidebar

As you do this, the arrow gizmos appear on the object, as expected

  • Change any of the scale values, which are locked by default (for uniform scaling)
  • As you focus out, the other (linked) values are left unchanged. The the axis that was changed is left as-is, but it is ignored.

Here I selected one object on the build plate, changed the X scale to 102 without touching the "link" button (which has been left on by default):

2019-06-13T180945

the object is not updated (no scaling gets applied to X) and neither were the linked YZ (my change was completely ignored), but you can see 102 in the input box...

However, if I deselect the object and select it again and attempt to change the X scale again my inputs are accepted.

I have no idea what actions need to be performed to put slic3r into this state. I generally prepare several build-plates and export the g-code in the same session, so there might be multiple things going on...

@enricoturri1966

This comment has been minimized.

Copy link
Collaborator

commented Jun 14, 2019

Maybe related to #2490

@wavexx

This comment has been minimized.

Copy link
Contributor Author

commented Jun 14, 2019

Mmmh, looks like. I generally have background processing on, so I never have to slice manually.
With background processing this normally works.

If I disable background processing and then slice the view is switched to preview. When switching back it's always reproducible.

So it might be related to view switching too (although just switching view without slicing doesn't trigger the issue)

@bubnikv

This comment has been minimized.

Copy link
Collaborator

commented Aug 1, 2019

Please test with the upcoming PrusaSlicer 2.1.0-alpha1. Thanks.

@wavexx

This comment has been minimized.

Copy link
Contributor Author

commented Aug 5, 2019

The behavior changed.

Now the input field is reset to the previous value when focus is lost in some circumstances.
See this video:

https://www.thregr.org/~wavexx/tmp/VID_20190805_171041.mp4

Notice how the first change in % from 100 to 102 is ignored, but if I try with a larger value it works (?).
It also happens when I do the following:

  • start new project
  • import (not load) the attached sample

test.zip

  • Click away to deselect, then click on a single object
  • Change scale from 100 to 102
@bubnikv

This comment has been minimized.

Copy link
Collaborator

commented Aug 23, 2019

This issue will be fixed in PrusaSlicer 2.1.0-beta. Closing.

@bubnikv bubnikv closed this Aug 23, 2019
@alexwhittemore

This comment has been minimized.

Copy link

commented Sep 20, 2019

I was having an issue in 2.0 that, if I tried to change (unlocked) scale factors by small precise amounts, the other two dimensions would change too. For instance, trying to set (x,y,z) = (101.5, 101.5, 99) I'd set X=101.5, Z=99, and Y would jump to 102.35 or some such, then when I set Y=101.5, X would drop to 100.3 or some such, repeat. Made it basically impossible to iterate on an HTPLA part I was heat treating.

I can only assume that issue is related to this one, because I can't find any other more accurate report, so I just came here to say: it's fixed in 2.1, thanks so much for all the work to do that!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.