2.93 viewport selection slow

windows 10 16GB RAM, TitanX
This is a big scene, but I’m trying to be efficient about it.
I have 8 files of the products and I’m linking them by linking the collection. I need access to a few parts though, so I’m using library overrides on each.
Each file is between 46-96MB currently, but I’ll go back and optimize later. They should all be around 50MB.
So my final file is currently 29.6MB. But there are 2,313 objects with 3.6M verts and 7.2M tris. (btw, how do I have more faces and triangles than verts?
I switched to 120fps and hit play, it caps me at around 60fps, which I think is pretty sufficient.

But if I select something, regardless of if it is in the 3D Viewport or the Outliner, it takes nearly 2 seconds to respond. It gets a little better every time I disable a collection.

Are there any settings to change to get that a little more responsive or is this just a big data set? I was hoping linking things would make it be pretty fast.

In a quad mesh each vert is typically part of four faces so usually the number of verts is close to the number of faces (but probably still a bit more) and the tris number will be 2x the number of faces when using quads as it just represents splitting each quad into two triangles.

I would say that the 2313 objects are the problem. Try to join objects that doesn’t need to be separated, a typical import CAD problem is that you get too many objects. Just as a test you can try to join all objects to one and see if there is any difference. If it’s fast again after joining then you know where your problem is, if it’s not you have to look elsewhere to find the problem. Good luck!

1 Like

Yeah, I put that together as well, after posting of course. I should have come back on my own so as to not reveal my temporary stupidity. But that’s ok. A few people might get a good laugh at my expense and I don’t mind.

I put some things into collections that only really need to show up at render time. I got it down to 2.8M verts and only 646 objects. Selection, moving things around, etc seem nice and fast.
I can hit play and it keeps up.
And if I put a keyframe on one object, just one keyframe, the fps drops down to about 4. Delete the keyframe? Still 4 until I clean up unused data.

I started hiding one thing after another and finally figured Something out, but it baffles me.
One assembly is linked in every product. It has an armature with a couple of driven animations. It’s a rubber flap on an AC and a DC plug. It had some sharp spots in the data so I also added a bevel modifier with those edges to be bevelled, and a weighted normal after that. But I had them disabled in the viewport. But the armature was showing.

I switched to matcop and switched on backface culling. I was getting 8fps and only have 1 LocRot keyframe on 1 parent. That’s it.
If I disable the armature modifier also it goes from 8-14fps. Hide just the copy of the object with that on it and it goes up to 60fps, which seemed to be where my machine maxes out no matter what, and that’s fine.

It seems odd to me that even if the modifiers are disabled, it still makes things crazy slow, up until the object is hidden from the viewport. But anyway that’s ok for me. I can see the bones moving to know if the door is open or closed visually in the viewport. It’s just that troubleshooting odd behaviors like this in blender is somewhat infuriating.

edit:
I started enabling more and had to turn off the handles too. And then I realized the common denominator is that the objects are using drivers. For the handles I had 2 versions, but the only difference was the length of something, so I mirrored them and “stored” each version by moving an empty back and forth to control the length. I only needed 2 lengths, so using a driver was easy to just have it as 0/1, basically short or long. Then I used a driver to put the handles up/down. That seemed easier than dealing with constraints in this case. Who knew simply having a driver would cause my scene to grind to a hault? (hint: it wasn’t me)

Unfortunately I can’t share the scene because it’s client data. It’s all public though, so I could show people, but I’m not comfortable asking the client if it’s ok to have a video out there in the public until after I deliver. But if someone were willing and interested I’d be happy to walk through it via screen share.

Update:

I thought I had it figured out. But I can’t play back still. In my animation scene I decided to just keep the collections instanced and create proxies as I need them.
Starting off, Already terrible. As soon as I put a keyframe on the parent empty, nearly no playback.

So I went to one of my files. I liked the UI, a power plug assembly, and the handle, which is duplicated for the other side of course. But those have overrides. I just did it that way to keep the data consistent between the 8 products.

But in that file, set a keyframe on the parent? And it drops.
The handle and plug both Had driven properties. I got rid of those though, just to be sure that wasn’t the issue.

After screwing about for a Long time, I ended up basically scrapping the way the handle was built. I got rid of the drivers for the 2 different lengths and I was mirroring the parts as well (even though the screws are technically wrong) and for whatever reason mirroring modifiers were causing a big slowdown as well.
So I instanced each object and scaled -1 in the mirrored direction. Moved things where they needed to be, and applied transform constraints.
So now instead of moving 1 empty to control my length I have to move 3 objects. Not a huge deal, but those things add up.

For the object with the armature, I ended up changing visibility of most all of the objects there to now Show in Viewports (at the object level, not the same as hide in viewport) and that causes blender to not evaluate whatever it was evaluating. So in the viewport, I’m just seeing a hole. I left one basic object just to be sure things are aligned.

I just figured I’d leave this here for anyone that might be searching for this later.

But that goes back to why I wanted to know if there was a way to tell which part of the scene was slow. Like in UnrealEngine you can show a gradient ramp of what is taking the longest to calculate. I probably could have figured this out a little faster at least.