I have a functioning although sometimes frustrating relationship with Layout, but I am genuinely curious about the thinking behind how it works, so please hear this as a sincere question.
Basically I’m curious why Modifying Scenes is possible? Double clicking on a portal, or changing into a standard view within Layout, or changing the style within Layout. These are all very convenient features of Layout but as they all break the Sketchup-Layout file link they cannot really be used. All best practice advice and documentation says never use these features, so why are they so carefully worked into the UI? How did the Layout development team imagine we would employ those features in our workflow? On one-off 2D documents that we would only print once and never need to edit again so the broken link would not be important? Why was so much care put into making features available that we can’t use and in some cases (double click portal) have to be extra vigilant to avoid?
It would be very satisfying to me to better understand the thinking here, and perhaps it could help me become a better Layout user.
The feature can be useful for quick one-off things where you just want to bang out a document to send to a client.
There have been requests over the years to make it more difficult to modify scenes in LayOut. You can now lock viewports and of course you could always lock layers. My LayOut templates all have layers that are only for SketchUp viewports. Those layers get locked before I do anything such as add dimensions, labels or drawing entities over the top of them so I don’t inadvertently modify them.
Because no one thought the SU LO relation through from the start is what I’d say; it is seems to have grown and developed over time.
Currently the UI invites you to make changes locally in LO but then you risk having your work destroyed when updating the model. While it seems to more or less be a consensus in the community about not changing viewports locally, only reference scenes, the UI steers users in that direction by making it very easy to make such changes. The scene workflow is really something you have to learn from others; it’s not like SU modeling which can be learned quite easily by just trying things out.
One reasonable approach would be to discourage users from making local changes to the viewport. Removing the capability completely may break some people’s workflows, but at least moving the camera could be done through the context menu, not double click, newly placed viewports could be linked to the active scene, not the Current View and so on. Maybe double click could even bring up a list of scenes to chose from or show a message when there are no scenes, to make it clear this is how you are supposed to use LO.
Another approach that I think would be even better is redesign for a workflow where LO doesn’t reference scenes, but primarily stores what is now scene properties to the individual viewports. For this, viewports need to by default not reference Current View nor any scene; changing the model should not change the camera, visible layers, style etc etc of any viewports after it is placed, unless you explicitly chose to do so. This would make the viewport appear much more stable and safe to work with. Next step would be a way to fully control on viewports what can now only be controlled for scenes, e.g.a active layers. The last step would be a tool to easily copy these properties between viewports, e.g. an eye dropper tool that lets you select exactly what properties to apply.
Sure, referencing scenes could still be fully supported for backward compatibility, but working without it would be simpler and more straight forward, and is already what is most intuitive to new users.
When you think of it it makes quite little sense to have modeling done in one software and presentation done partly in that software and partly in another. Changes to the presentation shouldn’t require changes to the model. Ideally one person should be able to model and one work on the presentation in parallel (without non-intuitive work around such as working models being used as component in presentation models). It should be a clear separation where you easily understand from the start what each software’s responsibilities are.
If there ever is released a web based version of LO I hope Trimble takes the time to rethink this relation from the start.
The vision of where it should be heading must come from Trimble.
They need to set a path and relations between the different software (Tekla,SketchUp,LayOut, Trimble Connect, etc)
They need to be aware of who in the AEC industry uses what and how they should work together.
I think you guys aren’t seeing presentation the way I meant. Don’t think static presentation, think more along the lines of PowerPoint which LO can do quite well.
The presentation mode and the ‘Can you do that, with SketchUp?’ Is part of the confusion.
I recently had a client who never had opened any ‘inspector ‘ panel in Layout! She did all her viewports by rightclicking on them and only used the tools in the getting started toolbar.
She did not know what ‘modified’ meant, but made great presentations for her clients.
Another client refused to use LayOut because it did not handle dimensions the way SketchUp did.
He does all his presentations in SketchUp.
I have great respect for the way you guys ( @Sonder, but also @mikebrightman and @jgbrock1 ) have managed to cope with the restrictions of the software but that is exactly what it is! (we don’t learn to use software, we learn to deal with it’s restrictions)
Anyhow, for the software to evolve and grow, we need a vision.
(eg: *‘if you want to model: SketchUp’
*’if you want condoc’s: LayOut’
*’if you want a presentation: find a way to insert models in Google Presentations or Powerpoint’
*’if you want to markup and collaborate: Trimble Connect’)
I feel like this gets at the spirit of my question. I have so often wished that Layout could be a true stand alone program that has complete control of the model view, only referencing geometry and textures, with all other “scene” options adjusted from within layout. This feels like such a natural idea and the constant back and forth between the two programs to accomplish one goal feels so clunky that I am incredulous that this could have been the intended workflow from the beginning. I wonder if the presence of many of these control options I long for (albeit in an unusable link-breaking capacity) is evidence of some original or future intention on the part of the developers to build layout differently. I suspect Trimble employees are barred from commenting on past or future intentions here. I was mostly curiousness if my feelings about the potential of layout and its workflow were shared by anyone.
I feel compelled to avoid argument by saying that I am not trying to disparage layout, it’s useful, and I use it. Yes, it can be used for presentation and clearly fantastic work can be realized using it as evidenced by some of the posters on this thread.
One thing that some people have asked for is the ability to modify the scenes in the SketchUp file itself from LayOut. That could be good if the SketchUp file is only ever used in a single LayOut file. It would wreak havoc if the same SKP file is used in multiple LO files, though. Personally, I have no problem setting up my scenes in SketchUp and leaving them unmodified in LayOut. The results are predictable and there are never any surprises like users who do modify scenes in LO report.
No, I agree that allowing layout to modify the Sketchup file could have disastrous results. I would rather see layout stop referencing scenes altogether, just do away with the “modified” label and have all viewports modified in Layout but still linked to SU raw geometry and textures.
Perhaps there is a code writing issue that makes this difficult. But I have yet to hear a good reason why in theory controlling everything from within layout would be a bad idea.
This would also prevent the file from being open for actual modeling work simultaneously as presentation work is being done. Having the data flow in two direction opens up a pandora’s box and for no real gain. You don’t need those scenes in SketchUp anyway.
Well, you do need those scene, considering how SketchUp and LayOut are currently designed to work together.
While I can see some benefits in just doing as EF suggests, trying to make it work that way now will just create problems. We see this repeatedly in this forum.
Well, it’s not really that you need the scenes in SketchUp but that SketchUp is the only place you can create them. It’s in LayOut you need the scenes. I’d be happ to get rid of the presentation specific scenes in SketchUp to make it easier to find my modeling scenes in the scene list.
I don’t think you would have the ease of alignment and stacking viewports with a method that was solely in Layout. The beauty of the scene relationship in Sketchup is the ease of matching the exact same camera position in the scene manager - Select the scene you want as the standard, in scene manager select that same scene, shift/select each scene you want to align, uncheck, then recheck camera location. It literally takes seconds to align all your floor plans, roof plans or multiple sections etc. The same goes for any of the parameters in the scene manager.
The ability to access the sketchup model from layout is great for presentations. It also allows you to simply share just the LO file since the sketchup file is embedded.
That depends 100% percent on the UI you have in LO. If you had an eyedropper that could pick up specific properties and “paint” them onto other viewports, it would be just as easy, and with the benefit of actually making sense and be intuitive to new users.
Why couldn’t we have that exact same functionality from within Layout?
Without having to switch back and forth between programs, without saving and updating references to make small changes it seems like it would be even faster and simpler? No?
If there are no scenes saved in Sketchup, how do you align multiple view ports? You’d have to do each one individually which is a complete waste of time for something that can be done in 2 seconds inside Sketchup.
If the SketchUp file can be modified in the LayOut file, that means that one LayOut file would control what is shown in other LayOut files using the same SketchUp reference. If you separate the SKP reference in one LO project from the original, changes to the original will no longer be shown in the LayOut document.
As it is, the process is simple, dependable, and easy. It makes it possible to use the same SketchUp file in multiple LO documents and updates to those documents are straightforward.
I’m in way over my head here with the heavyweights that are in this discussion, but couldn’t it be a two-way street?
If a view were to be “modified” in Layout why couldn’t Layout automatically add that scene back to SU tagging it with the “modified” nomenclature and not changing the original scene?
I’ve always struggled with getting the correct view I’ve wanted in the SU window. Only realizing it when I’ve exported to LO. I now realize that all I have to do is go back to SU make my changes and update.
But it sure would be a time-saver if my “modified” views could have automatically been added to scenes back in my model.
