Unexpected Behavior of Bridging / on solid Layers.

[Ksanto 1]

Hey Folks,

 

befor opening a Report on GitHub (Cura 5.4.0) I wanted to ask if anybody can tell me if this is the intended behavior:

 

I try to force Cura to use bridging on a specific Part and have to bump up Bridge Skin Support Threshold to 95% (used the provided Normal Profile for Anycubic i3 Mega for my exampl) so bending of the Part would be easier / more stable. Thing is, the bridging direction is not uniform and I think I alredy understood why, see the picture:

 

Because the bridging is happening inside the top Layer, the shortest distance between two walls is inside the top layers, so the direction follows a sub optimal Path for the intended bridging area. My understanding of bringing always was that bridging would happen only between two outer walls.

 

So, is this the intended behavior?

 

 

Regards

Ksanto

Edited October 5, 2023 by Ksanto

[Slashee_the_Cow 279]

I'll admit I'm no expert on bridging (so the problem could be there), but I know Cura 5.4 has some bugs when it comes to slicing, and bridges seem to be one of the things that make it show up more. If it is this bug, try setting Mesh Fixes > Maximum Resolution to 0.5mm, and if that doesn't work, try reducing it by 0.05m or 0.1mm at a time and see if it makes a difference. And if that doesn't work, try installing 5.3.1 (don't need to uninstall 5.4, they're happy to exist side by side) and slicing it in that. And if that doesn't work, wait for someone a lot more experienced than me to reply to the thread.

[Ksanto 1]

Appreciate your efforts. I already tinkered with Mesh fixing resolution because of the protruding line bug. Also consideres to install a older versions but didnt want to go down the rabit hole to install/test multible verions (stopped with the behavior of hoarding old cura versions, somewhere on the way between 3 and 4, because it confuses preprocessing CAD programs alot).

Edited October 5, 2023 by Ksanto

[Slashee_the_Cow 279]

6 minutes ago, Ksanto said:

Also consideres to install a older versions but didnt want to go down the rabit hole to install/test multible verions

I'm not asking you to go down the rabbit hole. Just two versions, tops (try 4.13.1 if 5.3 doesn't work). They'll happily live side by side. But slicing errors, often in situations like this are a known problem with 5.4, so it's the top candidate for "things to try that either fix it or eliminate it as a possibility".

[Ksanto 1]

Not the parallel installtion is the hassle, but the insall <old version>, not working -> next, insall <old version>, not working -> next ...

 

there is a clear answer, is this intended or not. I'm not some kind of software archaeologist whos mission is to find the last version on which it works as he expected. It could also be the new way it works NOW.

 

Regards

Ksanto

Edited October 5, 2023 by Ksanto

[Slashee_the_Cow 279]

49 minutes ago, Ksanto said:

Not the parallel installtion is the hassle, but the insall <old version>, not working -> next, insall <old version>, not working -> next ...

 

there is a clear answer, is this intended or not. I'm not some kind of software archaeologist whos mission is to find the last version on which it worke as he expected. It could also be the new way it works NOW.

I'm not asking you to test version after version. Just a single version (5.3), as a comparison to a version which is known to have bugs. If it works fine in 5.3, it's probably one of the bugs in 5.4. If it doesn't work fine in 5.3, then we've eliminated something which has a high chance of causing this problem.

 

I want to help you. It's why I lurk around here, to help people. But I can't help you if you're looking for a simple yes or no answer to a problem which has a high number of variables if you're not willing to do a bit of troubleshooting to reduce that number.

 

At the very least, if you could provide the Cura project file (.3mf, in Cura go to File > Save Project) for myself and others to be able to test that possibility (and others) ourselves, that would help.

[Ksanto 1]

It is indeed simple yes or no answer with no variables. But not for us both. Etherther developers intendet it to be the hole layer or not. But only they can tell. A third option for people not involved, like us both, is to say that one did not heard of anyone saying neither one thing nor the other, as I did to my self after failing to find anything regarding this behavior.

 

I did deliberately not provide the project file because I could show that the problem can be recreated with on-board resources. It would be less hassle for you to add the printer and/or use the integrated profile to make sure there it is not a problem with my installation, wich could be translate to the project file, than me going through the process of downloading the installer file (which is a long way around as our company has restricted teh download oft executables) and installing it. But either way, here you have.

 

Regards

Ksanto

bridging.3mf

[Slashee_the_Cow 279]

2 hours ago, Ksanto said:

It is indeed simple yes or no answer with no variables

Variables:

• Version of Cura used
• Model
• Printer
• Bridge settings
• All the other slicing settings
• Need I go on?

Anyway, the problem isn't anything wrong with 5.4. Take that as an "I told you so" if you want.

 

The problem is that parts of layer 13 don't sit upon anything, it's the first layer that produces skin for some areas.

These screenshots are set with Colour Scheme set to Line Type. Especially when the problem is with certain types of lines, it's much more useful than flow.

Here's the print midway through that layer, before it's printed any skin:

 

Here's the first part of skin it prints:

 

It's starting with the infill and then doing the walls because there's something there that it can attach to. It then completes that lap:

 

Then it starts doing some horizontal work:

 

So why does it do the long horizontal lines? It's looking for the shortest route between two best supported areas. If we look at the layer below, there is absolutely no support in that gap:

Where it does the long horizontal lines, the first line of skin that was printed is the only support that exists along that gap. It hasn't printed the skin in the shorter horizontal areas because it's bridging first so that the regular skin can match. So why not do the short lines between the walls and the infill first? Because then there isn't a valid path from one wall to the other:

If it did the short lines first, it would be a bunch of vertical lines in between a bunch of horizontal lines, and it works to make all the skin in an area the same direction. So why doesn't it do the whole thing in vertical lines? Because for the majority of the area, the best supported part is between the side walls and the infill, because there's already skin below it, and none of them have to cross a gap.

 

So then it does the extension. The first skin it draws is against the infill, then goes around anticlockwise:

 

Then it does the lines:

 

So why is it doing them along that vertical axis instead of the shorter, horizontal lines? The answer again lies in the lower layer:

There's no support in that gap. It does all the lines in each area in the same direction (duh). But wait, earlier it was doing horizontal lines across a big gap so that all the lines didn't have to cross a little gap? Yeah, but remember, it's looking for lines between the best supported areas. If we look at it before it starts filling in:

The gap area has no support whereas it considers the already existing geometry (the infill) as a supported area. So by drawing the lines vertically, then it's doing all of the lines so that they start and end at the best support, rather than doing some lines where there's no support. There's not enough pre-existing area where horizontal lines are the obvious choice to outweigh the few lines that aren't supported. The bigger area had a lot of area where horizontal lines were the obvious choice because they didn't have to cross gaps.

 

Can this behaviour be changed? Not sure. You could try playing with Top / Bottom > Top/Bottom Line Directions (it's a series of angles at which the lines are drawn) to be all verticals/horizontals if you want, but you're still going to have this mismatched bit. So if they're diagonal by default, why doesn't it just bridge diagonally?, some might ask. Answer: the bridging is stupid. It first looks for adjacent (which in this context means parallel) skin to bridge to.

 

(And yes, I did need your project file to figure this out, because then I could actually see the order things were being printed, the line types, and the layers above and below)

Edited October 5, 2023 by Slashee_the_Cow
Deleted unused pictures that had been replaced

[Ksanto 1]

2 hours ago, Slashee_the_Cow said:

Variables:

• Version of Cura used
• Model
• Printer
• Bridge settings
• All the other slicing settings
• Need I go on?

 

Not that it does have any meaning, as it was and is a general question of it being working as intended:

 

NO unknown Variables:

• I specified the version and so the question was specifically about 5.4.0
•  the question was generally on the intention of the behavior, I do want to print other things, not only this model for the rest of my life
• I did state the type of my printer (Anycubic i3 Mega)
• I did state that I choose the standard normal profile for my printer and have bumped up the Bridge Skin Support Threshold to 95%
• see above
• no, you should consider being wrong not right

2 hours ago, Slashee_the_Cow said:

Anyway, the problem isn't anything wrong with 5.4. Take that as an "I told you so" if you want.

I cant wait but I never said it was a bug or anything "wrong with 5.4.". If I had done this, I would have said so. However, I deliberately asked if it behaved as intended before filing a bug report, before claiming that it was a bug. From this point on, I consider you a Fanboy. Block me if you want, my special snowfalke.

 

2 hours ago, Slashee_the_Cow said:

The problem is that parts of layer 13 don't sit upon anything, it's the first layer that produces skin for some areas.

Isn't this the purpose of bridges. Bridging between layers/areas over thin air? aka unsupported? 

 

 

2 hours ago, Slashee_the_Cow said:

These screenshots are set with Colour Scheme set to Line Type. Especially when the problem is with certain types of lines, it's much more useful than flow.

fair enough, technically I agree. but I found that the contrast between lines and air did not come out very good with yellow to grey and the distinction between line types was preserved.

 

2 hours ago, Slashee_the_Cow said:

It's starting with the infill and then doing the walls because there's something there that it can attach to. It then completes that lap:

So far I would agree.

 

2 hours ago, Slashee_the_Cow said:

Then it starts doing some horizontal work:

 

 

exactly this is my problem

 

2 hours ago, Slashee_the_Cow said:

So why does it do the long horizontal lines? It's looking for the shortest route between two best supported areas. If we look at the layer below, there is absolutely no support in that gap:

Again: no support=bridging=works as intended. However: The shortest route between two best supported areas would still be all "vertically" as you phrase it later.

 

2 hours ago, Slashee_the_Cow said:

Where it does the long horizontal lines, the first line of skin that was printed is the only support that exists along that gap. It hasn't printed the skin in the shorter horizontal areas because it's bridging first so that the regular skin can match. So why not do the short lines between the walls and the infill first? Because then there isn't a valid path from one wall to the other:

If it did the short lines first, it would be a bunch of vertical lines in between a bunch of horizontal lines, and it works to make all the skin in an area the same direction. So why doesn't it do the whole thing in vertical lines? Because for the majority of the area, the best supported part is between the side walls and the infill, because there's already skin below it, and none of them have to cross a gap.

Very informative, even if I do not understand what it has to do with support (are we still talking about bridges? - see definition above) nor what matching the skin means. Why would there not be a valid path from one side to the other when the "rectangular areas" between the infill and the wall would be filled first?  Then there wouldn't be a valid path of the second bridging area also? What are your sources?

I of course would expect it to make them all the same direction and would say it would be nonsense if it tried to attach vertical bridges to horizontal bridges. So fare, now for the all vertical lines solution: That would be the expected outcome under the given circumstances. What with the nonsense about the Support? See definition of bridging, it should not have any difference if there is something ot nothing underneath. What are your sources?

 

3 hours ago, Slashee_the_Cow said:

So then it does the extension. The first skin it draws is against the infill, then goes around anticlockwise:

 

Then it does the lines:

 

So why is it doing them along that vertical axis instead of the shorter, horizontal lines? The answer again lies in the lower layer:

There's no support in that gap. It does all the lines in each area in the same direction (duh). But wait, earlier it was doing horizontal lines across a big gap so that all the lines didn't have to cross a little gap? Yeah, but remember, it's looking for lines between the best supported areas. If we look at it before it starts filling in:

The gap area has no support whereas it considers the already existing geometry (the infill) as a supported area. So by drawing the lines vertically, then it's doing all of the lines so that they start and end at the best support, rather than doing some lines where there's no support. There's not enough pre-existing area where horizontal lines are the obvious choice to outweigh the few lines that aren't supported. The bigger area had a lot of area where horizontal lines were the obvious choice because they didn't have to cross gaps.

Works as expected, still don't understand why supported area should have any influence. What are your sources?

 

4 hours ago, Slashee_the_Cow said:

Can this behaviour be changed? Not sure. You could try playing with Top / Bottom > Top/Bottom Line Directions (it's a series of angles at which the lines are drawn) to be all verticals/horizontals if you want, but you're still going to have this mismatched bit. So if they're diagonal by default, why doesn't it just bridge diagonally?, some might ask. Answer: the bridging is stupid. It first looks for adjacent (which in this context means parallel) skin to bridge to. 

Changing Top/Bottom Line Directions is reported to do nothing in threads back as far as 2018. Beside I do like my Top/Bottom Line Directions for the other layers as is. The wall in vertical direction are also adjacent/parallel!

 

One correction: the bridging is only as stupid as it's developer. 😉 In other words, I do not judge, this is the reason I phraised my question as is. I'm not in the position to criticise decision regarding code/development.

 

3 hours ago, Slashee_the_Cow said:

(And yes, I did need your project file to figure this out, because then I could actually see the order things were being printed, the line types, and the layers above and below)

Everything for nothing as nothing of this answers my core question:

10 hours ago, Ksanto said:

is this the intended behavior?

This question only can be or could have been direcly answered by somebody whith autorety by Ultimaker (Adminestrator for example) or somebody involved with development. My expectation was finding help at finding the answers somewhere by an official source or get answered by an official source.

 

 

We only achieved to debate whether it is/would be better one way or the other. Nevertheless, thank you for your efforts.

 

 

So why did I even bother to reply to you anymore? Well, You certainly made an effort and I even learned one thing or another (perspectives).  But boy, you should find another enemy for yourself and accept the you can sometimes not fulfill every demand in the relative position you find yourself in.

 

 

Sleep well

Ksanto

 

 

 

[Slashee_the_Cow 279]

7 hours ago, Ksanto said:

NO unknown Variables:

• I specified the version and so the question was specifically about 5.4.0
•  the question was generally on the intention of the behavior, I do want to print other things, not only this model for the rest of my life
• I did state the type of my printer (Anycubic i3 Mega)
• I did state that I choose the standard normal profile for my printer and have bumped up the Bridge Skin Support Threshold to 95%
• see above

I wasn't saying which variables were unknown. I was saying what variables exist and can be a factor in a situation like this. Some models would not exhibit this behaviour at all purely because of how the bridging algorithm works on their design, so I couldn't just pick a random model to test with. As for point four, you didn't say what quality preset you were using, nor if you were using a profile for a particular material (which shouldn't affect something like this, at least in the slicing, but many of the slicing settings interact in ways you wouldn't see coming).

7 hours ago, Ksanto said:

no, you should consider being wrong not right

Is this how you always treat people trying to help you?

 

7 hours ago, Ksanto said:

11 hours ago, Slashee_the_Cow said:

Anyway, the problem isn't anything wrong with 5.4. Take that as an "I told you so" if you want.

I cant wait but I never said it was a bug or anything "wrong with 5.4.". If I had done this, I would have said so. However, I deliberately asked if it behaved as intended before filing a bug report, before claiming that it was a bug. From this point on, I consider you a Fanboy. Block me if you want, my special snowfalke.

In case that last bit didn't tip you off, I was explicitly stating that I was wrong and that you could hold at least that part over me. I'm pretty sure snowfalkes snowflakes never admit they were wrong, and nobody has the heart to tell them if they are. I have no idea what you think I'm a "Fanboy" fangirl of though, unless it's "blame 5.4", but you're not the first person to tell me that. I don't know if I can block you but I am sort of offended you'd think I'd consider it, I'm not that sort of person, although I can't expect you to know that, so no offence personally aimed at you.

 

7 hours ago, Ksanto said:

11 hours ago, Slashee_the_Cow said:

The problem is that parts of layer 13 don't sit upon anything, it's the first layer that produces skin for some areas.

Isn't this the purpose of bridges. Bridging between layers/areas over thin air? aka unsupported? 

It's exactly the purpose of bridges. But I was exemplifying the point that parts of it were the problem, not all of it.

 

7 hours ago, Ksanto said:

12 hours ago, Slashee_the_Cow said:

These screenshots are set with Colour Scheme set to Line Type. Especially when the problem is with certain types of lines, it's much more useful than flow.

fair enough, technically I agree. but I found that the contrast between lines and air did not come out very good with yellow to grey and the distinction between line types was preserved.

And you expect me to go through the print profile figuring out the flow rate for each kind of section why?

 

7 hours ago, Ksanto said:

Again: no support=bridging=works as intended. However: The shortest route between two best supported areas would still be all "vertically" as you phrase it later.

The bridges have to connect to something at each end, and it picks whichever part is strongest, which is usually because it either has something underneath or is considered to be a strong itself (like walls). What it connects to at each end is referred to as its support, like a real bridge. It has nothing to do with supports printed in the model to hold parts above the build plate (or other parts of the model), other than the name.

 

Also, "vertically" as I phrase it? Technically inaccurate, but it's easier than saying "depthwise" or "along the Y axis", also especially because if you're looking at a single slice (like a layer) from a 2D perspective, the Y axis is vertical. Horizontal is objectively correct in my usage here because I am using it to refer to lines that run parallel to the X axis.

 

7 hours ago, Ksanto said:

I of course would expect it to make them all the same direction and would say it would be nonsense if it tried to attach vertical bridges to horizontal bridges. So fare, now for the all vertical lines solution: That would be the expected outcome under the given circumstances. What with the nonsense about the Support? See definition of bridging, it should not have any difference if there is something ot nothing underneath. What are your sources?

The thing here is that Cura prints whole skin areas (generally with the edges defined by other types of feature, like walls or infill) as one, with the same settings, so that it looks consistent because it's expected to be seen. So instead of just bridging this area (highlighted in pink):

 

It's giving the same treatment to this area, because it's the biggest polygon that can be made without hitting another feature type:

And the vast majority of that area is best served by horizontal lines, so the bridge follows suit.

 

The other area:

If it used horizontal lines here, then a more significant proportion of it would be bridges with nothing underneath them, so it determines that vertical lines better serve the purpose.

 

 

8 hours ago, Ksanto said:

12 hours ago, Slashee_the_Cow said:

(And yes, I did need your project file to figure this out, because then I could actually see the order things were being printed, the line types, and the layers above and below)

Everything for nothing as nothing of this answers my core question:

18 hours ago, Ksanto said:

is this the intended behavior?

This question only can be or could have been direcly answered by somebody whith autorety by Ultimaker (Adminestrator for example) or somebody involved with development. My expectation was finding help at finding the answers somewhere by an official source or get answered by an official source.

My intention was to provide all the evidence and reasoning possible behind why the bridging behaviour acts like it does.

 

Is it working as intended? If I'm correct about the logic I've discerned behind its behaviour, yes.

 

I don't think any of the Cura developers actively read the forums (you'd need to wait for @gr5 to pop in and confirm that) so if you want an answer straight from the proverbial horse's mouth, you would need to go to the Github repo and ask there, but I know they're generally pretty busy, some being volunteers (it is open source, after all) so I'm not sure how quickly you'd get a response.

 

8 hours ago, Ksanto said:

the bridging is only as stupid as it's developer. 😉

I'm not sure if the wink emoticon means you're joking or not, but that is not the way to endear yourself to software developers to get an official answer to your question. This stuff is a lot harder than most people think, especially a program with so many proverbial moving parts (different situations it has to be able to adapt for) as a slicer.

No, I'm not one of the Cura developers, but I am a programmer, and I have dived through the Cura source code a little bit, and trust me when I say to dive all the way down would require the submarine James Cameron used to go through the Mariana Trench, which is why lots of people work on different sections, more than me having a curious peek in.

[Ksanto 1]

7 hours ago, Slashee_the_Cow said:

I wasn't saying which variables were unknown. I was saying what variables exist and can be a factor in a situation like this. Some models would not exhibit this behaviour at all purely because of how the bridging algorithm works on their design, so I couldn't just pick a random model to test with.

But surely while having roughly the same proportions. Having a long bridging edge where support is needed otherwise while having two smaller areas divided by infill. But it was never the point to validate the behavior in special but in general, if the bridges are intended to extend (in whatever case) over the whole layer in this manner. Nether you nor I can tell, because we are not involved in the development. The examples in the "Introducing The Experimental Bridging Settings" thread suggest something different.

 

7 hours ago, Slashee_the_Cow said:

As for point four, you didn't say what quality preset you were using, nor if you were using a profile for a particular material (which shouldn't affect something like this, at least in the slicing, but many of the slicing settings interact in ways you wouldn't see coming).

On 10/5/2023 at 10:25 AM, Ksanto said:

bump up Bridge Skin Support Threshold to 95% (used the provided Normal Profile for Anycubic i3 Mega for my exampl)

You have a point in me not communicating the Material preset, but it does merely change the general temperatures.

 

7 hours ago, Slashee_the_Cow said:

Is this how you always treat people trying to help you?

Only people who getting cocky while missing the point. I Specifically made clean through my writing style with the slashed "wrong" and the following correction to "not right" (totally different statements in this case) that there can be different viewpoints on the same topic and that I accept your point of view. Hence your point of view is that this could be a isolated case, but my viewpoint is that it seems strange this is even intended in general. That's why I made clear before I listed the points that the following would be pointless. I appreciate your efforts, but you should focus your energy to other things then shooting around the target.

 

7 hours ago, Slashee_the_Cow said:

In case that last bit didn't tip you off, I was explicitly stating that I was wrong and that you could hold at least that part over me. I'm pretty sure snowfalkes snowflakes never admit they were wrong, and nobody has the heart to tell them if they are. I have no idea what you think I'm a "Fanboy" fangirl of though, unless it's "blame 5.4", but you're not the first person to tell me that. I don't know if I can block you but I am sort of offended you'd think I'd consider it, I'm not that sort of person, although I can't expect you to know that, so no offence personally aimed at you.

It did not. Maybe I missed the point because I'm not a native english speaker, but your text came across as an accusation followed by an lecture after the cocky and point missing "Need I go on?". Never did I expect to see this sentence out of my perspective, but yours.

It just seems like you're obsessively trying to defend/explain decisions/processes that I had not questioned at all at this point. An overreaction that is usually attributed to fanboys. The algorithm is obviously working like this now/at the moment, but is this behavior intended? But in the given context I will refrain to use the term Fanboy/girl and use the more neutral term Fanatic (not in the context of being a fan to sth/sb anymore but in the general therm as fan comes from fanatic), if at all. After all, I'm kind of a fanatic myself in that I want to make it clear to you that you are fighting a battle that has no enemy. Furthermore I apologize for my assumption that you were a bubble-filtering snowflake. That was based on the assumption that you were also a Fanboy/girl in combination with the misunderstanding of the quotet sentence.

 

7 hours ago, Slashee_the_Cow said:

And you expect me to go through the print profile figuring out the flow rate for each kind of section why?

No I expect nothing from you, beside maybe refer me to examples or statements that were given/made anywhere else and to accept that you can not do anything in this case as you personally cannot answer the question if this behavior is intended. Everything you have achieved is to lay out why it is bridging like it is, but not if this is intended.

 

7 hours ago, Slashee_the_Cow said:

The bridges have to connect to something at each end, and it picks whichever part is strongest, which is usually because it either has something underneath or is considered to be a strong itself (like walls). What it connects to at each end is referred to as its support, like a real bridge. It has nothing to do with supports printed in the model to hold parts above the build plate (or other parts of the model), other than the name.

As I have already stated, I did not questioning how it is doing what it does in the first place. Only did I react to your assumptions/statements and gave my own assumptions. If this is how it's intended to work in the long term I can work with that but I would be mad if I adapt to it and in the next version it is working totally different.

 

7 hours ago, Slashee_the_Cow said:

Also, "vertically" as I phrase it? Technically inaccurate, but it's easier than saying "depthwise" or "along the Y axis", also especially because if you're looking at a single slice (like a layer) from a 2D perspective, the Y axis is vertical. Horizontal is objectively correct in my usage here because I am using it to refer to lines that run parallel to the X axis.

This was not a criticism, I only wanted to clarify that I adopt your wording as a common language within this thread.

 

7 hours ago, Slashee_the_Cow said:

The thing here is that Cura prints whole skin areas (generally with the edges defined by other types of feature, like walls or infill) as one, with the same settings, so that it looks consistent because it's expected to be seen. So instead of just bridging this area (highlighted in pink):

But Bridges are not Skin and Cura it is capable of for example printing Infill right next to Skin. As established just a suggesting assumption opposing your Statement. It does not help me to understand why it does this more than understanding what it does if I can not assume that it is intended what it is doing. What would help me is to know that this is intended although it seems irrational to ME.

 

7 hours ago, Slashee_the_Cow said:

It's giving the same treatment to this area, because it's the biggest polygon that can be made without hitting another feature type:

And the vast majority of that area is best served by horizontal lines, so the bridge follows suit.

But (a) is still shorter than (b) and following along (a) fits the definition of shortest path over unsupported area best. Still just a suggesting assumption opposing your Statement. yada yada yada

 

7 hours ago, Slashee_the_Cow said:

The other area:

If it used horizontal lines here, then a more significant proportion of it would be bridges with nothing underneath them, so it determines that vertical lines better serve the purpose.

This area was never up for debate. It is in any way the shortest path (b) over the unsupported area. yada yada yada

 

7 hours ago, Slashee_the_Cow said:

My intention was to provide all the evidence and reasoning possible behind why the bridging behaviour acts like it does.

 

Is it working as intended? If I'm correct about the logic I've discerned behind its behaviour, yes.

 

I don't think any of the Cura developers actively read the forums (you'd need to wait for @gr5 to pop in and confirm that) so if you want an answer straight from the proverbial horse's mouth, you would need to go to the Github repo and ask there, but I know they're generally pretty busy, some being volunteers (it is open source, after all) so I'm not sure how quickly you'd get a response.

Even while I think that you are correctly presented its superficial workings this does not preempt any possible that this is not a unintended outcome. Your attempts at explanations honor you, but unfortunately they don't help me to decide whether I put up with it or whether I get more worked up over it (it's escalated quite a bit now) than here / what was originally planned.

 

7 hours ago, Slashee_the_Cow said:

I'm not sure if the wink emoticon means you're joking or not, but that is not the way to endear yourself to software developers to get an official answer to your question. This stuff is a lot harder than most people think, especially a program with so many proverbial moving parts (different situations it has to be able to adapt for) as a slicer.

No, I'm not one of the Cura developers, but I am a programmer, and I have dived through the Cura source code a little bit, and trust me when I say to dive all the way down would require the submarine James Cameron used to go through the Mariana Trench, which is why lots of people work on different sections, more than me having a curious peek in.

That was my way of trying to tell you that it could be quite offending in it selfe to call the bridging algorithm stupid. You have to read and Understand (quote! to) the sentence together with the sentences that where following to keep/understand its meaning.Im some kind of a developer myself, more on the mechanic/electric side but you need some code to wake the ghost in the machine. So I would be offended by someone labeling my algorithm stupid (beside myself) if is does what it is intended to do. I do not know how to make myself more clear about my intentions/asking.

16 hours ago, Ksanto said:

this is the reason I phraised my question as is. I'm not in the position to criticise decision regarding code/development.

 

 

Regards

Ksanto

 

Edited October 6, 2023 by Ksanto
deleted half / residual sentence

[Slashee_the_Cow 279]

Let's drop the personal stuff and limit ourselves to the matter at hand. There really only seems to be one bone of contention left there.

 

41 minutes ago, Ksanto said:

But Bridges are not Skin and Cura it is capable of for example printing Infill right next to Skin.

Bridges are considered skin when they're in a skin section (you'll see in the layer view with line type, they're the same yellow as the rest of the skin), and if a skin section has bridges, the whole section is considered bridges. Your example shows both the long horizontal bridges of the large section and the vertical bridges of the small section printing next to the infill, so I'm sorry if I'm misunderstanding you, but I don't see the point of the second half of that statement.

 

41 minutes ago, Ksanto said:

But (a) is still shorter than (b) and following along (a) fits the definition of shortest path over unsupported area best. Still just a suggesting assumption opposing your Statement. yada yada yada

You're not accounting for the infill breaking up the large horizontal area. That gives us a lot of short horizontal lines (c)

And since it treats the whole skin area as bridges, those short horizontal lengths are by far the best bridges (even if they're not areas that need to be bridged); they have something below them and are attached to a strong wall on one side and a supported wall (the one around the infill) on the other. Since a skin area will always have all lines running in the same direction (assuming you're using the lines pattern, although I don't know if bridges will always use the line pattern regardless of the top/bottom pattern setting, it's not a situation I've ever had to deal with) it uses the worst case for a few of the bridged lines because it's the same direction as the best case for so many of the other lines (which as I said, don't need to be bridges, but are considered to be).

Edited October 6, 2023 by Slashee_the_Cow

[Slashee_the_Cow 279]

Okay, by my own admission I'm a little embarrassed for myself that this took me so long to realise, but if editing your model is feasible (even if you only have the STL, you can edit that, it's just a lot of hassle), but I think the long horizontal lines could be fixed (I'm defining "fixed" as replaced by short vertical ones which are a lot less likely to fail) by just adding a couple of thin inner walls on that layer, which will break it into three disparate areas, and the long horizontal span that needs to be bridged would be its own area, which would hopefully be bridged with vertical lines:

Edited October 6, 2023 by Slashee_the_Cow
fixed minor grammar stuffup

[Ksanto 1]

1 hour ago, Slashee_the_Cow said:

Let's drop the personal stuff and limit ourselves to the matter at hand. There really only seems to be one bone of contention left there.

I really would like to agree with you, but you still do not understand my point and your second replay while I'm writing this lines is the biggest evidence for this. You simply do not get it, and this is a problem with the you you. The Personal you. I do not need an analysis of the Statu Quo, I need evidence the this behavior will persist for the long term.

 

1 hour ago, Slashee_the_Cow said:

Okay, by my own admission I'm a little embarrassed for myself that this took me so long to realise, but if editing your model is feasible (even if you only have the STL, you can edit that, it's just a lot of hassle), but I think the long horizontal lines could be fixed (I'm defining "fixed" as replaced by short vertical ones which are a lot less likely to fail) by just adding a couple of thin inner walls on that layer, which will break it into three disparate areas, and the long horizontal span that needs to be bridged would be their its own area, which would hopefully be bridged with vertical lines:

As I already stated before:

2 hours ago, Ksanto said:

If this is how it's intended to work in the long term I can work with that but I would be mad if I adapt to it and in the next version it is working totally different.

So, yes, this possibility was there all along, and yes, I did already consider something like that. But that is and never was the Point of the Question.

 

2 hours ago, Ksanto said:

As I have already stated, I did not questioning how it is doing what it does in the first place. Only did I react to your assumptions/statements and gave my own assumptions.

I did repeat myself many times in many ways during our ongoing conversation, but this is the clearest example of it.

 

1 hour ago, Slashee_the_Cow said:

Bridges are considered skin when they're in a skin section (you'll see in the layer view with line type, they're the same yellow as the rest of the skin), and if a skin section has bridges, the whole section is considered bridges. Your example shows both the long horizontal bridges of the large section and the vertical bridges of the small section printing next to the infill, so I'm sorry if I'm misunderstanding you, but I don't see the point of the second half of that statement.

This is informative, thank you, but it doesn't matter in the context of the question. That you do not understand nor value the secont halfe of the statmen is a core problem with us. Even if it is lacking *two small* words I did miss due to fatigue, repeating myself like a broken record, over and over again:

2 hours ago, Ksanto said:

As established just a suggesting assumption opposing your Statement. It does not help me to understand why it does this more than understanding what it does if I can not assume that it is intended *to do* what it is doing. What would help me is to know that this is intended although it seems irrational to ME.

 

1 hour ago, Slashee_the_Cow said:

You're not accounting for the infill breaking up the large horizontal area. That gives us a lot of short horizontal lines (c)

yes I do, I did state specifically "... fits the definition of shortest path over unsupported area best". In my understanding of the defineiton of bridges, the "...the infill breaking up the large horizontal area" shuld never be toched in this manner by bridges as they never bridge any bridging area. To make it clear, again, yes, the algorythem ist filling the whole area uniformly, but this does not mean that this is making fully sense, nor that shis is intenden as is. But I also not in a position to demand change, I will happily adapt if it is confirmed to be as intended.

 

1 hour ago, Slashee_the_Cow said:

And since it treats the whole skin area as bridges, those short horizontal lengths are by far the best bridges (even if they're not areas that need to be bridged); they have something below them and are attached to a strong wall on one side and a supported wall (the one around the infill) on the other. Since a skin area will always have all lines running in the same direction (assuming you're using the lines pattern, although I don't know if bridges will always use the line pattern regardless of the top/bottom pattern setting, it's not a situation I've ever had to deal with) it uses the worst case for a few of the bridged lines because it's the same direction as the best case for so many of the other lines (which as I said, don't need to be bridges, but are considered to be).

A bridge with something below is called road. Yes, I only know of one bridging pattern (at the moment). Yes that's the status quo, and I could deal with that, if I can relay on it not changing in the long terme.

 

 

If it is not a problem with reading/writing comprehension (from your side/my side) I think what we have her is a "If the only tool you have is a hammer, you tend to see every problem as a nail" Situation. Your analytical way of problem solving does not allow you to say that you can not help in this situation but you also can also not refrain from trying. That seems to be what fueled my initial perception of you as a Fanatic in the first place.

 

 

Regards

Ksanto

Edited October 6, 2023 by Ksanto

[Slashee_the_Cow 279]

11 minutes ago, Ksanto said:

A bridge with something below is called road.

Or a walking path over a lake. Or a railway overpass. Or the thing a road sits on so you don't fall into the river below. Or the  (usually raised) area in a ship where all the main controls are. Or the top part of your nose.

 

None of those change the fact that because Cura has to look to make bridges in any part of that area, it has to make bridges in every part of that area, and since a road is a generally very stable surface, it's definitely a good place to put a bridge on. Even though you don't need a bridge sitting on top of a road.

 

It's working as intended. The fact that Cura is designed to make that whole skin area bridges, probably intended, so the line directions are consistent. The bridging algorithm: working as intended, because it's making bridges. It's far too simple an algorithm to account for situations like this.

 

I'm outta here. Cya. 🐄➡🚪

[Ksanto 1]

Now you get silly, I simply wanted to communicate how irrational your statement can seam. In gemany, when a comparison is bad, we say it is limping (The comparison is misleading). Once I saw someone in a Forum with this in his signature: Not everything that limps is a comparison.

 

I give you that this was not very precise, what I meant was "A bridge sitting on something below is called road. So directly below, not far below.

 

A bridge in the technical senses (3D printing is very technical, is it?) is known for not touching the thing it is bridging over (expect the occasional leg/piller)

 

1 hour ago, Slashee_the_Cow said:

Or a walking path over a lake.

A bridge is not "on" a lake, it is over the lake.

 

1 hour ago, Slashee_the_Cow said:

Or a railway overpass.

The bridge is not touching the rails, that would be a disaster.

 

1 hour ago, Slashee_the_Cow said:

Or the thing a road sits on so you don't fall into the river below.

now you mixing things up, that is not a comparison anymore

 

1 hour ago, Slashee_the_Cow said:

Or the  (usually raised) area in a ship where all the main controls are. Or the top part of your nose.

That are both not Bridges in the technical sense.

 

1 hour ago, Slashee_the_Cow said:

None of those change the fact that because Cura has to look to make bridges in any part of that area, it has to make bridges in every part of that area, and since a road is a generally very stable surface, it's definitely a good place to put a bridge on. Even though you don't need a bridge sitting on top of a road.

I was telling you all the time that wenn this is this what the developers decided to do I can work with it. I only wanted a confirmation because it seem very irrational compared to the definition of a bridges by Ultimaker by my understanding of it.

 

1 hour ago, Slashee_the_Cow said:

It's working as intended. The fact that Cura is designed to make that whole skin area bridges, probably intended, so the line directions are consistent. The bridging algorithm: working as intended, because it's making bridges. It's far too simple an algorithm to account for situations like this.

It seems you assume that it is working as intended because it is making something the can be interpreted as bridges. Thats a circular argument. Im right, because Im right. "far too simple" ther is an explanaiton/evidence for your assumption/statement! This is something I would trust you to judge better. One could have a conversation on this basis.

 

Bye

Edited October 6, 2023 by Ksanto

[Dustin 132]

Lets keep personal arguments outside of the community please.

It would be best to raise this question on github for the best response.

I am closing this thread as its no longer productive. 

[gr5 2,178]

After briefly looking through the images, I'm not sure if this behavior is intended or not.  I think maybe it is.  Anyway it's okay either way as there are employees that do triage.  So really the best thing to do is to log this on github.  To do so, go here:

https://github.com/Ultimaker/Cura/issues

 

You must have a github account (they are free) and then click "New Issue".  You will be guided.  Maybe include the best photos from above.  Maybe link to this thread but it's long and gets off topic so I'd summarize with images once again.

 

If you could create a drastically simpler model that shows the problem that would be good for everyone involved.