For producing design drawings, I use a variation of “Sonder’s process” involving multiple LayOut documents connected to 1 sketchup file.
The documents might be:
Site Plans
Cross sections
Details
Building elevations
Shadow studies
etc
Each document has a handful of pages (sheets), maybe up to 20.
When the SketchUp file is large (600mb+) and the LayOut documents are complex (hybrid, or sections, or dimensions) it takes approx 30-45mins to update or re-render each document (even longer if its hybrid).
Most of my day producing drawings seems to be watching LayOut loading (ie hours of waiting). I have a very fast PC and all files are saved locally.
How can we make it so that I can load 1 document in LayOut, and, while it’s rendering, I can be working on other documents? (I notice only 1 cpu core is fully active during rendering operations)
Is there a way to launch multiple instances of LayOut ?
If we could get rid of the multi document behavior and have separate instances of the program open this wouldn’t be a problem. It would also allow quicker access to the document you want directly from the taskbar. And it would allow different version to run at the same time if we want to compare some changes, e.g. check if a bug is new.
A reference/update manager would be nice…something that can read across multiple SU and LO files and update + render with a click.
Is there currently no way to open more instances of LO? Or even to render one of the LO docs (tabs) in the background? Surely there’s a method (or hack)?
I don’t know if there is any undocumented/“secret” command line parameter, similarly to what there is for languages in SketchUp. If there is I’d want to know. Being able to start multiple instances has so many use cases, ranging from productivity in actual production, to investigate translation errors.
LayOut live API and render plugins would be the best! Imagine just right clicking a viewport and select convert to rendering and then it’s an image. All viewport data serialized so you can convert back. You can enter render resolution both as absolute pixels and DPI value.
Or better… Imagine dragging and dropping an unlimited number of layout files to an app that just starts rendering all viewports at once…
Anyhow. I’ve done a fair amount of ruby layout programming, time for some native tools to come
Or, to get back on topic: Imagine dragging and dropping an unlimited number of layout files to an app that just starts updating all model references and rerenders them.
Yeah, the batch update thing makes sense. I even thought it possibly could work as a menu inside SU (eg, update of a SU Scene updates the associated LO viewport)
Glad to hear you’re working on something. Let me know when I can purchase
Renderers (notably Lumion) have a live (‘realtime’) render window for SU. Even if SU and LO could grab images from a rendering program, that would be fine.
Some sort of image composing (layers) would be nice, too (instead of pulling SU /Renders into Photoshop then into LO)
Well, I f you are fine by doing the update manually (for now), and then automatically exporting to pdf, I do have an alpha version ready that does just that.
At first, didn’t LayOut Update one port at request? Now it seems update all whether you want to or not. Would save time. Everything is slow about this program and it creates needlessly large pdf files.
Yes, good comment. Auto-render is definitely turned off.
I’m testing whether having files (even small ones like symbols or a logo graphic) on the Network location is causng a slowdown (it doesnt seem like a cause, except it may slowdown the startup process).
I’m a bit late to this thread but still finding this an issue myself. I work in the same way as you @AK_SAM AK_SAM, with multiple files per project and even minor changes to a plan can take me hours to update each file individually. Have you made any progress on a solution?
And me… but yeah, what he said ^^
as an extension to this - its been floated before but how about using all those spare cores/ threads to perform updates to separate viewports in the same document.