Hi There,
I feel like is is high time now that sketchup should be able to handle heavy models efficienty like all other modelling softwares does.
Recently sketchup crashed for me just for 5 highly detailed plant models. (yeah there were a million edges)
but still other softwares are easily able to run and operate with such models
why cant sketchup? We all love to work in sketchup.
Everyone out there who has sketchup involved in thier workflows knows this that it is high time now, that the developers should address this long prevailing issue.
we all know that most impressive ArchViz involve highly detailed models, and yes we are using those as proxies for now, but the workflow for it is too time consuming.
why cant sketchup just handle the load? i have used 3ds max, rhino for same models and they work just fine.
Kindly look into this.
i know you will.
When SketchUp crashed on that million-edge model, was a Bugsplat generated and if so did you send it in?
I have been developing a very detailed model for a number of years now, using SketchUp Pro 2018 (and before that, SketchUp Pro 2016) on a 2014 iMac with 32GB of memory. The entire model has about 6.7 million edges and 3.3 million faces. No textures or other images anywhere, just solid colors for materials. I have never had SketchUp 2018 crash, though orbiting around it runs at perhaps 10 frames per second or so (no shadows, no profile edges).
I wonder if SketchUp itself is crashing, or if an extension is causing the crash? Can you recall what you are typically doing at the time when a crash occurs?
@TDahl
Actually what i did was just get highly detailed modelled plants inside of sketchup.( i guess they were from evermotion )
they imported fine
but they had a million faces and edges
and after a while the cursor would just circle around and sketchup did not respond at all.
i waited for about an hr but it did not respond at all, i just had to end the task later on
The thing here is, no extension was at all involved yet in the process.
It just stuck there processing all the faces and edges and just died for 2 tries
the third time it imported ok after waiting for just 10 - 15 mins. it was using about 12gb ram out of 16gb for all the geometry, but orbiting must have gone down to 1 or 2 fps
after this i imported the same model to Rhino - it did not even stutter, same goes to 3ds max.
they handled the model so well that too on the first try. also no frame drops while moving around
and also another big thing i observed was the ram usage.
sketchup bumped the ram usage to 12gb still no good to use
Rrhino and 3ds max were using just about 4-5 gb of ram
so i think somewhere, sketchup still has some sort of issue with handling a lot of geometry (which is considered normal for other modelling softwares)
I am on skp 2021, wouldnt know much about 2018 version and also i am on windows 10.
i have heard that CAD softwares run much better on mac? is it the case?
Agreed. I think there is some level of consensus among SketchUp users that SketchUp does not do as well with complex geometry as many other 3D applications.
I deal with this situation by developing the various sub-systems of my overall model in separate SKP files (which end up with between a few hundred thousand edges and a million edges, generally). When a sub-system is complete, I save it as a component from the separate SKP file, then add it to the master model SKP file. If I need to make changes, I edit the separate file, save-as again, then reload the component in the master file.
@TDahl
Yeah that is also something i do. But most of the times i import everything as proxy ( for vray )
But at some level , sketchup starts to loose the speed and efficiency. (Unlike other mentioned 3D softwares)
Which needs to be addressed by the developers.
Lets hope they hear it !
I don’t know anything about the inner workings of SketchUp but I have often suspected that with a lot of geometry present, the inferencing system sort of overloads. A lot of time ago AutoCad was almost impossible to use with running Osnap filters on, but they rewrote their snapping algorithms and managed to speed it up quite a lot.
Neither do I.
One solution might be to add an extra option to flag(/attribute/or whatever you would call it) components.
When that flag is enabled, component’s geometry would be ignored by the inferencing engine. Only its local origin in the overall modeling space and its local axes directions (orientation) towards the system’s axes would be used to place such a component. The geometry itself would be visible but there would be no inferencing to that component. The work load for the engine would reduce dramatically.
Maybe even an overall switch to (temporarily) overrule the flagged components to rapidly include their geometry for inferencing.
It is often said:
- SketchUp is an editor, not a viewer
- it involves a mix of CPU- and GPU-bound procedures, not purely GPU
- it has to support all kinds of unpredictable interactions, where as games use preoptimized compiled scenes
- inferencing is expensive: every vertex may be a vertex that you want to snap to
- it is all about learning the correct workflow: keep your detailed trees on a hidden layer (just for rendering) and proxies for modeling/snapping/inferencing on a visible layer
Here, we can view and interact with Terabyte (or unlimited size) raster images that don’t fit into RAM and still have reasonable performance. For raster graphics that’s (almost) all solvable with appropriate datastructures and algorithms. This cannot be compared to vector graphics, but the question is, is this a lack of innovation of appropriate datastructures/algorithms for vector graphics, or an inherent limitation (theoretically not better solvable problem)?
Would it be better to do without (or reduce) some features if that releases bottlenecks?
- Render without profile edges if the pipeline is then less CPU-bound?
- Introduce non-inferenceable geometry (vertices, or content inside of component definitions that do not respond to snapping, snapping only to their component bounding boxes)
- Load only parts of a file from disk that the user currently interacts with, if save assumptions can be made that unloaded data cannot be required by any current computations (e.g. through component hierarchy)
- Dynamically and transparently create low-detail representations and load higher- or full-detail from caches or disk only on demand?
That’s an understatement 
. I also find myself defending sketchup regularly for its shortcomings in handling complex geometry, but it is pretty obvious sketchup is severely lacking here. Not sure why but I also haven’t seen ANY other 3D software get bogged down by models this complex, or even models 10-50x more complex. Weird.
@monospaced
Yeah,
I think it should now try and compete with other modelling softwares, as they have grown so much with time but thats not the case with our beloved sketchup. 
We kinda need a major update ( like blender- cycles x - they re-wrote the render engine from scratch and it is said to be 700% faster now)
One question: are you using realtime shading/hidden view/etc. viewport style instead of wireframe in these applications? It has also been said that the realtime rendering in SketchUp is one of the reasons for its sluggishness. What I can say about the likes of Revit and Archicad, navigating in their 3D views is nothing to write home about.
Edit: I just had a look at a large landscape model with almost 400 000 faces and 600 000 edges in SketchUp, DWG TrueView and Rhino 7. It navigated quite OK in SketchUp, shaded with textures mode, but it was very, very slow in both DWG TrueView and Rhino, viewed in wireframe. This with a DWG exported from SketchUp. Rhino 7 did much better when let to import the SKP file by itself.
One solution to the inferencing complexity might be to limit its scope to selected objects, or to the active entities currently being edited (inside a group). Inferencing might also be accelerated by considering distance from the camera, and triangle density - snap could then ignore all vertices and just use the origin or bounding box. Often, I wish it were easier to just grab the origin. Raytracing engines have also figured out acceleration structures to traverse the scene more efficiently.
I’ll also add that I don’t think inferences are necessarily the entire culprit. My architectural scenes, no matter how carefully optimized, slow down when no editing tool is active at all, and I’m just orbiting around. I think edges are the major slowdown. I love Sketchup’s edges, but they always cause a big performance hit, especially profiles. From what i’ve read, OpenGL’s options for drawing line primitives are limited. Might be time to move to Vulkan…
In any case, hiding the edges of detailed meshes can really help.