Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Gua

Pages: [1] 2 3 ... 11
PlayMaker Announcements / Re: Keyboard Shortcuts
« on: July 23, 2019, 07:23:18 AM »
Can we get a shortcut for lock button?

I don't want to thread jack, but can anyone give me a quick run down on why I might want to use PP v2 rather than v1? It's still relevant to this thread because if I want to use v2 then I'll likely want to get this asset too.
PP v2 has SMAA which is my favorite Anti-Aliasing type.

Share New Actions / Re: Post Processing V2 Full Integration
« on: July 23, 2019, 03:17:33 AM »
@waveform, Thanks! In your screenshot with actions list, I don't see any action related to anti-aliasing. Are there plans to add those actions?

@djaydino, will a more powerful CPU improve performance for this use case?

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.

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.

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?

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. :(

If the link is a url, it should show up.

what kind of link are you sending?

Better you guys continue here, so we all can see whats going on.
I need to send him links to my project. So at least that part should be private. Actually I did send him links, multiple times, but he replayed that he doesn't see those links in the private message, that's why I want to switch to e-mail. Cause PM system in this forum seems bugged.

Since you've stopped responding to PM messages. I got worried. Please confirm that you received my last message regarding links to the project. Also, if you send me e-mail address for communication. It will be great, cause forum PMs seems unreliable. 

Okay. I figured it out. For anyone who has same issue. For some reason there's two parameters called orthographicSize. You need to select the one that is in the bottom of the list.

Unity 2018.3.0f2. Playmaker 1.9.0p5



 can you share this project so we can look at it? 5-10fps is very low, something is odd here. Have you ran the editor profiler to see what's going on?

- what version of Unity are you using?
- what version of PlayMaker are you using?


Sorry for late response.
Unity 2018.3f2. Playmaker 1.9.0p5. It's actually easy to reproduce in fresh project. Just add 30 fsms to any object and have inspector opened. In empty project it will be better than 5 fps, but performance decrease will be noticeable.

I did send you real/test project. (Check your PM).

Here's what profile shows in my real project. As expected it's InspectorWindow.DrawEditors

p.s. Maybe there's a component that is responsible to what is being shown in inspector and I can private most of the stuff there to prevent it from showing it? Cause I usually only need Name. Edit button. Template field and reset on disable.

Performance was noticeable better in Unity 5.6. So I suspect that Refresh button (I mean drawing it 30 times) is what consuming a chunk of performance. By the way. Can someone explain to me what refresh button does?

Here's same object in Unity 5.6

Pages: [1] 2 3 ... 11