yes that’s the only thing I could find. They talk about turning snap on/off for individual tags though and I could not find anything like this.
Those may have been feature suggestions.
They are feature suggestions. On having just a few hundred possible snap points for Layout to chug through instead of millions, in a complex drawing
ok I see. My speed reading tends to gloss over some important details!
so… further “proof” this would have a huge impact on performance: If you explode your viewport and make it native Layout linework, this will immediately speed the page up hugely. So its not so much the amount of linework in itself, but that the linework belongs to a live sketchup viewport that will affect speed.
So if the amount of snappable geometry from the viewport was reduced from having most tags not snappable, you should get this improvement also from a proper live viewport.
We need to get past the notion that Layout has old bad code. The code is younger than that of sketchup, also stated by @adam .But it probably has some workloads that dont need to be there.
We could get around the speed issue with workflows like the duplicate monochrome viewport without section fills and just a very few tags visible, and work on these during construction documenting, but that seems not to be common practise or knowledge, and really it took me a long time of experimenting to find the simplest of viewport configurations I can efficiently work on during construction documentation. Its when I do my dimensioning I need my vector rendered viewport, and thats when I zoom in and out more, and then need a “Tag-reduced” viewport with a really simple style.
@Odd_Haakon_Byberg : I love the way you stick to your point and don’t give up! 
I am using Layout so much these days, it’s definitely worth fighting for making it better. The new features of 2022 are nice. The native M1 is welcome (for me). But I think you are on to something here as well!
What would be awesome as well, would be if you could add an additional information to a material: section-cut-fill. I was thinking about it quite a bit and I think this could work in Sketchup/Layout quite well. It would be defined like this:
Each material has 2 colors: Face-Color and Section-Cut-Color.
If a material is applied to a group/component that can be defined as a true volume (displays volume-information in the element-inspector) the section cut fill would be applied to the face section cut part of that volume/group-component. If that group contains additional material information (like one of the sides is painted differently) it will ignore that for the section cut - because it only checks for true volume groups.
This would be really easy to set up for the user. One would need to think a little bit about how to solve the “different-scales” problem but it has been solved in other CAD software as well, so it should be doable. But this would feel “native” to Sketchup and wouldn’t require much relearning. And for users that don’t use it wouldn’t bug them much because they would simply ignore the setting and get the default-fill.
2 Likes
Having a cut material directly linked to the original material is very interesting. There have been different proposals for this, linking a section material to the tags panel, right beside the Tag color. I agree its very logical to see section material as a secondary definition of the actual material swatch.
Yeah, it feels logical. The way a section cut pattern is defined in classical drawings is that it ought to represent a material. That’s how we know that “wood” has a different pattern than say “concrete”. Tags are more about structuring a drawing - what to show, what to hide in specific circumstances.
Of course life is more complicated than that. For wood for example (at least in Germany) you have different section cut patterns based on the axis how the section cut is positioned to the axis of the object. AND (also based on the axis of the object) the pattern may be rotated. AND the way a section cut filling is scaled is represented also depends on the scale of the drawing in Layout. The last two points could be addressed by checking the axis, so it could be automatic but going from “horizontal wood section cut” to “vertical wood section cut” would require two section cut properties. However I as far as I know this is only a problem for wood so maybe it can be ignored and woodworker than use 2 different materials instead if they want to go all fancy…
Here we are dreaming again!
so I think the really simple solution is this:
If one is content having two stacked viewports, the back one could be just an image, still updating from the sketchup model, but with no other build in intelligence than keeping its scale. Layout would not look for snap-points, would work much faster, and not present snap alternatives that no-one wants.
The top viewport can then be the wireframe viewport of the few tags that one actually applies dimensions to.
This should speed things up drastically.
For some time I’ve had a raster viewport with style that has all the edge settings turned off and the only snaps I get are the blue On Model Face and a curious red cross Model Intersection indicator which are not that bothersome…
I overlay this raster viewport with a vector viewport that has a style with hidden line mode set.
I don’t have a problem with speed or annoying snaps all over the place.
1 Like
Yep lots of room for improvement in snaps.
I wouldn’t suggesting that we need quite the same fine tuning as Autocad’s dozen+ snap settings, but LO has literally no settings (it’s either on, or off).
Good idea:
- Snapping filters (for example, excluding faces, or softened edges, or hidden edges, or excluding certain Tags or Layers).
I think LO snapping is slow because it tries to snap to EVERY SINGLE face, edge of face, edge end point, midpoint, etc…even for curves. That’s millions of snapping points in an average model. And it’s trying to inference them all.
Sketchup manages it…not sure how…but LO just doesn’t (presumably because it’s also adding stroke styles and scaling which consume CPU capacity).
Maybe LO could have a mode to view the model in a simplistic way, eg Hidden Line with no stroke styles applied. (Adobe Illustrator has his mode…it’s very helpful to speed up edts in complex models…it’s like in SketchUp being able to turn off Profiles and Shadows)
Maybe turning off LO inferencing could help? That should be an easy tweak to the interface.
Also:
- Remove the widget thingy. Nobody likes it. Just give us a rotate tool and an accurate scale tool.
- Make all cursors point accurately.
- Replace the absolutely awful text engine.
2 Likes
I’m surprised nobody has mentioned auto render here… In general when the file size becomes large enough that layout starts to become slow, auto render makes a much bigger impact on performance loss than anything else mentioned so far above in this thread… That is my experience over the years.
2 Likes
What would be perfect for me is snapping forced at the section cut plane. It would require SU to create or acknowledge the intersection points at the plane, but it would be super consistent. Group from slice and section cut face will do this but they become a constant edit issue.
Yes, but the only downside is you have to remember to update each scene. The key is to monitor how often you need to update the reference. I personally keep autorender on and manually update the reference only as needed.
One thought on the group from slice: if you create a scene that only contains the group, you could then have that dedicated scene in LO be on non-printable layer ala “def points” in ACAD.
Yea. As you know, that only works up to a certain point, than with larger file sizes, it becomes slower and slower to keep auto render on making a big impact in speed. Layout got a lot better as of the most recent big update so I don’t think speed is really much of an issue anymore. Either way, Mike Brightman who really is a big reason for the auto render trick being a known thing, I think he’s totally right in saying that why would you tell layout to auto render your entire document when you’re only working on a sheet or a few sheets at a time. In his words, “Don’t tell layout to do dumb things”. I agree with his overall view on layout auto render personally. Like you said, I keep it on until I notice the impacts of speed and than I keep it off. At that point and forward it’s way faster to manually render the sheet or a few sheets you’re on rarely than it is to wait for the entire document every time to update when you’re only looking at one sheet or a few… I know you know all this, but just reiterating…
Auto Render shouldn’t be updating the entire document at once. It updates the page you are on. Then when you switch pages it updates the next page and so on. This only impacts speed when you update the reference. If you don’t update the reference there is nothing for LO to auto render. So I leave it on and only update as needed.
BTW, this also another good reason to NOT place all your sheets in one LO file. I can’t stress that enough. The reasons for separating your CD set into drawing types is extremely useful beyond the speed.
1 Like
I did not know the specifics of that! Good to know!
I have no issues whatsoever with having all my sheets in one file, I am super familiar with why you do that as we’ve talked about this in depth before with @AK_SAM if you remember that conversation in another thread. For me, it’s a complete non issue doing highly complex drawing sets for high end homes and worrying about separating my drawings into other sheets/categories, I have no need to do that and see no benefits in performance that are big enough for me to justify doing that. That is me personally though. A lot of these issues with speed too are somewhat disappearing also in my experience with the new big layout update, it’s pretty awesome. Still an extremely manual program, but much faster to work with now.
There is absolutely a performance improvement in reducing the file size, especially for the very reason we are discussing. Not only does it drastically reduce file size, but should there ever be a failure on a particular file you haven’t lost everything. You can also export specific drawings in both PDF and ACAD export for clients, consultants, builders and review agencies much easier than you can with everything in one document. Heck we even did this with ACAD back in the day. It was never one plot file for the entire project. That required one person to be in charge of the plot set making any team approach on the CD set nearly impossible.
You can also minimize your layer list to have quicker control over specific drawing types. This helps with everything from navigation to actual speed inside the program. Almost every complaint I hear about Layout speed could be rectified if people didn’t try to create one single LO file for a CD set. Of course, more speed in LO is something I too request, but even as the speed increases, it will always be faster to have dedicated LO files just like we used to do with ACAD. My slowest files are my MPE set since they are typically 9 pages with the model referenced on each sheet. Thankfully, the lighting portion of the set is a separate file since it uses the RCP model reference.
For me, I haven’t had an issue with layout speed in at-least half a year or more now and I keep all of my sheets for an entire set in one layout file, around 40-80 pages for an average set of house plans. So what you describe above, is a non issue for me… All of my annotating and working in layout is very snappy and fast, so for a myriad of reasons, just way easier to keep everything in one file for me personally… Sam pointed out numerous benefits to doing it this way as well in our previous discussion in another thread…