Softened and Hidden Lines problem getting ridiculous

hellnbak

@chris fullmer said:

It only works immediately after the problem occurs. I think Thom mentioned he has brought this up with the team and they said that its remarkably difficult to fix and its not high on their priority list, something along those lines. I could be wrong,

Chris

Well, thanks Chris. Even if it does work as you describe above, it won't be of much help to me. I can't be zooming out everytime I draw a line or do something else to my model. And that's what I would have to do to catch it immediately after it happens.

So Trimble is placing it low on their priority list because it would be too difficult to fix. That pretty much says it all as far as I'm concerned. SU is useless to me as it stands right now. I can't expect to make any progress on a model if I spend half my time just trying to get back to where I was.

Guess I should have expected this when I first discovered SU. Sooner or later everything good turns to crap.

jpalm32

Don't quit man! You are too good to give up.
Take a breath, crush a grape or take a long walk.

I have been where you are (No where near your talent) then started reading post from other S/W sites.
User paying 2-7 thousand and having the even bigger problems, version after version.

I rant & rave and go looking for the better SU and eventually come slithering back here.

I got jumped on for my comments that printing in SU is like a leap back to the 80's.

Hang tough!

pbacot

Need a plugin that watches for the event. If it cannot tell it apart from an intentional de-smoothing (one from a user command) then perhaps it can warn the user when more than a pre-set number of edges change state.

sonder

In our last discussion on the subject, we isolated the occurrence to having something selected, while you save the file. I've made a habit of deselecting before I save, and I haven't run into the Susie since.

thomthom

@pbacot said:

Need a plugin that watches for the event. If it cannot tell it apart from an intentional de-smoothing (one from a user command) then perhaps it can warn the user when more than a pre-set number of edges change state.

That would probably make SU very slow - watching and inspecting every edge.

@unknownuser said:

In our last discussion on the subject, we isolated the occurrence to having something selected, while you save the file. I've made a habit of deselecting before I save, and I haven't run into the Susie since.

It happens when SketchUp is minimized/restored and when SketchUp "whites out" (Save, Autosave, heavy processing - such as Sandbox tools etc.) You will see the window becoming unresponsive then flicker back into a reactive state again. That's when this happens.

Due to this bug I've also gotten into the habit of deselecting. I never keep a selection for any longer than strictly necessary. Ctrl+T
And when I notice the window has become unresponsive - for whatever reason - I always check my selection and open the Edit menu to see if there's a "Undo Soften Edges" item there.

TIG

As this issue seems related to having a selection when you do a save, can't we devise a ModelObserver that with onPreSaveModel remembers the current selection as an array, then clears the selection; and with onPostSaveModel adds that array back as the current selection ? Something like

class SoftEdgesSaverModelObserver < Sketchup;;ModelObserver
  def onPreSaveModel(model)
    ss=model.selection
    @ss=ss.to_a
    ss.clear
  end
  def onPostSaveModel(model)
    UI.start_timer(0.1, false){model.selection.add(@ss)} if @ss[0]
    ### wait a little to ensure it's done
  end
end
### then...
Sketchup.active_model.add_observer(SoftEdgesSaverModelObserver.new())

We'll also need an AppObserver to ensure that newly opened models etc have this new observer attached - meaning we need an enduring reference to the 'SoftEdgesSaverModelObserver' ...
I know some observers are flaky

thomthom

As I mentioned in my previous post - it's not just by save. (It's not even on every Save. It's any operation that makes SketchUp "white-screen". Drape will also trigger it.

TIG

A ToolsObserver might trap a 'white-out-making' event, but I must agree that it's going to be difficult to resolve, unless it's properly resolved in the base app code itself...

mitcorb

I tend to use Control-T a lot for deselection, but not for the conditions being described. It is usually when I need to move or copy move some item and something else is still highlighted.
I agree, for the conditions described in the posts above, some preventative would be very advantageous.

Chris Fullmer

Its interesting to see all the things you list Thom. This is a problem I RARELY have and I typically work on large terrains and cities. I find that I almost never ever leave things selected. I always deselect things by clicking on open space, or ctrl-t occasionally if its hard to see open space where I'm working. I never realized it might be a habit saving me from serious headaches. I also turn my autosave off because my models are always so large it takes a long time to save them so I only do it when I want to, typically before I run a script or close SU. So I think I happen to get around the problem by sheer coincidence.

Chris

pbacot

Thanks TT.

I guess I thought an "observer" would snooze up in a tower and when a "mass un-soft" occurred he'd hear the commotion and ring a bell!

Peter

thomthom

The mount of times I reopen my project at the office, only to find someone has made changes to it and not noticed the soften bug... x_X

Trogluddite

Phew! Like Chris, I think I've probably avoided this one by developing fine de-selection and CTRL-S reflexes (years of practice having to use CorelDraw! he he)

Maybe a little off topic, but personally, I find SU's selecting habits rather bit-and-miss in general, in a way that would seem to encourage this kind of unwanted behaviour. Pretty much all drawing software that I've used defaults to leaving the most recently drawn item selected - i.e. using a tool that creates new geometry, by default, clears any selection made prior to using the tool. This often catches me out when I've just drawn some small detail, and then go to use a selection-dependent action or the entity info box, without noticing that unwanted items are still selected - but not the one that I just drew, and would expect to be selected.
I'm not trying to suggest that the problem discussed here isn't a bug - just that an overhaul of how SU handles selections is probably overdue anyway, lending the opportunity to get this issue addressed too.

Chris Fullmer

Thom, what about a set of tools that could overide some of the basic SU functions that are nown to cause the problem? we could rewrite save, and explode for example to always deselct everything before doing the operation.

I wonder if that would actually help solve the problem in most cases.

sel = Sketchup.active_model.selection
exploder = sel[0]
sel.clear
exploder.explode

rv1974

I've got the same topicstarter issue (relatively rare thanks god)
My partial workaround is to use 'hiddenlayer' ruby by Jim (so unwanted edges will be constantly hidden in all scenes). The trick is to set up the one constant layer name for hidden stuff (via your default starting template)

thomthom

@chris fullmer said:

sel = Sketchup.active_model.selection
exploder = sel[0]
sel.clear
exploder.explode

Why explode stuff?

@chris fullmer said:

Thom, what about a set of tools that could overide some of the basic SU functions that are nown to cause the problem?

It can be any operation. Not any specific one. Just as long as the operation takes long enough for SketchUp to white-out. It can happen to plugins as well.

Chris Fullmer

I only used the explode example because that is just about the only time I ever see the bug is when I'm exploding mesh terrains. So it was the first that came to mind. So a new explode method, save method, rotate, move, all of which would get the user input, then deselect everything and commit the operation with nothing selected.

Just seemed like a potential help to alleviate some of the problems.

hellnbak

Well, the problem seems to have fixed itself, at least for now. Had too much time invested in my latest project so I decided to see if I could finish it, and the line problem has only cropped up once (so far) and on a small, manageable scale.
Sort of like having a problem with your car so you take it to the mechanic and the problem disappears.
Still cringing every time I click the mouse button.

Mike Amos

We only really need one app, specifically an app to get the develpment team to listen to users and get to grips with the very basic problems in sketchup. Additional faces, issues with multiple plugins freezing the program, no functionaly reliable intersection tool etc et al.

Been at this point with other software and stopped using it, only at this point (not just me but many folk leaving) will the dev team actually listen. Most of the time the cries of users are drowned out by marketing types and beanie counters. Sad way to run a business.

hellnbak

@mike amos said:

only at this point (not just me but many folk leaving) will the dev team actually listen.

But if the vast majority of the users use the free version, why would they really care about people leaving?