Bill, will Adam see this? You haven’t pinged him. @adam is his tag I think.
I think it is a little bit more complicated then that, C++ was developed almost 50 years ago, but will outrun me, for sure, with my BASIC skills. You need to combine multiple platforms and have the right mixture.
When asked what kind of sports car I prefer, I always respond ‘Red’
Check the preferred skills when looking for a job as a programmer in the Boulder area, these days:
- Experience with Conan package management.
- Experience with JFrog Artifactory.
- Experience with configuring InstallShield and InstallAnywhere desktop installers for Windows and Mac.
- Familiarity with compiled languages such as Java and C++, and their build systems for Windows (Visual Studio) and Mac (XCode).
- Experience with developing mission-critical tools and infrastructure designed for scalability and reliability.
- Experience administering development process tools like code review systems and bug databases.
- Experience with scripting languages such as Bash and Ruby.
- Experience with Atlassian tools such as Jira, Bitbucket, and Bamboo.
- Familiarity with the principles of computer security.
- Familiarity with software internationalization/localization.
- Experience with AWS server configuration, scaling, and maintenance.
(amongst the minimum requirements, I prefer those as the most important:)
- Passion and creativity for developing tools and automating workflows to improve productivity for software development teams.
- Ability to collaborate and participate as a positive-minded team player in a high functioning, customer-centric internal service organization.
I’ve tried on multiple occasion on a number of LayOut threads to get Adam’s attention/response. In particular, I repeatedly solicited his opinion/feedback regarding using an external graphic processor (eGPU) to accelerate LayOut. Evidently he keeps a pretty low profile, no direct responses from him on any LayOut topics to date …
Thanks Anssi,
I would add to your list the following to improve LayOut performance:
- Turn OFF Grid and Object Snapping whenever possible
- Use only ONE LayOut page per LayOut document … this minimizes the number of Viewports/SU Models LayOut has to process.
- Turn OFF Auto Render, and Render/regenerate Viewports manually only when you want/need to.
They seek him here, they seek him there…!
The slow speed in LO is directly related to what you vector render. As I mentioned in the video, vectorizing a 3D Wall deals with 12 edges and 6 faces, while vectorizing a section cut of the wall only deals with 4 edges and 1 face…so likely a 10 fold time crunch. I don’t think each viewport sets a new model or the file size would get astronomical.
So for those of you that only want vector rendering I’d recommend a layering control system that minimizes the elements needed in a vector render. Make sure you check any components that may be overly large like appliances etc.
And definitely work with auto update off. I just get in the habit to update the reference when I first open a file.
1 Like
Thanks Nick,
I appreciate your feedback, and I enjoyed your Basecamp talk yesterday!
Your comment about each new Viewport not setting a new instance of the SU model makes sense, I guess if that happened, LayOut wouldn’t function at all!
It does seem that limiting each LayOut file to just ONE page (thus less Viewports and instances of the SU model per LO file) increases speed and responsiveness, any theories on what is going on there?
Thanks again for pushing the envelope with your work, showing us all what CAN be done with the native tools!
1 Like
Hey Mike,
I’m a bit confused by your job skill listing … what are you trying to say?
I like red sports cars too, but what am I missing here?
Care to clarify?
these are the skills needed to get a programming position in Boulder, one must be multi-faceted and be familiar with multiple disciplines.
Check the preferred skills when looking for a job as a programmer in the Boulder area, these days:
- Experience with Conan package management.
- Experience with JFrog Artifactory.
- Experience with configuring InstallShield and InstallAnywhere desktop installers for Windows and Mac.
- Familiarity with compiled languages such as Java and C++, and their build systems for Windows (Visual Studio) and Mac (XCode).
- Experience with developing mission-critical tools and infrastructure designed for scalability and reliability.
- Experience administering development process tools like code review systems and bug databases.
- Experience with scripting languages such as Bash and Ruby.
- Experience with Atlassian tools such as Jira, Bitbucket, and Bamboo.
- Familiarity with the principles of computer security.
- Familiarity with software internationalization/localization.
- Experience with AWS server configuration, scaling, and maintenance.
In softwareland, I think it’s regarded not wise to let developer’s talk directly to end user’s.
Developer’s are used to talk to machines. The Product Managers should be in between.
1 Like
I do multi-page documents in LO, but I do not place an entire project in one layout file. That will definitely slow things down considerably. I separate my LO files by drawing type. So Floor Plans and Roof plans are one file, Elevations another, Sections another and so on. It makes the work flow much easier to keep track of since you aren’t dealing with multiple models in a single file. The only exception to multiple models in a single layout file would be my detail sheets - but those are composed of scrapbook models that do not get edited on the drawing sheet - they are edited in the individual scrapbooks and then just dropped into the sheet.
This method also helps when you are exporting ACAD files for other consultants since you can focus on just the sheets they need.
1 Like
Thanks for the extra process description Nick!
OK … and this is a way of saying … what?
Layout is actually a fast renderer of 2D vectors.
The problem, as @Anssi and @Sonder stated already is that each viewport is a full model that has to be loaded/reloaded and rendered.
If you export a complex model’s view from Sketchup to DWG and import this DWG into a Sketchup file and then into Layout, Layout renders it very fast. Exporting a complex DWG from Sketchup might be as slow as rendering it in Layout though. But if you’re really in a need for a vector view of a complex model in Layout, you could try that.
This method of exporting DWG, inserting it into a SKP file, and send it into Layout is simply put, unusable for every day tasks but helps for a faster Layout workflow if some things could change.
If we would like to use this method right now we’d need to export several scenes, from the model or multiple models into one or more Sketchup files. We would have to do it one by one as there is no batch exporter for DWG files. Then we’d have to convert every DWG into a 2D SKP file (importing them directly to Layout takes longer and there’s no reload option). We’d finally would have to each 2D Skp file into Layout.
We’d be dead by the time we finished and we would die a second time if we needed to change something in the model and redo the whole process.
However, this “2D SKP to Layout” process could change everything if it was automated:
- We would hit a button and Skethup would Batch export scenes as 2D Skp files into a folder;
- We would import every one of these 2D skp files into Layout as a viewport or we would have an automated way of creating our viewports in Layout.
- And Layout would work fast.
- If we would change the model we could tell either Sketchup or Layout to redo the process in 1. and update all references.
- We could even select a single viewport to update and sketchup would export the 2D Skp file from that scene and avoid processing all scenes.
An advantage of this method that I use for certain tasks/jobs is that with the 2D Skp file you can manipulate the view in 2D and create different effects than what the 3D model allows. For certain graphical output is great and I use it for old vs new plans, elevations and sections.
The mais issue (besides all the work) is that, exporting a very complex model to DWG can take a long time. You can experiment with your own models and see if you can export one scene from Skp to Dwg fast enough and if so, you can use it in Layout after importing it to Skp and manipulate it graphically:
a. Pick a complex model,
b. export a scene to dwg,
c. import that dwg to Sketchup (generate some faces to fill the 2D linework first if you wish).
d. import the original 3D model into Layout and select that corresponding scene in the viewport,
e. import the 2D Sketchup file you created and compare which is faster to work with and snap to.
Each viewport is only a view to the one model.
That method would completely lose the ability to update the model. Any changes would require this re export process.
You are far better off utilizing layer control to vector render what is required. Many times, the vector lag is due to complex components that you may have in your model like 3rd party appliances and fixtures.
If your having trouble with object snap and dimensions, part of that pre 2020 probably had to do with dimensioning a full vector 3D model. With 2020 tag control, you can easily isolate just walls and dimension without issue.
I dimension my plans before I add trim, cabinets etc, so it just the bare raster render of the structure. It’s a task that takes minutes on an average 3,500 sf house.
Hi Nick,
Thanks for your help. I have not half the problems most people are having and can control my drawings to be able to work.
I rather keep using stacked viewports than the new layer process though, it’s speedier.
I’m just saying that exploring 2d SketchUp views of the model instead of full 3d viewports does make Layout faster but it would require the SketchUp team to work things out in the background so it could be feasible.
Otherwise it’s not.
Having said that, I used that method for some kind of drawings where I was presenting 2D from SketchUp (it has some renewed possibilities now with line style control by tag) and I also use it for old vs new drawings, where I export drawings of the new model and the old to 2d and overlap them. The code here requires the demolished to be yellow, the new to be red and what’s kept to be black and in full 3d it’s almost impossible to achieve something easily while it’s very easy with 2d files.
That’s why I found that the same drawing in 2d is much faster in Layout than in a 3d view.
I believe the team is aware of these experiments of mine.
That’s great! Everyone finds their best solutions once they understand that.
I only hybrid/vector render 2D views like isolated section cuts and line work for things like property lines and setbacks.
That said, vector rendering a simple 3D model is fast, but if contains dynamic or even regular components that are complex, it will big things down significantly…a cube or wall in 2D is 4 edges and one face. In 3D it is 12 edges and 6 faces…that’s a huge difference in vector computation.
I’ll bet if folks isolate all components like appliances, light fixtures and elaborate dynamic components, hide them, removing them from the scene, then vector render in layout they’ll see huge improvement in speed. Then use 2D scrapbook elements to replace them.
There is a lot of stuff to improve in Layout though.
We cannot simplify what others ask from us so we can’t go raster.
I don’t enjoy working in raster anyway and I also need layers in vector for CAD that I can’t export from SketchUp tags. For me it’s definitely not only property lines…
So I can’t avoid vectors. What I can avoid is complex styles, shadows and other stuff and I definitely simplify modelling as much as possible.
For appliances and all that HD stuff for rendering I always replace for simple proxies and other special render stuff never shows up in tech drawings.
We have a streamlines workflow but also a lot of caveats that are very hard to solve.
Hello everyone in this thread.
@Beamer2 LayOut’s core codebase is significantly younger than SketchUp’s. For your question about an external GPU, that will likely not help LayOut’s performance.
One of the biggest offenders in LayOut performance is in inferencing into a SketchUp model viewport, regardless of its render mode. If you turn object snapping off and move entities around your document you should see a huge difference in performance. There are also other issues specific to each platform that can cause slowdown. For example, on Windows, lots of text on a page can cause slowdown when zooming in closely. On macOS, we’re fighting with some Cocoa “optimizations” that occur when you’re zoomed in close that makes panning chug.
Balancing performance with quality output is a seriously complicated task, and we are very aware of how painful it can be to use LayOut with heavy models. As I’ve shown, we are aware of many different areas of weakness in LayOut’s rendering performance and doing what we can to improve it.
Thanks,
Adam
7 Likes
Excellent Adam!