In SketchUp ALL edges and faces should be created AND remain untagged. Tags are to be given to groups and components.
With incorrect tag usage you can wind up with edges that LO needs to consider for rendering and that makes LO slower when viewports are rendered as Vector or Hybrid.
Giving tags to geometry creates more work for you and increases the chances you’ll induce errors into your models creating even more work. Tagging geometry requires that you are always chasing the active tag as you are creating new geometry and editing existing objects. If you follow the “rule” that has existed since SketchUp was first release and leave Untagged (formerly Layer 0) active at all times, leave all geometry untagged, and give tags to the groups and components in the model, there is no chasing of tags. There’s less chance of creating errors because you forgot to chase the active tag. In fact, you don’t even need to know what tag has been given to a group or component when you are editing it. Just open it for editing and do what you need to do.
I see. I knew that tags should only be given to groups and components and everything else should be untagged. I may copy and paste your explanation in an email to my office group. Would that be okay with you? Thanks a bunch as always.
I don’t know that there’s a hard number. It certainly depends on your hardware and it also depends on the complexity of the model. Edge counts and material pixel counts in the model play into that. Also the selected rendering mode affects rendering time. Thus the suggestion to leave viewports rendered as Raster.
A few versions back they made a change to how LO renders the viewports. It used to be that after updating a SketchUp reference, LayOut would render only the viewports on the currently displayed page. Then when you switched to the next page you had to wait again while LO rendered the viewports on that page. Now, when you update the reference LO renders all the viewports in the document. That can make it look like the rendering is slower but once it’s finished you can switch to any other page and work without having to wait for more rendering.
If you are regularly making edits to the model that only impact a subset of the scenes/viewports, you could turn Auto Render off in the SketchUp Model panel and manually render the viewports that need it. This defers rendering the rest of the viewports until later. For example, if you are making edits to the primary bathroom, those changes probably won’t affect the kitchen, dining room or the garage. There’s really no need to be rendering the viewports related to those spaces. Once the project is at a point where you are ready to export a PDF, turn on Auto Render and go get a cup of coffee to let all of the viewports render.
Another thing that helps is to be thoughtful about the rendering type you select for the viewports. I often see LO files from users who have selected Hybrid rendering for all of the viewports even if they are using a Hidden Line face style. Hybrid is overkill for that.
For viewports in which textures are displayed, it may be that Raster yields suitable results with no need to render as Hybrid. Turning off the Output Override will leave Raster rendered viewports alone. If you have done so, you should export a PDF with the viewports as Raster and see what you get. They generally look worse in LayOut than in the export because LO normally reduces the Display resolution to help keep working speed up.
Maybe someone from Trimble would do a video as you suggest.
That’s good. You probably also know that if you explode a tagged group or component, the untagged entities inside will inherit the tag. This can be useful if you are exploding a nested group because the objects inside it will have the same tag. This can also be a problem when you explode a tagged group to raw geometry because those faces and edges no become tagged. The immediate next step after exploding a group or component to raw geometry, while that geometry is still selected, should be to go to Entity Info and select Untagged.
That’s fine by me. I think anything you can do to get the folks all on the same page will help to make your work easier and more predictable. I dislike being given a SketchUp file for a project that hasn’t been created correctly. I almost always wind up redoing the model from scratch because that’s easier for me than repairing what the other has done. In some cases I charge double if the client insists on me using their SketchUp model.
Of course everyone’s workflow is different and tailored to the project.
I split my project documents into multiple Layout files.
So, I’ll have a Layout file that is General Arrangements which may contain both existing and proposed or I might have separate files for existing and proposed. Typically these documents will be at 1:100 and are used for making a planning application.
For Building Regulations and construction I’ll have a Layout file that is Existing Conditions and Arrangements and another file for Proposed Arrangements. These will be at either 1:50 or 1:25.
A file for proposed details – 1:10 or 1:5.
And separate files for window and door schedules, services and so on.
It’s essentially a variation on the workflow that Sonder developed.
Since we’re discussing Layout bugs, are you also experiencing this strange phenomenon that occurs when you start a layout?
It’s not possible to directly switch the first view to the top view; you have to switch it to another view first and then back to the top view for it to work. (See attached video)
I’ve never noticed it before but I see it, too. I prefer to use the proper workflow creating scenes in SketchUp and using them for the viewports in LayOut. More stable and predictable results.
@adam, maybe you can pass this on to someone to check out?
In my case, when LO was slow, I realised that my viewports and imported pictures were rendered in High Resolution. Going to Medium and playing with the Graphics Engine - draft mode thing ( I still not totally sure what they do, but I didn’t had time to look them up ) seemed to speed up the work with the file to a perfectly normal level.
I have to say, it’s not a very large file this time, but I have done textures on them and I use a lot of viewports. I also use a lot of line work and fills over the viewports. Quite a bit of viewport layering, shadow and fog and inserted photos, references.
I mainly work on a ArchE or larger paper and I save to dwg (to my coo workers) or pdf (for printing). So the LO file can get quite large by the end of the process. I usually don’t use vector or hybrid viewports. There was a very good update a few years back to save as hybrid or vector when saving.
I needed to update as LO 2025 was doing weird things when updating viewpoints, so couldn’t risk working with that version…just to contradict Mike’s suggestion. In normal circumstances I would agree with his approach.
I apologize if someone has made this suggestion before, but in order to minimize LO’s performance troubles, I never create a single file containing the construction drawings of my projects; I create one for plans, another for sections, another for elevations, another for details, and so on. This method has worked fine so far.
One of the few times that ChatGPT actually shines. Your translation made your meaning crystal clear, though your original English was excellent as well!
To all,
This subject pop’s up quite a lot on this forum & no matter how many very good tips by all to get SU Layout more responsive for a users needs, the file linking data process does seem to be at the heart of these issues.
I think Layout was discussed on this forum as a future possibility to be integrated into the core programme & perhaps these issues wouldn’t be so prevalent. However, I guess this would be a major re-write of the programme, so that wouldn’t happen anytime soon.
I note Rhino was mentioned on this forum on a different subject, so as similar type modelling programmes, I see their equivalent Layout programme is in-house & also uses a tool called Make2D.
I wonder if someone could come up with an optional extension to undertake this within SU….just a thought..
