This attached video demonstrates an issue using box/marquee select on control rig controls. Their on screen size determines how likely they are to be included in the selection which isn’t a reliable enough method for animators. Our workarounds include turning on “Box Select Occluded Objects” and increasing the viewport screen percentage, but both of these come with their own drawbacks
The related issue to this is that (being constant size static meshes) the controls are too small when far away, and too large when up close. We meed to have controls be a constant (or more intelligently adaptable) pixel width regardless of view distance
Thanks for raising this, there is a bug here since the animating with the rig has its own editor mode and does it’s own selection determination. You can follow along here: https://issues.unrealengine.com/issue/UE-353919
Apologies for the delay in responding, I was looking for a fix or small workaround you could do to help the issue, but there really isn’t. If you wanted to, you could take a look at FSelectionHelper::GetFromFrustum in ControlRigEditModeUtil.cpp. In there we, for items that are not occluded, we have a heuristic to do the selection.
That said, I’d be curious as to what the drawback is for “Box Select Occluded Objects” (not with the screen percentage adjustment), as that would be the recommendation we would give. It takes in the box selection frustrum and selects everything within it.
> I’d be curious as to what the drawback is for “Box Select Occluded Objects”
It actually works well, and replicates the experience they get in maya. The “drawback” is that we can’t expect every animator to set up the dozen or so editor prefs to make unreal animator friendly in each of their project workspaces - so we like to set them project-wide in Config/DefaultEditorPerProjectUserSettings.ini. But this inflicts these prefs on *all* users, not just animators, and not everyone may want “Box Select Occluded Objects” (but all animators do for sure).
This touches on wider issue that (perhaps warrants a separate EPS?) where unreal doens’t seem to have a config level for user prefs that apply to all of a users’ projects. This discourages users from tweaking out the editor to make it better suit them, since they have to redo all those prefs in every workspace, or go through the export/import ini process which isn’t feasible to keep in sync across more than a couple of projects.
The other 2 issues mentioned in my OP are
8-10ms performance degradation when many ctrls are selected
Controllers (being static meshes) means they get bigger and obstruct the viewport when camera is close to the character
Are these issues on the radar already? I’m happy to open separate EPS for these if you think it would help with tracking
This touches on wider issue that (perhaps warrants a separate EPS?) where unreal doens’t seem to have a config level for user prefs that apply to all of a users’ projects.
We do have ongoing work here to make this better in the future. I don’t have a timeline, but we are looking to cover a few scenarios both within the editor UX and saving preferences out.
8-10ms performance degradation when many ctrls are selected
There are a few things that can affect this. Is it just when selected, or you have many ctrls selected and you manipulating them? Do you have many event and manipulation triggers in your rig? If you’ve debugged the peformance of your rig, are they extremely extensive?
We can narrow down other engine performance concerns, if you do an Insights capture with STATNAMEDEVENTS turned on and send it our way.
Controllers (being static meshes) means they get bigger and obstruct the viewport when camera is close to the character
This is something that I can raise as to the animation in engine team as a feature request. Are you thinking, something like Maya curves is better for you visually?
8-10ms performance degradation when many ctrls are selected
> Is it just when selected, or you have many ctrls selected and you manipulating them?
Its simply selecting them. The performance drop is noticible on manny’s rig, and its even more pronounced on our custom rigs which have much more controls. Interacting with (dragging) the controls will cause the performance to drop even further. We generally struggle to hit hit 30fps when working in CR, with the bottleneck being game thread. Performance varies depending on if we are camera orbiting, scrubbing, playing or interacting. It does scale well when adding multiple chars, but I feel there is a large inital performance tax in putting a single CR in animation mode
> Are you thinking, something like Maya curves is better for you visually?
Yes probably. It’s just the current controls can be a bit intrusive, and they participate in rendering effects like dof, gi, motionblur, reflections which isn’t ideal. Maybe there are ways to solve that without implementing curves. Like perhaps the ctrls could become thinner as they get closer on screen, or ctrls only appear when the mouse is near them. Or an option where all the controls would become hidden other than the ctrl which is currently being dragged / interacted with. Our custom pickers also help a lot. So its not a deal breaker, its just something that could be better