Hello!
I was working on a tool for our art team that involved creating a custom FPrimitiveColorHandler, registered to the FActorPrimitiveColorHandler. It works great, until you try to swap to another visualizer mode, which is a common workflow for our team, at which point the scene colors do not update to the new visualizer. I have put a breakpoint in code and see in `PrimitiveComponent::PushPrimitiveColorToProxy` that the new colorizer is being called, and returning a valid, different color for the objects, but it never visually updates in the scene view. Even though I was creating custom visualizers, I was able to reproduce this even with two built-in visualizers. I have attached screenshots showing this in a test scene with some basic speedtree trees.
Notably, if you stream in new trees after switching to the new visualizer, they are colored correctly, but then “stuck” in this new color. Additionally, I’ve been able to “fix” this issue by using live coding to reload the relevant modules, and that refreshes the visualizer view…but they get stuck again later. This implies to me there is some caching happening that shouldn’t be?
Any guidance appreciated! If there is a CL already that fixes this, I am happy to integrate it into our codebase, since I know we’re on an outdated engine version!
Steps to Reproduce
Open a level with some basic static geometry, configured in a way such that any two actor colorizers would show different colors
PIE
Eject to the Debug Camera
Set your first visualizer, and notice the colors are correct
Swap to your second visualizer and notice that the colors do not change
Hi there,
Thanks for the reproduction steps, I was able to reproduce this issue in 5.4 and the latest source version.
From debugging and reviewing the code, the only insight it can provide is that it uses the GWorld global world reference for the world context when changing coloration view modes, which may not be the current PIE world, but instead the editor world.
Updating the viewport code, which changes the coloration mode to check for a PIE world, appears to fix the bug, at least in the latest source build. Swapping GWorld for GetWorld()
FULL DISCLAIMER
I have not validated this code beyond this test. There may be a good reason not to do this or a more elegant way.
EditorViewportClient.cpp : ~2925
void FEditorViewportClient::ChangeActorColorationVisualizationMode(FName InName)
void FEditorViewportClient::ChangeActorColorationVisualizationMode(FName InName) { SetViewMode(VMI_VisualizeActorColoration); FActorPrimitiveColorHandler::Get().SetActivePrimitiveColorHandler(InName, GetWorld()); }I’ll create a bug report and reply with a public tracking link once it goes live.
Let me know if this works for you.
Kind Regards,
Keegan Gibson
Hi Keegan,
Thanks for the update. That makes sense to me.
Unfortunately, in 5.4, that FEditorViewportClient::ChangeActorColorationVisualizationMode function doesn’t exist. This engine version is from before Actor Colorizors were made into view modes -- they’re currently a separate, special sub-option. I’ll try to find an equivalent function and let you know how it goes.
Okay, I believe the equivalent code in my version is SLevelViewportToolBar::FillViewMenu::1883. Replacing it as follows appear to resolve the issue:
// FActorPrimitiveColorHandler::Get().SetActivePrimitiveColorHandler(PrimitiveColorHandler.HandlerName, GWorld); FActorPrimitiveColorHandler::Get().SetActivePrimitiveColorHandler(PrimitiveColorHandler.HandlerName, ViewportClient->GetWorld());I’ll continue testing, but my initial attempts work just fine, so I’m going to accept this as the answer for now. Thank you!
Hi there,
Here is this public tracking link for the issue: Unreal Engine Issues and Bug Tracker (UE\-305931)
If that workaround works for you, I’ll close this support request for now, but if you need anything else, please feel free to open a new support request.
Kind Regards
Keegan Gibson