Enscape 4.0+ (specifically 4.1.1)- Why is Enscape force-replacing the Revit icon/taskbar icon?

[twiceroadsfool]

Its been happening since 4.0, but i would like to know what the reason is, that Enscape is doing this:

All you need to do is launch Revit 2025 (i assume the earlier ones as well) from a pinned Quick Launch shortcut. Revit will use “its own” icon until it fully loads and gets to the Home Screen, at which point Enscape loading hijacks it and moves it to another Revit 2025 icon, doubled up in the QL bar. Why is this?

Removing Enscape from the loaded addins makes the problem go away.

Its a minor inconvenience, but im trying to figure out the logic that means i would now have to explain this to users. Why are you doing it?

[Demian_Gutberlet]

Hi @twiceroadsfool , thanks a lot for your inquiry and the report generally.

This behavior is/was to be expected as we’ve added a so called Application Model ID which is like a name tag that Windows uses to recognize and group related applications together on your taskbar in this case Revit and Enscape. This change was necessary starting with 4.0 because Enscape now runs as a separate process.

Next to any technical explanation, to resolve this issue and refresh the icon, you can simply unpin and then repin Revit (2025 in your case) to your taskbar.

Let me know in case of any further inquiries regarding this or any other subject.

[twiceroadsfool]

Well, its not really that straightforward:

1. We (and a lot of our clients) replace the icons for Revit, and we do it where the real icon is stored, in %systemroot%\Installer, etc.

2. It isnt that you are simply spawning your OWN application inside the “group” because its MOVING where Revit is running, too.

3. When Revit is launching (before it gets fully launched) it is under our icon, where we would expect it.

4. After Enscape “does its thing” all of Revit has now moved to the “alternate location.”

This means a user clicking on the R25 will launch another whole session of Revit, accidentally.

You guys appear to be using Icons stored in the actual Revit.exe, which isnt how any of the standard shortcuts work, for any of the Autodesk Applications.

For instance, the Icons your “new shortcut” uses, are stored in: C:\Program Files\Autodesk\Revit 2025\Revit.exe

The Icons used by default are stored in: %SystemRoot%\Installer{7346B4A0-2500-0510-0000-705C0D862004}\REVT.ico

And just to clarify: You are saying it HAS to be this way? Because no other program we use that works with Revit HAS to do this, and im not inclined to release it in to a bunch of clients offices, with it behaving like this. Its silly, and it didnt use to do it.

If im understanding correctly, you are saying if ANYONE “pins” a Revit shortcut to the QL bar before its fully launched and enscape has “changed” it, they are going to have to unpin and repin it. Why on earth would we go through all of that?

[Demian_Gutberlet]

Thank you for your comprehensive response and the additional details.

Allow me to bring this up for discussion internally once more given the scope of this behavior and I’ll reach back out to you once I have any additional news/information to share soon in regards to what we can do from our side here in the near future. You can expect a further reply from me soon.

[Steve_Bennett_1]

Hello @Demian_Gutberlet - I will second Aaron’s findings and also confirm this happens with Revit 2022 as well as 2024, current versions. I will mention that I brought this up previously to @Phillip_Miller_1 (your VP of Product Management) at a recent in person event, but I was probably not able to describe what was happening as eloquently as Aaron did above.

I will also add, unpinning and re-pinning the icon does nothing to fix the icon and bring back the custom icon we assigned to Revit. Without this, we have no way to distinguish which icon represents 2020 vs 2022 or 2024 vs 2026 and so on.

I have to say, I’m a bit troubled by the direction Enscape has taken with this change in how it handles application loading. As you’ve described above, it almost seems like a way to hijack a program and inject something it was not originally designed to do from Autodesk. We want to start utilizing some of the great new features in 4.0, but we too have paused our deployments until this can get resolved. I know it might seem minor, but having consistent display results with the application icon is mission critical for us. Please escalate this ASAP.

[Demian_Gutberlet]

Welcome to our Forum @Steve_Bennett_1 - Right away, thank you very much for your input.

I have shared your feedback and general concerns in regards to this behavior with our developers as well. As soon as I have more information on any upcoming updates or related news, I’ll be sure to reach out to both of you right away.

Thank you in advance once more for your patience as well, please of course let us know in case anything else may come up in the meantime.

[Demian_Gutberlet]

@twiceroadsfool and @Steve_Bennett_1 , as stated I have reached out to our developers so allow me to forward their more comprehensive input directly to act as an explanation while providing additional potential workarounds as well:

The root cause of these changes is that since version 4.0, Enscape runs in a separate process from the host Cad.

A separate process allows us to support both Windows and Mac at the same time, and also newer Cad versions such as Revit 2025. It isolates the Cad from instability in Enscape, and vice versa. The limited amount of Enscape code which remains inside the Cad process is just enough to channel the necessary information to and from the Enscape process.

The only downside of this design is that Windows no longer recognizes Enscape windows as being owned by the host Cad. When taskbar grouping is enabled, they end up in their own group and it becomes very difficult to tell which Cad they are associated with. Worse still, if multiple Cads are running Enscape at the same time then all Enscape windows from all Cads are grouped together.

Windows provides a system to resolve this problem: the App User Model (https://learn.microsoft.com/en-us/windows/win32/shell/appids). We just have to give the Enscape process the same App User Model ID as the host Cad, and its windows will be treated as windows of that Cad. They will appear in the correct taskbar group and everything will work as expected.

The catch is that Revit doesn’t define an App User Model ID of its own. At startup we detect this and give it one, before applying the same ID to our own process. This is the point at which a new icon appears on your taskbar: the pinned icon has no ID, so is not considered the same as the current Revit process.

There are some potential options/tips for resolving this (eventually):

1. Manually pin the new icon and remove the old icon. You will then need to re-apply the custom icon. (This may not work in your situation but can be a workaround for some users)
2. Write a small program which updates your existing Revit taskbar shortcuts to add the App User Model ID which Enscape generates for Revit. We can provide these values to you. Unfortunately the API provided by Windows for this simple task is very obtuse.
3. Forward your request to have Autodesk define an App User Model ID for Revit. This is something that they ought to be doing anyway given that once Revit has its own ID, Enscape will no longer generate one for it. (Thus we generally encourage our users to reach out to Autodesk as well if possible so they’ll receive that feedback not just from us.)
4. Submit a feature request to add a (hidden) functionality which disables the App User Model changes we make on startup. This will result in Enscape windows appearing in a separate taskbar group, as described above. (Feature requests can always be forwarded to product management directly as detailed here)"

I hope this further explains the situation behind this behavior and why it’s not as directly solvable as we like. If there’ll be any additional questions in this regard please let me know as well.

[twiceroadsfool]

LOL, well, okay.

We aren’t doing any of those options, to solve a problem that didn’t exist last year.

I would much rather Enscape just show up on its own in the QL bar, than do this janky stuff. If that isnt an option right now, i guess we (Parallax) are back to having Enscape on hold (not deployed) until it gets resolved. It stinks, as Enscape has been our goto for the entire 9 years we have been in business, but im not about to have to explain to users that they will need to manually unpin, repin, and redo icons for every version of Revit because ‘Enscape said so.’ Thats wild.

If and when you guys get that “hidden functionality” to turn off this behavior, let us know. Then we can reconsider. But we had to do the legwork to deploy Twinmotion before we knew the Licensing disaster was getting “fixed,” so there isnt a reason for us to have to deal with this issue now, until you guys resolve it.

[Steve_Bennett_1]

Thanks for the welcome note to the forums, Demian. However, I’m in the same boat as Aaron. We will hold on deploying or upgrading to 4.x until this is resolved. I’ll have to also inform others I know of this downside in the tech circles I collaborate in. I would imagine many will likely hold off deploying and as a downstream result, not pay for upgrading licenses at the same time. Perhaps now is the time we have been waiting for to make the switch to Twinmotion.

[Mehmet_Gunduz]

Hi @Steve_Bennett_1 , @twiceroadsfool ,

I’m Mehmet from the Enscape Product Management team.

Thank you very much for your kind messages. They are very helpful for us to understand your needs so we can prioritize solutions accordingly. Of course, the number of requests is much higher than the resources we have available, but we are doing our best to prioritize efficiently.

As Demian is on vacation, I wanted to chime in and provide a small update/correction. You don’t need to submit your request through our idea portal because the good news is that this feature is already planned for upcoming versions. Most likely, it will be included in the service pack we plan to release after version 4.2 (aka 4.2.1). By the end of the year, we aim to roll out the feature Demian mentioned, which disables the App User Model changes we make on startup. I’m glad I stumbled upon this thread and can share this good news with you.

Since this request primarily comes from mid to large sized companies, we will be adding it as a new deployment setting that will allow admins to configure this for their users. This means it won’t be an option within the Enscape UI, but we will provide a way for Admins to deploy it using your preferred method. As a result, users will simply see a separate Enscape icon on the Windows taskbar. Please note that we don’t expect any downgrade in user experience, and the Alt+Tab behavior will remain unchanged. However, when using the taskbar, users may find it difficult to differentiate between versions of Enscape running within different CADs if multiple sessions are open simultaneously. Enscape will be grouped under its own icon, and there won’t be an indication of which CAD it’s attached to. If Enscape is running inside multiple CADs at the same time, its icons will be grouped together, even though the two CAD programs are separate.

(Side note: Enscape is a child window of the CAD program. So when the user clicks on the CAD icon, the correct Enscape window will be brought to the foreground along with the CAD main window, provided the “Pin Enscape on Top” option is selected.)

I hope this is helpful for you.

All the best,
Mehmet

[twiceroadsfool]

Hello Mehmet!

Thanks for the feedback.

Unfortunately, i think its just a situation of you guys not “reading the room” so to speak. For instance: Its pretty common i have three versions of Revit opened side by side, and MAYBE one of them has Enscape launched, at any given point in time. MULTIPLE Enscape’s at a time? I think the only time i’ve ever done that was when i was working a booth at a conference.

I will concede that maybe other peoples workflows are different, but: Revit is my primary tool, and im in it all day long. Enscape is a secondary tool that i use sporadically. Its WAY more important i can keep my Revit’s separated and clearly defined, than it is for my Enscape’s to not all be grouped together.

Right now, just starting my day, i already have a Revit 2022, 2023, and 2024 all opened. This is how it looks (since we opted to not deploy Enscape anymore, until this is fixed).

Glad to hear itll be fixed by the end of the year. I guess we will Twinmotion it until then.

[rifkin]

I may be a Luddite in this regard, but I always set the taskbar to “small buttons, combine when full” which gives Enscape its own tab in the bar. That allows the quickest access to get back to the Enscape window without the extra pause/hover/click with nested icons. Some users don’t even realize you can change that, and pretty much everyone I’ve shown it to appreciates the Enscape icon -not- being nested. (Granted, we are still on Win10, and it seems with Win11 we may not be able to exactly replicate those settings anyway.)

I can’t think of anyone within our firm (100’s of users) who would be running Enscape in multiple host software at the same time. If they are rendering in Revit, they are staying in Revit, there would be no need to also be rendering in Sketchup or Rhino. Or at least it would be incredibly rare. I also always assumed with GPU/VRAM limitations it was best practice to -not- be trying to run multiple Enscape sessions anyway.

I wonder if perhaps, internally at Enscape, since you are constantly developing/testing across all platforms, this may be something that your staff see as an issue, but is not in fact a real concern for your users? It just seems like an odd hoop to jump through, to avoid an issue that isn’t really an issue, while introducing a behavior that actually causes a bigger problem for your enterprise users?

Either way, thank you for acknowledging and promising a fix. As many have discussed elsewhere, with licensing issues and Rhino issues, there have been way too many hiccups forcing us to hold on older versions. If this could be solved sooner than later, it would be extremely helpful to have one less thing to mess with/fix as we roll out Revit 2025.

[Mehmet_Gunduz]

Thank you very much for your feedback!

Perhaps I over-explained earlier regarding the possible edge case annoyances. Please keep in mind that Enscape windows are affected in the same way—for example, the Material Editor—so it’s not only about opening Enscape more than once. Yet, the main user need remains, and this would still be considered an edge case. As you also explained with reasons, most of the time it is not a problem to use Enscape in multiple host applications at the same time. This edge case wasn’t the reason we hadn’t implemented it sooner; it was simply a matter of prioritization and having limited resources.

Regarding other hiccups such as Rhino and licensing issues, I feel you. In fact, perhaps I’m one of the people who is most concerned about these topics. It would take too much time to explain all the reasons behind them, but especially for Rhino, it was purely a struggle of switching to new technology, which will be beneficial in the long run. I wish it was just one bug we could fix. I believe we’re in a much better position now compared with the 4.0 version. We’ve addressed most of the main points already, and according to our tests, we’re achieving significantly better frame rates and have fixed problems such as the Rhino viewport becoming unresponsive for some projects. Of course, some problems are project-specific, and some still remain, but we’re doing our best to discover and fix those. That’s why, a while ago, on top of our QA efforts, we asked for your contribution to identify problems. If you still encounter any issues, please make sure to report them through our Customer Support so they are visible to us and we can fix them.

We’re in touch with McNeel (actually, we’re working pretty closely, which is awesome), and with our upcoming 4.2 version, things will be even better. On top of that, we’re also improving our output visual quality, but that’s only affecting about 5% of the creation times (compared with 3.5 version). So, we’re truly doing our best to address these issues. As for licensing, that’s why we immediately took action and provided the new floating license, but we know there are still more areas to improve on that front as well.

I tried to keep my response short, but I couldn’t help myself—sorry about that! Please be assured that we’re hearing you, whether it’s via the forum, the ideas portal, customer support, or during events.

Cheers,

Mehmet

[Steve_Bennett_1]

Thanks for the updates @Mehmet_Gunduz - appreciate you helping the devs understand the need for a fast fix for this. Please be sure to let us know where the documentation for this switch is, once its been published.

[colin_mccroskey]

It’s definitely unique to Enscape. Other plugins/add-ons do not act the same way.

Dynamo, Ideate, Rhino-Inside all respect the custom Revit icon group in the taskbar.

[Demian_Gutberlet]

@Steve_Bennett_1 @twiceroadsfool with Enscape 4.2, we’ve now introduced a new setting called “SuppressTaskbarIconGrouping”. When enabled, this ensures that each Enscape window appears as its own group in the taskbar. We’re currently preparing a dedicated knowledge base article on this feature, but in the meantime, you can refer to the following methods that apply to both Windows and macOS:

Please keep in mind: This will apply also to windows opened in the context of different CADs or CAD instances. Therefore, it may be hard to distinguish which window is associated with which running CAD instance.

The following screenshot illustrates the above note:

The user has opened the rac_basic_sample_project.rvt in Revit 2023. Then he started Enscape and opened General Settings and Material Library windows.

The user has opened another project in Revit 2024. Then he started Enscape and opened Material Editor and Asset Library windows.

As you can see all Enscape windows appear as one group separately from the CADs. That could become confusing and misleading, which is why we therefore do not recommend the usage of this option unless truly required.

[colin_mccroskey]

I might be an “edge case” but I like this much better.

It allows my customized Revit icons to work properly, and all my “Enscape stuff” is collected under an Enscape icon in the taskbar. I like this much better than having Enscape windows buried behind a Revit icon.

And while I have multiple Revit versions open almost every day, I can’t remember the last time I left multiple Enscape windows open for different projects.

I would not complain if this became default behavior in the next version of Enscape…

[Grey_Block]

Is there a dedicated knowledge base article for this yet? and/or preferably an easier way to remove the grouping other than a command prompt with admin privileges? asking IT to come and run this line of code so we can add a value into the registry at best raises a few eyebrows, but is often greeted with a ‘no’…

not sure why having enscape in its own group wouldn’t be the default anyways, we find it lumping itself into the Revit group pretty annoying. and this seems to be the opinion of everyone in here (so far).

i get that maybe it’s not easy to discern which enscape window belongs to which cad session, but even looking at the screenshot all I can think is “that’s still 100x better”. (and also, “why would we ever be running multiple enscape sessions?”)

[rifkin]

@Demian_Gutberlet - any guidance on this?

[colin_mccroskey]

I just had to do this registry tweak on a few new computers.

Is there any plan to make this the default behavior when installing Enscape?
It would save some time…