burtoogle

Yes, the macos builds that you can find at https://www.dropbox.com/sh/s43vqzmi4d2bqe2/AAADdYdSu9iwcKa0Knqgurm4a?dl=0 have that setting. Please read the README.md file there.

Hello @upsetShrimp, I can't offer any magic solutions but it may be worth installing one of my builds as they are built slightly differently to the UM releases. You can find my builds at https://www.dropbox.com/sh/s43vqzmi4d2bqe2/AAADdYdSu9iwcKa0Knqgurm4a?dl=0. Please read the README.md file there.

Yes, turn off the wall overlap compensation setting(s).

Hi, I don't think we can help you unless you can provide further info. Please attach the project file (.3mf) so we can see what is happening and suggest a remedy. Thanks,

Cura does not cope well with walls that are not close to an even number of line widths wide. To be honest, it's a mess. You may get a reasonable print if you set the following. Line width to something less than the wall width (i.e. 0.6 in your example), overlap compensation on and mimimum wall flow to at least 50%. YMMV.

Hello @bortolotti57, welcome to the wacky world of 3d printing! The reason the layer view looks like that is because it is in "compatibility mode". Cura requires a certain level of OpenGL version (at least 4.1) to display the full layer view. If your graphics system cannot do that level, it falls back to the compatibility mode. That mode can also be forced with a preference but, by default, it should show the full layer view if it can. Either your graphics hardware is too old to provide the required OpenGL version or, more likely, the drivers installed on your system are out of date. Often, updating the drivers can solve this problem. Hope this helps.

You can also specify gyroid for the support infill.

The internet says that the AMD Barts is capable of supporting OpenGL 4.4 so I guess you need to update to a later driver?

Sorry, yes, I missed that. OK, well, there's your answer because in there it says: So the accelerated GL is version 3.3 and it needs to be 4.2 or greater. I am also using Mesa version 18.0.5 so it's not as if your drivers are old. Maybe your hardware simply doesn't support a later version of GL?

Yes, but what does glxinfo say?

I can't say for sure what's causing the problem but I have two suggestions: 1 - increase the value of the Maximum Resolution setting to something like 0.25, that should remove the short line segments that are in the gcode. Sometimes, very short line segments can cause visible artifacts. 2 - either reduce the number of walls to 2 or completely turn off the Compensate Wall Overlaps setting. The overlap compensation is buggy and can introduce artifacts. Hope this helps.

In stderr.log it shows the detected OpenGL version 2020-02-03 08:46:34,521 - DEBUG - [MainThread] UM.View.GL.OpenGL.__init__ [112]: OpenGL Version: 3.0 Mesa 18.0.5 It's saying that the version is 3.0, you need version 4.2 to get the full functionality. If you run glxinfo in a terminal what do you get in the ExtendedRendererInfo section, for example, this is what I see Extended renderer info (GLX_MESA_query_renderer): Vendor: Intel Open Source Technology Center (0x8086) Device: Mesa DRI Intel(R) HD Graphics 520 (Skylake GT2) (0x1916) Version: 18.0.5 Accelerated: yes Video memory: 3072MB Unified memory: yes Preferred profile: core (0x1) Max core profile version: 4.5 Max compat profile version: 3.0 Max GLES1 profile version: 1.1 Max GLES[23] profile version: 3.2

Thanks @ahoeben, your advice was good. I'm sure I'd tried something similar before but it didn't work. Anyway, it appears to work just fine (on Linux, at least).

Man, it's confusing, fieldOfView on github is ahoeben here and burtoogle here is smartavionics on github. Who are these people? Anyway, thanks for the hint, I'll have a play with that tomorrow.

Let's ask an expert. Hi @fieldOfView, do you know how to detect when Cura has the keyboard/mouse focus?

If you minimize Cura, it should stop reading events from the spacemouse. I wanted to detect when Cura lost the focus but failed to achieve that so what it does now is the next best thing.

https://github.com/smartavionics/RawMouse It's not really what you are asking for but it does allow the spacemouse to work on all 3 platforms (Linux, MacOS and Windows).

What's the error? Any more info?

Can you not use relative extrusion as was suggested above?

Yes, maybe it's something like that. I will investigate and try and fix that.

There is some discontinuity in the pitch movement and also I have noticed the new rolling movement can cause the view to go blank when near the inverted position. I am still using what is essentially the same rotation code for yaw and pitch as the mouse uses. I am not getting glitches or blanks for "normal" moves/rots/zooms, i.e. no extreme angles or positions.

Do you even have jumpy motion when looking at the prepare view? For me all motion is smooth there. When looking at the preview (sliced), it can be jumpy depending on how big/complex the model is. Obviously depends on GPU performance.

Hi @DivingDuck, I have added support for the roll axis and made a new release (1.0.3). Your config file will need to be altered. Change targets rotx to rotyaw, roty to rotpitch and none to rotroll.

Hi @DivingDuck, thanks for the feedback. I can understand your wishes. As you know, at the moment, RawMouse simply emulates the normal 2D mouse so as that can't roll then neither does RawMouse. I have started toying with support for other targets that would manipulate the view differently. So I have tried using a 3 axis tumble so you can roll, pitch and yaw the camera view but, to be honest, I found it difficult to use. Also, if you then use the 2D mouse, the view will snap back to zero roll which is a bit disconcerting. I will do more work on this when I get the time. I like the idea of using the 2d mouse to select a point to be rotated around and I will look into how that could be achieved.

Hi @Noisettetbou, thanks for the feedback. What kind of objects are you printing using the Schwarz D infill?