playMaker

Author Topic: Editor performance on gameobject with lots of fsms  (Read 7219 times)

miguelfanclub

  • Full Member
  • ***
  • Posts: 165
Re: Editor performance on gameobject with lots of fsms
« Reply #15 on: June 28, 2019, 07:04:53 AM »
Not related to the inspector issue but in my project, not showing scene view as well as not showing playmaker editor window, makes the game to be +15 fps in game while playing.

djaydino

  • Administrator
  • Hero Member
  • *****
  • Posts: 7615
    • jinxtergames
Re: Editor performance on gameobject with lots of fsms
« Reply #16 on: June 28, 2019, 07:24:27 AM »
Hi.
Yes any active window can potentially slow down the fps.

for best Performance testing you should make a build of your game.

Gua

  • Beta Group
  • Sr. Member
  • *
  • Posts: 309
    • Andrii Vintsevych
Re: Editor performance on gameobject with lots of fsms
« Reply #17 on: June 30, 2019, 05:43:33 AM »
For me it is cleary inspector stuff. You can see it in profiler and as soon as I deselect gameobject with those fsms, my editor performance returns to the way it should be. And it's the work around that I currently use to be able to work with those fsms. I even have a script with a bind to mouse button to quickly deselect gameobject. But this workflow creates a extra clicks and inconveniences, that's why I would prefer to find a fix for this issue. But I'm repeating myself.

It's a shame that it's so hard to get support for Playmaker. Aside from this topic I've send PMs and e-mails regarding this issue, but got no response. And as soon as this topic finally got a response, everything immediately stopped and now we're back on the halt. I've created this topic 3 months ago, but there was absolutely not progress toward solution for the issue. :(

« Last Edit: June 30, 2019, 05:54:37 AM by Gua »

miguelfanclub

  • Full Member
  • ***
  • Posts: 165
Re: Editor performance on gameobject with lots of fsms
« Reply #18 on: June 30, 2019, 08:47:51 AM »
Maybe a playmaker downside and nothing to do.
I never work with more than one (max 2) FSM in the same game object.
Its SUPER tedious.

djaydino

  • Administrator
  • Hero Member
  • *****
  • Posts: 7615
    • jinxtergames
Re: Editor performance on gameobject with lots of fsms
« Reply #19 on: June 30, 2019, 12:05:03 PM »
Hi.
I can assure you that they are trying to find a solution.

This issue has been there for a long time, but it did get worst with the latest unity version.

Main issue is unity's design to get things working in the inspector.
Each open component is updated continuously .

For example when you expand a collider in the inspector it will be seen in the scene view and updated.
When you collapse it the collider is not shown in the scene view.

Playmaker holds a lot of data in the backend (not visible) to show every state/action/transitions/colors/names/positioning everything/etc which gets updated all the time when not collapsed.

That is the main Reason fsm with lots of states also tend to slow down.

also, if you have a fsm with many states it will show a note


I actually use many fsms as well on a single object (like player or enemies)

when i need to edit or test some variables from within the inspector and have many fsms, i tend to collapse all.
Then play and expand the one that i want to test values from.

if unity's inspector would be able to expand/collaps component of the same types individually , it could solve already a lot of lag.

Gua

  • Beta Group
  • Sr. Member
  • *
  • Posts: 309
    • Andrii Vintsevych
Re: Editor performance on gameobject with lots of fsms
« Reply #20 on: June 30, 2019, 12:24:13 PM »
Hi.
I can assure you that they are trying to find a solution.

This issue has been there for a long time, but it did get worst with the latest unity version.

Main issue is unity's design to get things working in the inspector.
Each open component is updated continuously .

For example when you expand a collider in the inspector it will be seen in the scene view and updated.
When you collapse it the collider is not shown in the scene view.

Playmaker holds a lot of data in the backend (not visible) to show every state/action/transitions/colors/names/positioning everything/etc which gets updated all the time when not collapsed.

That is the main Reason fsm with lots of states also tend to slow down.

also, if you have a fsm with many states it will show a note


I actually use many fsms as well on a single object (like player or enemies)

when i need to edit or test some variables from within the inspector and have many fsms, i tend to collapse all.
Then play and expand the one that i want to test values from.

if unity's inspector would be able to expand/collapse component of the same types individually , it could solve already a lot of lag.
Here it is clearly visible that drawinspector is what takes away performance
So I assumed that drawing all those buttons and other fields related to Playmaker script in inspector is what takes away performance. So if drawing that script was not backed into *.dll I would just open that script and used a lot of [HideInInspector] to hide fields that I usually don't need, to improve performance. But from my understanding I can't do/test this, cause it's backed into *.dll correct?

djaydino

  • Administrator
  • Hero Member
  • *****
  • Posts: 7615
    • jinxtergames
Re: Editor performance on gameobject with lots of fsms
« Reply #21 on: June 30, 2019, 01:36:12 PM »
Hi.
I think you misunderstand what i mean.

it's not about what you see in the inspector.
its about what it does when not collapsed to the scene.

When you look to the collider example :
When expanded, it draws the collider in the scene when selected and it is called continuously .

Now for the playmaker component when expanded it will do the same,
But playmaker holds a lot more data.

Each state/state position/state color/action/transition/colors and so on are stored on the component.
Even the basic fsm with no actions yet inside has already a bunch of data to make things work.

And this is called every time for each playmaker component.

Playmaker actually does not need to be refreshed every time in the scene, but that is a unity limitation and can not be disabled.

as well a for expanding a single component of the same type, wich would already improve the performance for PlayMaker

Gua

  • Beta Group
  • Sr. Member
  • *
  • Posts: 309
    • Andrii Vintsevych
Re: Editor performance on gameobject with lots of fsms
« Reply #22 on: July 01, 2019, 04:36:55 AM »
Hi.
I think you misunderstand what i mean.

it's not about what you see in the inspector.
its about what it does when not collapsed to the scene.

When you look to the collider example :
When expanded, it draws the collider in the scene when selected and it is called continuously .

Now for the playmaker component when expanded it will do the same,
But playmaker holds a lot more data.

Each state/state position/state color/action/transition/colors and so on are stored on the component.
Even the basic fsm with no actions yet inside has already a bunch of data to make things work.

And this is called every time for each playmaker component.

Playmaker actually does not need to be refreshed every time in the scene, but that is a unity limitation and can not be disabled.

as well a for expanding a single component of the same type, wich would already improve the performance for PlayMaker
I did understand it the first time and as far as I know, you might be 100% correct. But considering your explanation I find it weird that profiler shows resource consumption as DRAW inspector. That's why I would love to test your assumption by hiding most fields and buttons from inspector to see if there will be any noticeable performance difference. But if I understand it correctly, code that is responsible for Playmaker script interface in inspector is hidden in *.dll so I can't perform that test.
« Last Edit: July 01, 2019, 04:51:57 AM by Gua »

djaydino

  • Administrator
  • Hero Member
  • *****
  • Posts: 7615
    • jinxtergames
Re: Editor performance on gameobject with lots of fsms
« Reply #23 on: July 01, 2019, 06:24:57 PM »
Hi.
On your Profiler image you can see that it is actually the DrawEditors @2:02
and not draw inspector.

Hiding fields will not change anything.

But yes the core of Playmaker is inside the .dll file

Gua

  • Beta Group
  • Sr. Member
  • *
  • Posts: 309
    • Andrii Vintsevych
Re: Editor performance on gameobject with lots of fsms
« Reply #24 on: July 03, 2019, 04:10:35 PM »
I actually would be fine with collapsed Playmaker scripts. The problem is that I prefer to used Playmaker with Locked view. That means I need edit button of Playmaker script to be visible, to start editing script on selected gameobject and as soon as I select one fsm on gameobject, playmaker provides great tool for fast switching between fsms on gameobject that hosts fsm that I'm currently editing. So the issue is only in initial first step, when I can't start editing fsm unless I "uncollapse it" or uncheck Lock button and relesect game object and check lock again, which is not very convenient.

update: Although I've just found a problem with templates, where quick switch tool is useless when you have templates on your fsms on game object like here.

« Last Edit: July 03, 2019, 04:13:36 PM by Gua »

djaydino

  • Administrator
  • Hero Member
  • *****
  • Posts: 7615
    • jinxtergames
Re: Editor performance on gameobject with lots of fsms
« Reply #25 on: July 03, 2019, 07:42:34 PM »
Hi.
It might help to categorize the Templates, when you select a template you can give it a category, and even sub-categories when using slash.





You can also 'multi select' a bunch of templates and set a category then for all selected.



I never knew it was there, i only noticed this like last week.

Btw if you have the templates in the standard folder, you should move then to another folder outside the PlayMaker folder.
It happend to me once that i deleted playmaker to reinstall and lost all templates.

These days its not possible anymore with me as i use github for all my (and my customers) projects, so i can always discard or revert changes.

Gua

  • Beta Group
  • Sr. Member
  • *
  • Posts: 309
    • Andrii Vintsevych
Re: Editor performance on gameobject with lots of fsms
« Reply #26 on: July 17, 2019, 09:51:11 PM »
@djaydino, will a more powerful CPU improve performance for this use case?

djaydino

  • Administrator
  • Hero Member
  • *****
  • Posts: 7615
    • jinxtergames
Re: Editor performance on gameobject with lots of fsms
« Reply #27 on: July 18, 2019, 11:24:47 AM »
Hi.
it depends on you current cpu if its really old, but i don't think it will speed up much.

Gua

  • Beta Group
  • Sr. Member
  • *
  • Posts: 309
    • Andrii Vintsevych
Re: Editor performance on gameobject with lots of fsms
« Reply #28 on: September 19, 2019, 11:00:34 PM »
Hi.
it depends on you current cpu if its really old, but i don't think it will speed up much.
I've just build new PC with Intel Core i9-9900K (previously I was using intel i7 3770k). As soon as I hooked up SSD with my project I've immidiatly intalled Unity to test inspector performance. And I'm happy to report that new hardware sagnificatly improved editor perfomance. Profiler shows 43% improvement. When I actively scrolled over game object with lots of FSM components I previously got 133 ms and now I get 93 ms. I can also add, that when I needed to edit any fsm on that object I had to deselect selected gameobject, because performance was just too poor even for a small edit. And now it's much more smooth, so seems that I can stop doing that :)
« Last Edit: September 19, 2019, 11:02:42 PM by Gua »