Change the fade / hide settings from the API

[DanRathbun]

Continuing the discussion from Changing active_ entities within a tool:

@barry_milliken_droid

The related problem is that I don’t see a way to change the fade/hide settings from the API(?)

In some circumstances, where groups abut or overlap, I want to switch from fade to hide so user can see what he is doing.

You need to try to remember that things like this are rendering issues, and so you’ll most often find settings in the model’s RenderingOptions hash instance.

### HIDE REST OF MODEL
#
  def get_inactive_hidden()
    opts = Sketchup::active_model.rendering_options
    @prev_inactive_hidden = opts['InactiveHidden'] if @prev_inactive_hidden.nil?
    opts['InactiveHidden']
  end

  def restore_inactive_hidden()
    if @prev_inactive_hidden.nil?
      puts "No previous setting to restore"
    else
      opts = Sketchup::active_model.rendering_options
      opts['InactiveHidden']= @prev_inactive_hidden
    end
  end

  def set_inactive_hidden(arg)
    opts = Sketchup::active_model.rendering_options
    @prev_inactive_hidden = opts['InactiveHidden']
    opts['InactiveHidden']=( arg ? true : false )
  end

  def toggle_inactive_hidden()
    opts = Sketchup::active_model.rendering_options
    @prev_inactive_hidden = opts['InactiveHidden']
    opts['InactiveHidden']= !opts['InactiveHidden']
  end
#
###

### HIDE ALL OTHER INSTANCES
#
  def get_instance_hidden()
    opts = Sketchup::active_model.rendering_options
    @prev_instance_hidden = opts['InstanceHidden'] if @prev_instance_hidden.nil?
    opts['InstanceHidden']
  end

  def restore_instance_hidden()
    if @prev_instance_hidden.nil?
      puts "No previous setting to restore"
    else
      opts = Sketchup::active_model.rendering_options
      opts['InstanceHidden']= @prev_instance_hidden
    end
  end

  def set_instance_hidden(arg)
    opts = Sketchup::active_model.rendering_options
    @prev_instance_hidden = opts['InstanceHidden']
    opts['InstanceHidden']=( arg ? true : false )
  end

  def toggle_instance_hidden()
    opts = Sketchup::active_model.rendering_options
    @prev_instance_hidden = opts['InstanceHidden']
    opts['InstanceHidden']= !opts['InstanceHidden']
  end
#
###

The fade settings are also there, as John shows …

@john_drivenupthewall

Sketchup.active_model.rendering_options["InactiveFade"] = 0.35

Sketchup.active_model.rendering_options["InactiveHidden"] = true

Sketchup.active_model.rendering_options["InstanceFade"] = 0.25

Sketchup.active_model.rendering_options["InstanceHidden"] = true

these?

john

[eneroth3]

I don’t know the context of this discussion but I’d like to add that whenever you change ROs in your custom tool, make sure to remember the original values and reset them when the tool is deactivated. Otherwise users will struggle knowing why their model suddenly appears different.

[DanRathbun]

@eneroth3

I don’t know the context of this discussion …

This is a related topic thread. The “continued from link” is at the top of the thread, was regarding changing active context within a tool. It really didn’t have much to do with the stated subject of that thread so I broke it out into it’s own. (So searchers might find it more easily.)

@eneroth3

… but I’d like to add that whenever you change ROs in your custom tool, make sure to remember the original values and reset them when the tool is deactivated.

Agreed. This is why, in my examples above I store the previous setting, and provided restore methods along with getter, setter and toggles.

Although I did not treat the faders they can be done in a similar way. But their toggles might toggle between no fade and the previous setting ?

[barry_milliken_droid]

I did TRY to remember. But when I looked at rendering options I didn’t see them because I was looking for something related to “components” and didn’t see it. This is an area of the API where the organization and terminology used is sometimes very different from the SU UI. It would be helpful at least if the statement “The majority of the rendering information returned exists in the Styles dialog” was amplified to refer to the exceptions.

[john_drivenupthewall]

I don’t TRY to remember, But I made an extension years ago…

john

[DanRathbun]

@barry_milliken_droid

But when I looked at rendering options I didn’t see them because I was looking for something related to “components” and didn’t see it.

Firstly, most of us here can agree that the RenderingOptions hash keys are a bit too “concise” in may cases.

It makes us wonder why they were named the way they are. The obvious answer is similar to the answers I gave you in your thread attacking the name of Attribute Dictionary.
It most likely has to do with the names of objects on the C-side of the SketchUp code. When the original API coder(s) implemented (aka exposed) the rendering options to the Ruby subprocess, they most likely just used the same internal key names they use on the C-side, so that there need be no lookup table or humongous C switch statement.
These internal C side key names make (or made) sense to the SketchUp core programmers.

@barry_milliken_droid

This is an area of the API where the organization and terminology used is sometimes very different from the SU UI.

In many places the UI terminology (labels) changed over the years and the documentation did not.

@barry_milliken_droid

It would be helpful at least if the statement “The majority of the rendering information returned exists in the Styles dialog” was amplified to refer to the exceptions.

I would agree with this.

ALSO, it would help if the RenderingOptions API doc had a multi-column key table.

Key on the left, the GUI name, the GUI dialog (referring to Model Info and panel or Styles Manager and panel), and an informational column for those options that have multiple numeric value settings such as RenderMode.

ping @tt_su

[barry_milliken_droid]

My original post stated that I didn’t see any way to do this, which is a valid statement of fact.

I’m well aware of the historical reasons for the various terminological confusions, but we agree that the API documentation should make a few more attempts to point them out. Then newbies wouldn’t have to wade through these forums in the first place.

Many of the terminological confusions are simple enough: where the UI says “car” the API says “automobile”.
But some (like “attribute dictionary”) are much more egregious, like “car” vs “rocketship”…