The two most common utility scenes I create are called simply “ON” and “OFF.” The “ON” scene displays all layers in the model. Using a scene to toggle on or off multiple layers at once allows you to change what’s displayed with one easy click. Of course, you can go into the Layers window and manually toggle layers on and off, but this can be time-consuming with dozens of layers. These scenes enable you to quickly turn off or on details, making it easier to work in the model. There are many uses for saving scenes with the above options I’ll demonstrate something called “utility scenes” here.
So clicking this scene tab won’t orbit you around anywhere, but it can change the displayed layers.
Without a saved camera location, the current camera view is not saved with the scene. When this option is checked, as it should be by default, whatever layers are visible when the scene is saved are the layers that will appear when you display that scene.įor the scene shown here (to the right), named “OFF,” layers are saved, but Camera Location is not. Since this is a post about layers, the most relevant scene option here is Visible Layers. Take a look at all of the options you can save in a scene, such as shadows, axes, or hidden geometry. Note that Camera Location is not saved for this scene.īut saving views is not the only reason to use scenes. Clicking that scene tab returns you to the saved view. Simply click the Add sceneicon (the “plus” sign at the top of the Scenes window), and a scene tab is created at the top of the SketchUp window. This complicated-looking project is a prime candidate for simplification using scenes and layers.Īt its most basic level, the Scenes window is how you save a view in SketchUp. In this final post of the series, I’ll demonstrate the power of combining SketchUp layers with scenes to make model presentation simple and efficient. In Part One of this series, Bonnie discussed best practices of layer placement, and in Part Two I showed some large-model case studies of layer organization.
The following is adapted from Part Three of their series on the use of layers in SketchUp. Bonnie runs 3DVinci, which features a wide variety of SketchUp books and projects for all ages. Daniel is a landscape architect and masterful SketchUp trainer and author. If someone were to add their own 's4u_makeface/s4u_makeface_loader.rb' file that would NOT break the signing hash check in v2016, AND if the loader looks for an open-ended path, then the RB will load instead of the encrypted versions and this could do something wicked - but of course unless you stupidly got the RBZ from an iffy site it should all be OK - but that's more to do with the source being trustworthy - like EWH or the SketchUcation PluginStore - rather than the RBZ being signed, which unfortunately on its own could offer only illusory assurance.Daniel Tal and Bonnie Roskes have teamed up to create – a blog on SketchUp and all things related to 3D. Of course, publishing only RBE means the extension won't work in anything other than >=v2016 !Īlso, if the signed RBZ includes encrypted files, then it may currently not be exempt from malicious tampering ! ill-advisedly shipping them together means any 'hacker' can easily see inside the RBS anyway, and compromise the RBE's encryption. Īlso the signer perversely allows the author to add both types of encrypted files into the same signed RBZ - although RBS works in ALL SketchUp versions anyway and publishing in RBE only protects the author's IP when there is no RBS version out there. The new signer does not allow a mixture of RB and encrypted files. RBS or RBE - because only unencrypted RB files will work. it does not include a file-type suffix, and IF the author chooses any encryption at all - i.e. RB files in the subfolder will find it works, but making the RBZ with them included and then signing it, will then fail unless the specified loader path is left 'open ended' - i.e.
This is a typical error caused by the new and unfortunately half-baked v2016 signing process which has been introduced.Īn author testing his code with all. So it must be done by the author and re-signed. So v2016 won't like it unless it's running in 'Unrestricted' mode. It will work - however, editing this file manually breaks the signing hash! If the base-level 's4u_makeface.rb' were to say: There are two files added by the signing process: The base-level 's4u_makeface.rb' which sets up the extension has a path set for the extension's loader to be: The author needs to change his files and remake the RBZ and get it re-signed/republished.