I am using ArcGIS Pro 2.9.3 and have applied a rule package to a building footprint layer with almost 1 million footprint features using a modified version of the Standard Building cga in the Complete Streets example. I am trying to improve refresh performance and am looking for suggestions. I am not satisfied with the options I have tried so far. Prior versions of Pro gave Excessive Refresh Requests errors if I moved the camera in the scene before waiting for each refresh to complete using this layer. Fortunately Pro 2.9.3 seems to have fixed this behavior which at least allows the layer to complete the final refresh when I get the camera where I want it, but refresh performance is still slower than I like once I get to that point.
The only suggestion I have seen in the Pro help is to limit the layer scale that will draw in the scene. I have limited the layer scale to 2 miles, which is probably the ideal scale limit for my needs. It works better than having no scale restriction, but it still takes a long time (3 to 5 minutes) for the rule to refresh whenever I pan to an area that forces the cache to reset. Even if I change the scale restriction to a significantly smaller value the refresh performance does not improve very much, and the level of improvement is not worth the limitation of what can be viewed in the scene. It seems that most of the refresh time is still being used to evaluate the vast set of features that ultimately are not displayed.
I have 3D Analyst and considered converting the buildings into multipatch features, which does improve performance. If I exclude textures and colors when I build multipatches for the buildings the fgdb file is almost 2 GB, which is a reasonable size. However, I want the rule textures in the final symbology and I don't know of any way to apply the rule textures after generating multipatches it I didn't include the textures through the conversion tool. Unfortunately, if I include textures and colors when I generate multipatches the output file would be between 300 to 400 GB (I cancelled the tool when the file grew to 55 GB after about 15% of progress). That is too large to be justified.
I haven't tried this option, but applying a definition query on the layer to limit the extent displayed by the layer using fields with an attribute index, like fields containing centroid coordinate values or community names, should improve performance. However, most of my users wouldn't know how to adjust the definition query when they moved beyond the initial query limits.
I could setup separate scenes in advance that limit the amount the user can move, but I don't think my users would know which scene they needed to open to view a particular area given the large number of communities my jurisdiction covers.
Setting up tiled layers could be done and placed in a scene, but I would think that performance would only be improved if the layers knew how to turn their visibility on or off in response to the camera position. It is unlikely my users could manually manage to adjust the layer visibility settings any better than they could manage separate pre-made scene files. I don't think there would be any improvement over using the original feature class if the user eventually ends up setting all of the tiled layers to being visible all the time.
Is there something I am overlooking? I know how to program and am learning the Pro SDK, so a custom solution is possible. But I was hoping that applying some out of the box techniques would make going that route unnecessary.
