+9
Under Review
Lazlo Bonin (Lead Developer) 2 weeks ago • updated by Александр Жданов 16 hours ago 26 1 duplicate

I'll try to remove the loading times for unit caching and codebase analysis by caching the result in an asset and simply loading it with the editor.

On the downside, you will need to manually go through a small dialog to update the set of unit options after importing a third-party plugin or modifying your custom scripts. I'll take that occasion to make the Assembly Options and Type Options project settings more evident and better documented.

This may seem simple, but it's actually quite a big refactor! I'll try to get it done this week, fingers crossed!

Duplicates 1

This is currently the main culprit in my opinion. I have a beefy machine (intel 6700K, 32GB RAM, etc) and on a test project with a simple cube rotating, I get a 2-3 second delay when I press Play. Without Bolt it's instantaneous.

The Graph, Flow Machine and Variables inspector show a loading circle during this period.

Hope you can do something about it! Any how, incredible work!

Thanks for the feedback. It's helpful for me to know that for you, the delay occurs before these windows are done showing the spinner, and helps me pinpoint some causes of lag better. I'll do some heavy profiling in these areas and see if I can optimize anything.

Unity Ver-2107.1.0f3
iMac MacOS Sierra  Ver- 10.12.6 (16G29)
iMac (27-inch, Mid 2011)
Processor 3.1 GHz Intel Core i5
MEM 4 GB 1333 MHz DDR3
Graphics AMD Radeon HD 6970M 2048 MB
Unity running from a USB SSD drive

In th example Flow chart above from press play in editor to play in seconds over 3 tests - 18.39, 17.70 and 18.42.  Edit: On par with the below speeds after 2nd round of testing. 


In th example State chart above from press play in editor to play in seconds with 3 over -10.29, 13.69 and 14.49

---

Full Caching process when entering edit from play in seconds over 3 tests - 34.54, 36.62 and 37.40

This is on one of my systems, I will test from the others and post. Obviously this iMac is not a killer rig, but many devs will be using lower end specs so anything to reduce the load times is helpful.


Just a heads up to let you know that I've started profiling and thinking of optimizations.

I'll take the day off (it's Sunday after all!) but I'll be working on it further this week.


I am not sure if it is specific to the Mac version on Unity, but on my MacBook pro it is essentially unusable.  The delay you describe is too painful to be productive.  Works pretty well on my Windows 10 desktop.  A little more power and memory there, but this is noticeably slower than other features in Unity3d, from a relative perspective.

In a potentially related note, when using a Mac, the context windows for searching for a node are constantly resizing as you attempt to choose a node from the list (since the "hints" at the bottom of the list are forcing the panel to resize from the center, instead of top anchored, as on windows).  Also, right clicking with the trackpad is ignored in the graph editor window.  It works everywhere else in Unity3d editor during the same session, just not in the graph editor.  This makes is impossible to create a new node, without dragging a wire off an existing one.  In the short term, I'd be happy with an "add node" button on the graph editor, or even a hotkey.

I hope this is helpful.  Pretty solid tool so far.  Just need a few bugs ironed out.

Hi James, 

Thanks for the feedback and the kind words. When we're talking about delay here, are you referring to unit caching or the "freeze" when entering playmode? These are different issues and areas to optimize.

For the right-clicking issue, what happens if you change the control scheme from Unreal to Unity in the preferences panel (Tools > Ludiq > Editor Preferences... > Graphs)? The Unreal control scheme (default) is more convenient for desktops, but less suited to trackpads. 

Hi Lazlo,

I am referring specifically to the unity caching.  Given that the fuzzy finder opens dozens of times in a session, waiting up to thirty seconds is rough.  The "play freeze" is annoying, but I would take it over the caching.

As for the right clicking, I have tried both control schemes.  Unity is better on the trackpad for panning the graph, but right click doesn't work on either scheme.  This is further difficult, since the mac uses "ctrl+click" to right-click.  Since Bolt uses "ctrl+drag" to create groups, this seems to override the right click.  This makes the trackpad totally unusable on the MacBook Pro.  

Thanks for clarifying. Version 1.0.1 will not address the loading times yet, but it's my next priority.

I believe the usual control scheme for Mac OS is to replace most instances of "Ctrl" on Windows with "Cmd", am I right? If that's correct, I'll change group creation to Cmd+Click on Mac.

In the mean time, to trigger the menu on the trackpad, you can use the default multi-touch action of tapping with two fingers to right-click.

It would also be handy if you could simply drag to select a group and on realize be given the option to create the group as opposed to CMD/CTL drag

You can already start holding Ctrl after you've started selecting to turn the lasso into a grouping tool. Or is that not what you mean?

Yeah. Being lazy. Kinda would like to skip the whole holding part. I frequently work one handed.

you are correct.  normal convention is "Cmd"

As to you other point, two finger tap is also not working.  basically, no kind of right click on the mac trackpad.

Two-tap works here. Do you have secondary click enabled in your trackpad preferences?

I'll updating the control scheme for v.1.0.1 to use Cmd everywhere and fix Ctrl+Click.

hmm.  that is really strange.  maybe it is just me.  I do have secondary click enabled.  The odd part is that it works in the panel right next to Bolt, but not in the Bolt graph editor panel itself.  maybe a conflict with the mouse driver I have installed.  who knows.

I can attest to that as well, the fuzzy finder will resize and cause an almost flickering like screen when hovering over nodes with many options making it very difficult to see or choose the one you need, of course making note of where you open the finder will help but not convenient. Not an issue on my iMac, but on on my Air, with the much smaller screen, becomes problematic in picking some nodes.


+1

I have a pretty beefy machine (i7 w/ 16 GB of ram) and I see a hang of 1-2s when pressing play on Windows 10. I'd love for it to not have to recache every time or I had a way to explicitly tell it to recache. 

Thanks for the feedback. I will definitely address the caching issue before the hang issue.

That is welcome news and a small conseeion to speed up that process. Ty. 

+1
Under Review

Bad news, everyone. :/

I implemented the solution I was planning (caching the options to a file and loading them, instead of recalculating them every time).

It turns out that loading the file with 20k+ options is exactly as long as calculating the options for 20k+ units (10 seconds on my machine), meaning the last two days of work on this are pretty much moot. FullSerializer isn't the fastest deserializer, and at the moment I'm not sure at all how I'll be able to fix this issue.

I'll get some rest and see if some miracle solution comes to me. Rest assured this remains my #1 priority, but I'm at the end of my wits at the moment.

Hi!
Maybe you can collaborate with developers of product: http://sirenix.net/odininspector? It's has own serializer, maybe it's more powerful and fast then FullSerializer.

Why does it have to load them more than once?  Shouldn't that only be an issue when we open the project, or does Unity work in some other way somehow?

It's actually because Unity reloads all assemblies whenever you enter play mode. That means that all the memory is cleared, and every script, window, variable or whatnot is reset. 

Unfortunately, the only way to preserve the data across assembly reloads is to serialize it (save it to a file on disk) before the reload, and deserialize it (load it from the file) after the reload. This works OK for small things like settings and whatnot, but when you have a massive database 15 MB of tens of thousands of units, it takes too long.

FullSerializer (what Bolt uses to save and load data) is in part the culprit here. It's the most powerful serializer available out there, but it's also one of the slower ones. I might have to introduce another storage format that's faster just for the unit database, for example SQLite, but that's another layer of complexity and dependencies that I'd like to avoid if I could.

Well, I think with how cool Bolt is already, you'll come up with something great! 

Hmmm
Playing arround with bolt for one day now but i have to say i am not really happy with it.
On my i7, 16RAM it takes sometimes more than 10 seconds before i can type to search an function.

I tied it on my old notebook and it needs quite the same time. This is not really usable for my daily work. The Opportunity from Node based scripting systems should be to get a prototype very fast done.