[adoby]

Did you make any improvements in this direction?

Just looking around again for more tools.

[adoby]

@Gavalakis
It’s a nice tool, for small projects. but we are not looking at small projects here.
We can’t just use a tool and find out mid-development that we get memory problems.

Thats why we made the tests and try to get support. If it’s not foreseeable to fix the high memory usage, then thats a nogo in the long run.
It’s totally nice for smaller projects and I’m not saying that you coded something bad.
FlowCanvas is powerful and works better than most of the other tools I used in terms of compile time and integration.
We probably just hoped that there would be a playmaker replacement/blueprint equivalent that wouldn’t have a major drawback.

@rixter
Talking about RAM, its increasing linearly.
Small test with 2000 flowscript doubled the RAM usage as well.
And our test uses a very small flowScript, you would need way more states to create a working app.
We can’t make a real world experiment, that would take too much time.

Have a nice day/night
We may take another look at it.
Maybe you find something that lowers the memory usage.
E.g. Editor properties like Descriptions, Names of states etc. in the build.

[adoby]

We don’t care about editor memory usage, but editor performance.
But thats okay as long as the build works, which it doesn’t !

Compare ScriptInBuild vs FlowCanvasInBuild and you can see, that 30MB IS NOT the “total memory usage”
But only the usage of FlowCanvas alone.

Here:
Empty Scene performance and memory

Unity alone 360kb and scripts 80kb more
As we can see easily, FlowCanvas uses about 26,7MB more memory in build than anything else.
All Tests done with Unity 5.3.4f btw.

Attachments:

You must be logged in to view attached files.

[adoby]

We are not looking for a “complete replacement”.
We are looking for a system which our artists or even us coders can use to add quick functionality (as said above).
The base app will be coded.

But look at the FlowScript I made. Its like 4 States (less then nothing?).
Using nearly 30MB just for that is ridiculus.

We are looking at a worse case.

[adoby]

Here:
Test Project
(Commented out the 2 defines after doing the tests)

Attachments:

You must be logged in to view attached files.

[adoby]

New:
FlowCanvas in Build
Script Overview
Script Performance

Attachments:

You must be logged in to view attached files.

[adoby]

Here.

You have to look at “ManagedHeap.UsedSize” under “Other” if you are looking at Detailed view.
But we just look at “Mono” at the Simple View which is sufficient.

I Redone all the tests to have clean and comparable samples.
This simply shows that FlowCanvas uses way to much Memory compared to simple scripts with the same logik.
As well as bad performance in editor.

Here:
FlowScript overview
Editor Performance

Attachments:

You must be logged in to view attached files.

[adoby]

From my side, I wouldn’t use any visual coding at all.
But i can not work on all projects at onces.

Artists often ask for a simple way to add new functionality on the fly (like button clicks, or animation triggers)
I can not recode all of that (i wouldn’t have time for anything else).

So we need a visual scripting tool (sorry but blox is not the way to go :P)

FlowCanvas has a lot of very good features like instant code reflection thingies which designers can use instantly.
Playmaker just needs to much work (creating custom actions for everything is not efficient)

We would really like to use flowcanvas in production, but the drawbacks on performance and memory are to high.

UScript on the other hand is cool, but reflection is very basic (you can’t even set the position of a transform without custom action?) and compile time limits efficiency by a lot.

[Author]

Posts